Webd

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à »

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.

Pour redimensionner une image, c’est plutôt simple ! L’idée est de créer un contexte d’image de la taille souhaitée (ici 40*40 pixels). Dans ce contexte, en dessine l’image à redimensionner dans la taille souhaitée. Il ne reste alors plus qu’à récupérer l’image redimensionnée avec un UIGraphicsGetImageFromCurrentImageContext. Pour finir, on pensera bien à fermer le contexte courant.

Voici le code final:

CGSize size = CGSizeMake(40, 40);
UIGraphicsBeginImageContext( size );
[avatarImage drawInRect:CGRectMake(0,0,size.width,size.height)];
avatarImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();

Le NSLog est l’outil de base dans le développement et le déboguage d’application Cocoa (donc Cocoa Touch). Seulement, l’utilisation de NSLog n’est pas si anodine qu’elle peut paraître … Le fait d’envoyer une chaine de caractère à la sortie console consomme des ressources.

Certes, c’est peu de choses, mais quand un NSLog est inclus dans une boucle, se déclenche à chaque touchesMoved: (par exemple), il commence à ralentir très sérieusement le fonctionnement de l’application. Sans compter qu’une fois l’application distribuée, il est possible pour l’utilisateur final de lire ce qui se trouve dans les logs … Ce qui n’est pas forcement voulu pour le développeur.

L’idée serait donc, quand on est en configuration de compilation « release », de désactiver (automatiquement les NSLog). La suite du billet, c’est par là »

Je viens de découvrir aujourd’hui une nouvelle librairie permettant de simplifier l’utilisation de SQLite3 sur iPhone: Iphonelite3. L’idée global du projet est de ne pas avoir à coder une seule ligne de SQL dans son application. Il s’agit tout bêtement de faire de la persistance d’objet. Là où le concept est intéressant, c’est qu’il ne se base pas sur des objets héritant d’une quelconque implémentation de serialisation.

Non, l’idée est plus axée « hibernate » (que l’on trouve avec Java). Vous passez votre objet au gestionnaire de base de données et il s’occupe de tout le reste. Je ne vais pas continuer à faire l’article de Iphonelite3, son auteur le fait très bien sur son blog dédié. Notez que le projet est, pour le moment, en phase alpha et ne doit donc pas être utilisé en phase de production. Mais c’est à regarder avec attention.

Au passage, je rappellerais ce qui se fait sur ce segment en ce moment. Il y a les projets FMDB (que j’utilise dans deux de mes projets), SQLitePersistentObjects (que je n’ai pas pu utiliser dans mon dernier projet car il gère mal les NSMutableDictionary) et EntropyDB.

L’UITableView est un outil idéal pour afficher une certaine quantité de données à l’utilisateur. Seulement voilà, quand cette quantité de données devient grande, il peut être intéressant de permettre à l’utilisateur d’accéder rapidement à l’information qu’il souhaite.

Une des solutions est d’utiliser le tri par ordre alphabétique. C’est l’idéal pour l’affichage de contacts (par exemple). On peut même aller plus loin. Pourquoi simplement se limiter à un tri par ordre alphabétique ? Pourquoi ne pas proposer une catégorisation des entrées en prenant en compte la première lettre de la propriété qui nous intéresse. C’est ce que nous allons voir dans ce billet. Au final, nous arriverons à ce résultat:

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