Webd

Vous l’aurez vu ces dernières semaines, mon activité ici a été plus que réduite. Ce n’est pas un manque de motivation ou l’agonie d’un blog. Non, bien au contraire. En fait, j’avais un autre projet très chronophage dans les cartons. Il s’agit de Vélo Rennes. Pour faire simple, Vélo Rennes est une application iPhone gratuite qui se veut être le compagnon idéal des rennais utilisant le réseau Le Velo Star. Pour plus de détails, voyez la page qui y est consacrée ou allez sur l’AppStore.

Pourquoi m’être investi dans ce projet ? Pour plusieurs raisons simples:

• Rennes Métropole vient de lancer une initiative visant à créer un entrepôt de données en accès libre. Concrètement, l’idée est de mettre à disposition de n’importe qui toutes les informations intéressant le grand public. Pour le moment, seules les données du réseau Le Velo Star sont accessibles. A terme, il en sera de même pour les bus, le métro, les points d’intérêt, … Plus d’informations sur data.keolis-rennes.com
• Je suis développeur iPhone depuis Juin 2008 et je n’avais pas eu l’occasion jusqu’à maintenant de m’investir sur un projet totalement personnel. Et finalement, ce fût très instructif. J’ai pu découvrir des aspects méconnus pour moi de la réalisation bout-en-bout. Certes, il ne s’agissait que de petits détails, mais c’est toujours bon à apprendre.
• C’est un service qui me manquait. Franchement, j’arrive pas à comprendre comment cela se fait que Rennes n’avait pas de service équivalent à Vélo Rennes

.

Bref voilà, après un mois de travail, je vous présente Vélo Rennes:

Je profite de ce billet pour remercier tout ceux qui ont participé à ce projet de façon plus ou moins directs. Qu’il s’agisse de coups de mains graphiques ou bien d’avis, critiques ou conseils tout au long de la conception de Vélo Rennes.

Au passage: Vélo Rennes va très certainement être amené à évoluer. N’hésitez pas à me contacter si vous avez des remarques, question ou suggestions.

L’utilisation d’Interface Builder s’avère très pratique pour les développeurs Cocoa Touch. C’est vrais que c’est génial de pouvoir créer ses interfaces en mode WYSIWYG. Oui mais voilà, cela peut poser quelques problèmes. Outre les cas où l’utilisation du code est nécessaire (pour atteindre la granularité voulue), on peut vouloir renoncer à l’utilisation des nibs pour des raisons de performance.

En effet, dans certains cas l’utilisation des nibs pose de sérieux problèmes de performance. On se retrouve ainsi avec un dur choix: soit on choisit la simplicité (et on utilise Interface Builder), soit on écrit ses interfaces directement dans le code et on gagne en performance. Dans certains cas, l’impact de l’utilisation des nibs sur la performance est quasi nul. La question ne se pose donc pas. Mais parfois, ce n’est pas le cas.
La suite du billet, c’est par là »

Il est souvent utile de comparer deux NSDate dans le temps. Il s’agit de savoir si une date est antérieure ou postérieure à une autre. Le mécanisme offert par Apple pour les comparaisons de NSDate n’est pas des plus pratiques. Il faut utiliser la méthode compare:(NSDate*)date qui retourne un objet de type NSComparisonResult.

Cette méthode est une méthode standard de Foundation. Elle permet, grâce à des résultats de comparaison standardisés d’effectuer un tri sur des objets de façon générique. Oui, mais Apple ne prévoit pas de méthodes un peu plus haut niveau pour les simples comparaisons de dates. Voilà pourquoi j’ai écrit rapidement une addition de la classe NSDate permettant de comparer deux dates intuitivement. Les voici:
La suite du billet, c’est par là »

Je vois assez souvent, dans les fichiers de code qui passent entre mes mains, des en-têtes comme ceci:

//  Created by Julien on 17/01/09.
//  Copyright 2009 __MyCompanyName__. All rights reserved.

Le problème porte sur __MyCompanyName__. Il serait bien plus propre de le remplacer par une valeur personnalisée (et automatique de préférence). Pour ceci, Apple a tout prévu …
La suite du billet, c’est par là »

Il y a peu, je vous présentais ici même comment redimensionner une UIImage. Je vous replace dans le contexte: Dans certains cas, il peut être utile de redimensionner une UIImage. En effet, même si UIImageView gère très bien le redimensionnement, on peut vouloir exporter une image dans une certaine taille. De même, il n’est pas forcement utile de stocker (en mémoire ou bien en dur) une image de grande taille si c’est pour l’afficher réduite par la suite.

Le code qui était présenté est fonctionnel … Oui, mais un collègue m’a fait remarquer que ce n’était pas le cas en multi-threads. Pourquoi ? Tout simplement parce que quand on fait UIGraphicsBeginImageContext(), on travaille dans un contexte unique. Ainsi, quand on voudra redimensionner deux images en même temps, elles partageront le même contexte. Clairement, ça ne peut pas marcher. D’ailleurs: ça ne marche pas !

La suite du billet, c’est par là »

Pour ceux qui ne la connaissent pas, MD5 est une méthode permettant d’obtenir une empreinte numérique unique d’un message (au sens large du terme: chaine de caractère ou fichier). Cet algorithme a longtemps été utilisé à des fins de sécurité. Au risque de me répéter: n’utilisez pas MD5 à des fins de sécurité ! Cet algorithme est maintenant faible. Plus d’informations sur Wikipedia EN.

MD5 peut être utilisé pour générer une clef « unique » à partir d’une chaine de caractères. Exemple concret: j’ai des objets représentant des rendez-vous qui naviguent un peu partout (SQLite local, serveur de calendrier distant, …). Il me faut à tout moment pouvoir identifier uniquement un rendez-vous. La solution que j’ai choisi est de générer une somme MD5 à partir du titre du rendez-vous, de la date de création et l’UDID (voir Comment récupérer l’UDID). Voici l’implémentation que j’utilise pour générer mes MD5 (dans le cas présent, c’est une addition de NSString):
La suite du billet, c’est par là »