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.

Dans ce dernier cas de figure, il existe maintenant une solution: nib2objc. Ce projet Open-Source est tout simplement un convertisseur de fichiers nib (.xib) vers du code Objectif-C. Il gère toutes les propriétés publiques de chacun des éléments graphiques, le constructeur et la hiérarchie des vues. Pour le moment, il n’y a que les composants d’UIKit qui sont supportés. L’utilisation est on-ne-peut-plus simple:

imac-de-julien-2:Debug julien$ ./nib2objc demo.xib > demo.m

Et voilà le résultat pour ce nib:

UILabel *view6 = [[UILabel alloc] initWithFrame:CGRectMake(20.0, 20.0, 260.0, 21.0)];
view6.frame = CGRectMake(20.0, 20.0, 260.0, 21.0);
view6.adjustsFontSizeToFitWidth = YES;
view6.alpha = 1.000;
view6.autoresizingMask = UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleBottomMargin;
view6.baselineAdjustment = UIBaselineAdjustmentAlignCenters;
view6.clearsContextBeforeDrawing = YES;
view6.clipsToBounds = YES;
view6.contentMode = UIViewContentModeScaleToFill;
view6.enabled = YES;
view6.font = [UIFont fontWithName:@"Helvetica" size:17.000];
view6.hidden = NO;
view6.lineBreakMode = UILineBreakModeTailTruncation;
view6.minimumFontSize = 10.000;
view6.multipleTouchEnabled = NO;
view6.numberOfLines = 1;
view6.opaque = NO;
view6.shadowOffset = CGSizeMake(0.0, -1.0);
view6.tag = 0;
view6.text = @"Ma célule personalisée";
view6.textAlignment = UITextAlignmentCenter;
view6.textColor = [UIColor colorWithRed:0.000 green:0.000 blue:0.000 alpha:1.000];
view6.userInteractionEnabled = NO;

UITableViewCell *view4 = [[UITableViewCell alloc] initWithFrame:CGRectMake(0.0, 0.0, 300.0, 182.0) reuseIdentifier:(null)];
view4.frame = CGRectMake(0.0, 0.0, 300.0, 182.0);
view4.accessoryType = UITableViewCellAccessoryNone;
view4.alpha = 1.000;
view4.autoresizingMask = UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleBottomMargin;
view4.backgroundColor = [UIColor colorWithRed:1.000 green:1.000 blue:1.000 alpha:1.000];
view4.clearsContextBeforeDrawing = NO;
view4.clipsToBounds = NO;
view4.contentMode = UIViewContentModeScaleToFill;
view4.font = [UIFont fontWithName:@"Helvetica" size:17.000];
view4.hidden = NO;
view4.hidesAccessoryWhenEditing = YES;
view4.indentationLevel = 0;
view4.indentationWidth = 10.000;
view4.lineBreakMode = UILineBreakModeTailTruncation;
view4.multipleTouchEnabled = NO;
view4.opaque = YES;
view4.selectedTextColor = [UIColor colorWithWhite:1.000 alpha:1.000];
view4.selectionStyle = UITableViewCellSelectionStyleBlue;
view4.showsReorderControl = NO;
view4.tag = 0;
view4.textAlignment = UITextAlignmentLeft;
view4.textColor = [UIColor colorWithWhite:0.000 alpha:1.000];
view4.userInteractionEnabled = YES;

UIButton *view7 = [UIButton buttonWithType:UIButtonTypeRoundedRect];
view7.frame = CGRectMake(101.0, 49.0, 99.0, 37.0);
view7.adjustsImageWhenDisabled = YES;
view7.adjustsImageWhenHighlighted = YES;
view7.alpha = 1.000;
view7.autoresizingMask = UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleBottomMargin;
view7.clearsContextBeforeDrawing = NO;
view7.clipsToBounds = NO;
view7.contentHorizontalAlignment = UIControlContentHorizontalAlignmentCenter;
view7.contentMode = UIViewContentModeScaleToFill;
view7.contentVerticalAlignment = UIControlContentVerticalAlignmentCenter;
view7.enabled = YES;
view7.font = [UIFont fontWithName:@"Helvetica-Bold" size:15.000];
view7.hidden = NO;
view7.highlighted = NO;
view7.multipleTouchEnabled = NO;
view7.opaque = NO;
view7.reversesTitleShadowWhenHighlighted = NO;
view7.selected = NO;
view7.showsTouchWhenHighlighted = NO;
view7.tag = 0;
view7.titleShadowOffset = CGSizeMake(1.0, 1.0);
view7.userInteractionEnabled = YES;
[view7 setTitle:@"Un bouton" forState:UIControlStateNormal];
[view7 setTitleColor:[UIColor colorWithWhite:1.000 alpha:1.000] forState:UIControlStateHighlighted];
[view7 setTitleColor:NSPatternColorSpace NSImage 0x2c3e5a0 Size={320, 460} Reps=(
    NSBitmapImageRep 0x2c49460 Size={320, 460} ColorSpace=NSDeviceRGBColorSpace BPS=8 BPP=32 Pixels=320x460 Alpha=YES Planar=NO Format=1
) forState:UIControlStateNormal];
[view7 setTitleShadowColor:NSNamedColorSpace System controlColor forState:UIControlStateNormal];

UISwitch *view8 = [[UISwitch alloc] initWithFrame:CGRectMake(103.0, 103.0, 94.0, 27.0)];
view8.frame = CGRectMake(103.0, 103.0, 94.0, 27.0);
view8.alpha = 1.000;
view8.autoresizingMask = UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleBottomMargin;
view8.clearsContextBeforeDrawing = YES;
view8.clipsToBounds = YES;
view8.contentHorizontalAlignment = UIControlContentHorizontalAlignmentCenter;
view8.contentMode = UIViewContentModeScaleToFill;
view8.contentVerticalAlignment = UIControlContentVerticalAlignmentCenter;
view8.enabled = YES;
view8.hidden = NO;
view8.highlighted = YES;
view8.multipleTouchEnabled = YES;
view8.on = YES;
view8.opaque = NO;
view8.selected = NO;
view8.tag = 0;
view8.userInteractionEnabled = YES;

[view4 addSubview:view6];
[view4 addSubview:view7];
[view4 addSubview:view8];

Comme vous pouvez le voir, c’est très verbeux. C’est parce que l’outil ne détecte pas les valeurs qui sont là par défaut. Donc dans le doute, il génère toutes les propriétés. A noter aussi que les valeurs des propriétés UIImage, NSLocale et NSTimeZone ne sont pas sorties dans le code. En effet, ibtool (sur lequel nib2objc se base) ne les supporte pas.

Plus d’informations sur la page du projet nib2objc du site d’Adrian Kosmaczewski.

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:

//
//  NSDateAdditions.h
//
//  Created by Julien on 28/05/09.
//  Copyright 2009 Julien Quéré - Webd.fr. All rights reserved.
//

#import 

@interface NSDate (NSDateAdditions)
-(BOOL) isLaterThanOrEqualTo:(NSDate*)date;
-(BOOL) isEarlierThanOrEqualTo:(NSDate*)date;
-(BOOL) isLaterThan:(NSDate*)date;
-(BOOL) isEarlierThan:(NSDate*)date;
@end

//  NSDateAdditions.m
//
//  Created by Julien on 28/05/09.
//  Copyright 2009 Julien Quéré - Webd.fr. All rights reserved.
//

#import "NSDateAdditions.h"

@implementation NSDate (NSDateAdditions)

-(BOOL) isLaterThanOrEqualTo:(NSDate*)date {
	return !([self compare:date] == NSOrderedAscending);
}

-(BOOL) isEarlierThanOrEqualTo:(NSDate*)date {
	return !([self compare:date] == NSOrderedDescending);
}
-(BOOL) isLaterThan:(NSDate*)date {
	return ([self compare:date] == NSOrderedDescending);

}
-(BOOL) isEarlierThan:(NSDate*)date {
	return ([self compare:date] == NSOrderedAscending);
}

@end

L’utilisation, quant à elle est on-ne-peut plus simple:

// Compare a NSDate (maDate) and the actual date
if([maDate isEarlierThanOrEqualTo:[NSDate date]])
{
	NSLog(@"It's earlier or equal");
}
else
{
	NSLog(@"It's later");
}

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();

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). Pour ce faire, on va simplement ajouter le code suivant dans leNomDeLApplication_Prefix.pch (il s’agit simplement d’un fichier qui est inclus dans tous les fichiers d’un projet):

#ifndef DEBUG
#define NSLog //
#endif

Le code veut simplement dire: Si DEBUG n’est pas activé, on remplace les NSLog par des commentaires. On pensera donc à ajouter un flag DEBUG dans GCC_PREPROCESSOR_DEFINITIONS de la configuration de compilation dans le mode Debug. Notez que, par défaut, GCC_PREPROCESSOR_DEFINITIONS n’existe pas, il faudra donc le créer à la main.

Voilà, c’est fini . Notez tout de même que cette façon de faire a une limitation: il faut que les NSLog soient définis sur une seule ligne. Mais bon, ça l’est dans 99% des cas !

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.

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:

On commence par créer notre projet dans Xcode et on lui ajoute un TableViewController. Pour le moment, on n’y touche pas. Ensuite, on créée le xib des cellules avec Interface Builder (pour plus de détails sur la manipulation de UITableViewCell avec Interface Builder, voir Créer une UITableViewCell personnalisée à partir d’Interface Builder). Maintenant, faisons une structure pour nos données. Ce sera une simple classe contenant 4 propriétés NSString: firstname, lastname, age et sex. Ce qui donne tout simplement:

@interface Person : NSObject {
    NSString *firstname;
    NSString *lastname;
    NSString *age;
    NSString *sex;
}

On rajoute aussi les méthodes d’initialisation et de désallocation de l’objet:

- (id) initWithLastName:(NSString *)mlastname andFirstname:(NSString *)mfirstname andSex:(NSString *)msex andAge:(NSString *)mage {
	lastname = [[NSString alloc] initWithString:mlastname];
	firstname = [[NSString alloc] initWithString:mfirstname];
	sex = [[NSString alloc] initWithString:msex];
	age = [[NSString alloc] initWithString:mage];
	return [super init];
}

- (void) dealloc {
	[lastname release];
	[firstname release];
	[sex release];
	[age release];
	[super dealloc];
}

Toute la partie manipulation de données sera gérée par PersonDataSource. Il s’agit d’une classe contenant:

• un NSArray (personList) qui contiendra notre liste de Person brute (c’est à dire non-triée)
• un NSMutableDictionary (personListAlphabeticalDictionary) qui contiendra nos Person triées par ordre alphabétique. Chaque entrée du dictionnaire aura pour clef la première lettre du nom des Person et en valeur, le tableau de Person correspondant.
• un NSArray (personNameFirstLeterIndexArray) qui contiendra la liste de toutes les premières lettres de noms disponibles. En effet, il se peut que l’on n’ai aucune entrée avec comme première lettre Z (par exemple).

Du coté des méthodes, ça donne cela:

• - (void) populate: cette méthode ne fait que récupérer nos objets Person. Dans l’exemple, j’ajoute les objets à la main, mais on peut tout à fait remplacer ça par une récupération de données dans un fichier XML ou bien une base de données.
• - (void) populatePersonListAlphabeticalDictionary: cette méthode va aller chercher le contenu de personList et générer personListAlphabeticalDictionary comme convenu. Pour finir, la méthode va appeler sortPersonInitialLetterIndexes.
• - (void) sortPersonInitialLetterIndexes: cette méthode va générer personNameIndexArray en récupérant toutes les clefs de personListAlphabeticalDictionary (triées alphabétiquement). Puis pour chacune des clefs, presortPersonListAlphabeticalDictionaryForInitialLetter
• - (void)presortPersonListAlphabeticalDictionaryForInitialLetter:(NSString *)aKey va (pour une clef aKey donnée), trier le contenu du NSArray correspondant dans le personListAlphabeticalDictionary.
• - (NSArray *)personsWithInitialLetter:(NSString*)aKey: cette méthode retourne un NSArray avec toutes les Person ayant pour première lettre aKey.
• - (Person *) personForIndexPath:(NSIndexPath *)indexPath retourne l’objet Person correspondant au NSIndexPath passé en paramètre. Cette méthode sera appelée par le UITableViewController.

Au final, on obtient ceci:

- (id) init {
	[self populate];
	[self populatePersonListAlphabeticalDictionary];

	return [super init];

}
- (void) dealloc {

	[personList release];
	[personListAlphabeticalDictionary release];
	[personNameIndexArray release];
	[super dealloc];
}

- (void) populate {
	personList = [[NSMutableArray alloc] init];
	[personList addObject:[[Person alloc] initWithLastName:@"Léponge" andFirstname:@"Bob" andSex:@"Homme" andAge:@"21"]];
	[personList addObject:[[Person alloc] initWithLastName:@"Daniel" andFirstname:@"Jack" andSex:@"Whiskey" andAge:@"12"]];
	[personList addObject:[[Person alloc] initWithLastName:@"Fontaine" andFirstname:@"Claire" andSex:@"Femme" andAge:@"89"]];
	[personList addObject:[[Person alloc] initWithLastName:@"Charues" andFirstname:@"Vielles" andSex:@"Festival" andAge:@"125"]];
	[personList addObject:[[Person alloc] initWithLastName:@"Bull" andFirstname:@"Red" andSex:@"Boisson" andAge:@"2"]];
	[personList addObject:[[Person alloc] initWithLastName:@"Bonvoisin" andFirstname:@"Bernie" andSex:@"Homme" andAge:@"55"]];
	[personList addObject:[[Person alloc] initWithLastName:@"Jobs" andFirstname:@"Steeve" andSex:@"Homme" andAge:@"80"]];
	[personList addObject:[[Person alloc] initWithLastName:@"Damien" andFirstname:@"Francois" andSex:@"Humoriste" andAge:@"35"]];
	[personList addObject:[[Person alloc] initWithLastName:@"Gates" andFirstname:@"Bill" andSex:@"Homme" andAge:@"50"]];
	[personList addObject:[[Person alloc] initWithLastName:@"Laporte" andFirstname:@"Bernard" andSex:@"Rugbyman" andAge:@"32"]];
	[personList addObject:[[Person alloc] initWithLastName:@"Chabal" andFirstname:@"Sebastien" andSex:@"Mythe" andAge:@"36"]];
}
- (void) populatePersonListAlphabeticalDictionary {
	personListAlphabeticalDictionary = [[NSMutableDictionary alloc] init];
	for(Person *currentPerson in personList)
	{

		NSString *firstLetter = [currentPerson.lastname substringToIndex:1];
		NSMutableArray *existingArray;
		/* Si on a déjà un array de Person pour cette première lettre*/
		if (existingArray = [personListAlphabeticalDictionary valueForKey:firstLetter])
		{
			/* On y ajoute la Person en cours*/
			[existingArray addObject:currentPerson];
		}
		else	/*Sinon, on créée l'array, on y ajoute la Person courante et on ajoute l'array au dictionnaire*/
		{
			NSMutableArray *tempArray = [NSMutableArray array];
			[tempArray addObject:currentPerson];
			[personListAlphabeticalDictionary setObject:tempArray forKey:firstLetter];
		}

	}

	/* On génère personNameIndexArray et on trie chaque array de personListAlphabeticalDictionary*/
	[self sortPersonInitialLetterIndexes];

}

- (void) sortPersonInitialLetterIndexes {
	personNameIndexArray = [[NSMutableArray alloc] init];
	/* On récupère toutes les premières lettres et on les trie en ignorant la case*/
	personNameIndexArray = [[personListAlphabeticalDictionary allKeys] sortedArrayUsingSelector:@selector(localizedCaseInsensitiveCompare:)];
	for (NSString * eachNameIndex in personNameIndexArray)
	{
		[self presortPersonListAlphabeticalDictionaryForInitialLetter:eachNameIndex];
	}

}
- (void)presortPersonListAlphabeticalDictionaryForInitialLetter:(NSString *)aKey {
	/* Pour chaque array à la clef aKey dans le dictionnaire, on trie le contenu de l'array alphabétiquement sur la propriété lastname en ignorant la case*/
	NSSortDescriptor *nameDescriptor = [[NSSortDescriptor alloc] initWithKey:@"lastname"
																   ascending:YES
																	selector:@selector(localizedCaseInsensitiveCompare:)];
	NSArray *descriptors = [NSArray arrayWithObject:nameDescriptor];
	[[personListAlphabeticalDictionary objectForKey:aKey] sortUsingDescriptors:descriptors];
	[nameDescriptor release];
}
- (Person *) personForIndexPath:(NSIndexPath *)indexPath {
	/* On récupère la lettre qui a un ID correspondant à la section de l'indexPath */
	NSArray *personsWithInitLetter = [self personsWithInitialLetter:[personNameIndexArray objectAtIndex:indexPath.section]];
	/* Et on renvoie la Person correspondant au row*/
	return [personsWithInitLetter objectAtIndex:indexPath.row];
}

- (NSArray *)personsWithInitialLetter:(NSString*)aKey {
	/* On renvoie la liste des Person ayant pour première lettre aKey*/
	return [personListAlphabeticalDictionary objectForKey:aKey];
}

Maintenant que notre source de données est prête, il n’y a plus qu’à mettre en place la TableView en elle-même. La première chose est d’ajouter un personDataSource comme variable d’instance et de l’initialiser (via [[PersonDataSource alloc]init];). Ensuite, on attaque le
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath. Le fonctionement est traditionnel. La seule subtilité, c’est qu’on va récupérer l’objet Person via [personDataSource personForIndexPath:indexPath].

Pour le nombre de sections dans la table, c’est simple: il y en aura autant que de première lettres. Donc, c’est tout naturellement que - (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView renvera [[personDataSource personNameIndexArray] count]. Pour le nombre de lignes dans chaque section, c'est le nombre de Person ayant pour première lettre celle qui correspond à la section courante. C'est pourquoi
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section retourne return [[self miniContactsWithInitialLetter:[miniContactNameIndexArray objectAtIndex:section]] count];. On obtient donc ce code pour le UITableViewController:

@implementation AlphaTableViewController
- (id)initWithStyle:(UITableViewStyle)style{
	if (self = [super initWithStyle:style])
	{
		personDataSource = [[PersonDataSource alloc]init];
		self.tableView.rowHeight = 125;
	}
	return self;
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

	static NSString *CellIdentifier = @"MyCellIdent";

    TableCell *cell = (TableCell *) [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
    	UIViewController *c = [[UIViewController alloc] initWithNibName:@"TableViewCell"  bundle:nil];
		cell = (TableCell *)c.view;
		[c release];
    }
	Person *currentPerson = [personDataSource personForIndexPath:indexPath];

	[cell.firstname setText:[currentPerson firstname]];
	[cell.lastname setText:[currentPerson lastname]];
	[cell.sex setText:[currentPerson sex]];
	[cell.age setText:[currentPerson age]];	

    return cell;
}

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
    return [[personDataSource personNameIndexArray] count];
}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
	return [[personDataSource personsWithInitialLetter:[[personDataSource personNameIndexArray] objectAtIndex:section]] count];
}

Cela donne le résultat ci-dessous. C'est bien, mais il manque encore la liste des lettres sur la droite. C'est pas compliqué .

En fait, il faut être capable de répondre à deux questions posées à l'UITableViewController: quels sont les titres à afficher pour l'index de la TableView via
- (NSArray *)sectionIndexTitlesForTableView:(UITableView *)tableView et Pour la section X, où faut-il scroller la TableView via
- (NSInteger)tableView:(UITableView *)tableView sectionForSectionIndexTitle:(NSString *)title atIndex:(NSInteger)index. Au final, il est très facile de répondre à ces questions dans l'architecture que l'on a mis en place. Voilà ce que ça donne dans le code:

- (NSArray *)sectionIndexTitlesForTableView:(UITableView *)tableView {
	return [personDataSource personNameIndexArray];
}
- (NSInteger)tableView:(UITableView *)tableView sectionForSectionIndexTitle:(NSString *)title atIndex:(NSInteger)index {
	return index;
}

Et le résultat final ... Vous l'avez déjà vu plus haut. Si vous voulez, vous trouverez ici une archive du projet complet (Xcode 3.1).

Il s’agit d’une TableView qui va chercher les dernières photos Flickr avec pour tag « xmas ». Pourquoi donner un exemple aussi compliqué ? Tout simplement parce que je n’ai vraiment pas le temps de faire un exemple complet en ce moment et je voulais publier un exemple rapidement. J’ai donc récupéré rapidement un exemple de code que j’ai fais en interne pour le boulot.

La partie de code qui va chercher les images sur FlickR n’est pas de moi. L’auteur n’ayant pas laissé d’informations le concernant dans le code, je ne pourrais plus vous dire qui c’est (et ça me désole vraiment).

Voici l’archive contenant le projet Xcode complet (toute l’intelligence concernant la méthode pour l’UITableViewCell se trouve dans MyTableViewController.m à la méthode - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath): télécharger MyTableViewDemo.zip.

Le souci, c’est qu’il n’est pas possible de préciser dans le code la taille d’une UITableView. Après avoir essayé plusieurs solutions (dont certaines était plutôt farfelue), j’en ai retenu une. C’est celle qui m’a semblé la plus propre, simple et efficace.

Il s’agit tout simplement de créer une vue vide de la taille de la UIToolBar (par défaut: 44 pixels). Puis de la mettre en tant que tableFooterView (une vue qui n’est affichée que tout en bas de la UITableView) sur la UITableView courante. L’idéal c’est de faire ça directement dans la phase d’initialisation (dans le UITableViewController). Concrètement ça donne ça:

self.tableView.tableFooterView = [[UIView alloc] initWithFrame:CGRectMake(0, 0, 320, 44)];

La TableView est un composant essentiel de l’HIM de l’iPhone très simple à développer pour des besoins simples. Clairement, si on doit afficher à l’utilisateur des cellules avec une seule ligne de texte, ça se fait les doigts dans le nez.

Là où les choses se corsent, c’est quand il faut créer des cellules personnalisées. Avec, par exemple, deux UILabel et une UIImageView. En effet, il n’existe pas de méthode pour charger un nib (comme l’habituel initWithNibName:). Ainsi, on se retrouve forcé à créer tout nos éléments et à les placer à la main dans le code. C’est loin d’être quelque chose d’agréable, simple et rapide à faire. Sans compter qu’au moindre changement de design de la cellule, on perd un temps fou.

La solution

Non, l’idéal c’est de pouvoir utiliser Interface Builder pour construire ses cellules… Après quelques essais, recherches et erreurs, voici la solution que j’ai trouvé (et que j’utilise):

On commence par créer une nouvelle interface dans IB. On y ajoute une TableCell (au passage, le nib ne doit contenir que des TableCell’s !). Dans la TableCell, on ajoute les éléments dont on a besoin (ici, deux UILabel et un UIImageView). On définit la Class Identity et les Class Outlets qui vont bien. On finit par un Write Classfile et on a notre nib et l’UITableViewCell dans le projet.

Maintenant, il faut s’occuper de l’UITableViewController. L’utilisation d’un nib ne change absolument rien au fonctionnement habituel. Ce n’est qu’à la création de la cellule (dans - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath) que cela change un peu. Voilà ce que ça donne:

(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    static NSString *CellIdentifier = @"MyCellIdent";
    MyTableViewCell *cell = (MyTableViewCell *) [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
    	// On initialise un ViewController à partir du Nib qui a été fait
    	UIViewController *c = [[UIViewController alloc] initWithNibName:@"MyTableViewCell"  bundle:nil];
	// On récupère sa vue et on la caste dans le type de notre TableViewCell
	cell = (MyTableViewCell *)c.view;
	[c release];
    }
    // Ensuite, ça reste traditionnel
    cell.label1.text = [[myObjects objectAtIndex:indexPath.row] name];
    cell.label2.text = [[myObjects objectAtIndex:indexPath.row] desc];
    [cell.uIImageView  setImage:[[myObjects objectAtIndex:indexPath.row] image]];
    return cell;
}

Les développeurs avisés auront très certainement remarqué un petit détail qui a son importance: on ne définit jamais (lors de la création de la cellule) son CellIdentifier, ainsi la réutilisation de cellules devient impossible (ce qui est suicidaire en terme de mémoire). En fait, celui-ci se définit dans Interface Builder. Dans les propriétés de votre TableViewCell, il suffit de mettre votre CellIndetifier dans Identifier. Ici, on mettra donc MyCellIdent.

Vous voilà maintenant avec des TableViewCell générée à partir d’Interface Builder en gardant possible le mécanisme de ré-utilisation de cellules. Ça, c’est des demies journées de gagnées sur vos projets (si ils comportent des cellules personnalisées bien évidement).

Édition du 09/01/09:
Un exemple de code complet et opérationnel est disponible dans le billet Créer une UITableViewCell personnalisée à partir d’Interface Builder: exemple complet

L’idée est de partir du ABRecordRef correspondant au contact dont on souhaite afficher l’image. A partir de là, on vérifie que ce contact dispose bien d’une photo dans sa fiche (via ABPersonHasImageData(). Pour finir, on récupère les données brutes de l’image ( ABPersonCopyImageData()) et on crée la UIImage qui va bien (via initWithData:).

Au final, voilà ce que ça donne:

if(ABPersonHasImageData(recordRef))
{
	NSData *myAvatarData = (NSData *) ABPersonCopyImageData(recordRef);
	UIImage *avatarImage = [[UIImage alloc] initWithData:myAvatarData];
	[myAvatarData release];
}

Après, il ne faut pas oublier de libérer myAvatarData puisqu’il est devenu inutile. Charge à vous ensuite d’afficher avatarImage dans le UIImageView qui va bien. Simple non ?

L’idée ce coup là, c’est de récupérer un identifiant d’un contact. Je m’explique: dans l’application que je développe je dois enregistrer (sur un serveur distant) des informations concernant un contact sélectionné par l’utilisateur. Clairement, il s’agit du nom, du prénom et de l’adresse email. Puis, dans un second temps, ces données peuvent revenir sur l’iPhone.

Seulement, il pourrait être intéressant de faire directement le lien, lors du retour de l’information, entre les personnes désignée par les données sur le serveur et l’entité qui la représente dans le AddressBook. Pourquoi ? Pour plusieurs raisons. Tout d’abord, imaginez que l’on modifie les informations concernant la personne (cas typique: on a fait une faute de frappe quand on a saisi son nom la première fois ou elle change d’adresse mail). Et bien si on est capable de détecter ce changement quand les données reviennent sur l’iPhone, on pourra répercuter les modifications sur le serveur. La seconde raison est qu’il peut être sympa de faire un lien vers la fiche de la personne dans le AddressBook quand on affiche son nom dans l’application.

Quand on arrive dans le peoplePickerNavigationController: shouldContinueAfterSelectingPerson (donc que l’utilisateur a sélectionne un contact), on ne dispose que d’un objet de type ABRecordRef. Ce type d’objet est difficilement « sérialisable » … Comprenez par là qu’il serait difficile de le transformer en une chaine de caractère et de refaire l’opération inverse (pour le « dé-sérialiser »).

La solution est d’utiliser ABRecordGetRecordID() qui retourne un identifiant unique du contact dans l’ AddressBook. Cette fonction renvoie un objet de type ABRecordID (qui n’est ni plus ni moins qu’un entier !). Au final, pour la convertir en chaine de caractère ça donne (mPerson étant notre objet de type ABRecordRef):

NSString contactId = [NSString stringWithFormat:@"%u", ABRecordGetRecordID(mPerson)];

Ensuite, l’opération inverse (récupérer le ABRecordRef a partir du de la chaine de caractère), c’est simple:

ABRecordRef recordRef = ABAddressBookGetPersonWithRecordID(addressBook, [contactId intValue]);

Notez que dans le cas où le contact n’existe pas (plus), ABAddressBookGetPersonWithRecordID() renvoie NULLVoilà, maintenant on peut effectuer n’importe quelle opération comme si on venait de récupérer le contact à partir du peoplePickerNavigationController.

L’idée est d’aller récupérer les informations concernant un contact que l’utilisateur aura désigné dans son carnet d’adresse. Je ne vais pas expliquer ici comment mettre en place l’interface de sélection d’un contact (le peoplePickerNavigationController). En effet, Mickaël Morvan le fait très bien dans son article sur développez : « iPhone SDK: Accès au carnet d’adresses de l’iPhone ».

Comme vous avez pu le voir, récupérer le nom et le prénom d’un contact sous forme de chaine de caractère est assez simple. Par contre, si on applique la même technique à l’adresse email (en utilisant kABPersonEmailProperty à la place de kABPersonLastNameProperty), on lève une exception Terminating_Due_To_Uncaught_Exception …

Pourquoi donc ? La première chose à comprendre c’est qu’un contact n’a qu’un seul nom. Mais il peut avoir plusieurs adresses email… Par conséquent, un ABRecordCopyValue(mPerson, kABPersonEmailProperty) ne renverra pas une seule valeur mais une collection de valeurs ! Alors, évidement, quand on veut mettre ça dans un NSString ça ne passe pas.

Pour faire simple, on va considérer que seule la première adresse email nous intéresse (généralement c’est la principale). Ce qui revient à vouloir prendre la valeur à l’index 0 de la collection de valeurs. Ensuite, et bien on caste en string. Concrètement, voilà ce que ça donne :

NSString contactMail = (NSString *)ABMultiValueCopyValueAtIndex(ABRecordCopyValue(mPerson,  kABPersonEmailProperty), 0);

Après, il n’est pas dur de compléter en permettant de choisir une adresse email particulière (voir dans la littérature Apple du coté de ABMultiValue).

Mine de rien, le problème a l’air tout simple, mais il a fallu quelques heures pour en arriver là. Sans compter que toutes les recherches faites sont tombées sur des gens posant la question et n’ayant pas de réponse !