Avant de commencer il faut savoir que la mise en place d’un Splash Screen, écran de loading n’est pas conseillé par Apple : The « splash screen » isn’t supposed to be for branding or displaying a logo, it’s supposed to look like the default condition of the app so it appears to start up quickly.
En gros le splash screen n’est pas supposé être utilisé pour l’affichage d’une marque ou faire de la pub mais doit afficher la capture de votre première vue au lancement de votre application.

Exemple avec l’application Bourse : l’image utilisée pour le splash screen est la copie de la vue chargée au lancement.
Bon maintenant une grande majorité des applications sur l’AppStore ne prennent pas en considération cette préconisation Apple et affichent soit leur logo ou encore de la pub.

Alors comment fait-on ? Deux étapes : la première ajouter les images du splash screen (Une Retina et une autre “normale”) et la seconde mettre en place le code pour l’animation.

Créer le projet et mettre en place les images

Ouvrir un nouveau projet dans Xcode. On choisira ici une Window-based Application ou Empty Application (pour les dernière version d’Xcode), que l’on va appeler SplashScreen. La première fenêtre qui s’ouvre une fois le projet créé correspond aux informations du projet et de l’application en développement. La partie « Launch Images », vous permet de déclarer les deux images « SplashScreen » : une standard et une deux fois plus grande pour le Retina Display de l’iPhone 4.

Les deux images doivent être au format PNG. La image doit faire 480 x 320 pixels et la seconde (Retina) 960 x 640 pixels.

Ajouter vos images au projet en les faisant glisser depuis le Finder vers les zones concernées. La fenêtre qui s’ouvre alors vous propose d’ajouter une copie de ces éléments au projet, ce qu’il est très fortement conseillé de faire.

A la fin de cette étape, vous pouvez constater que votre image s’affiche bien lors du chargement. Cette section « Launch Images », extrêmement facile à paramétrer depuis la version 4 d’XCode permet de faire un SplashScreen simple, sans aucune ligne de code. Mais avec une jolie animation, ce serait quand même beaucoup mieux : c’est l’objet de la seconde partie.

Mise en place du code

Rendez-vous dans le fichier « SpashScreenAppDelegate.h », pour y ajouter une ImageView et une nouvelle méthode :

#import UIKit/UIKit.h
 
@interface SplashScreenAppDelegate : NSObject  {
    UIImageView *splashView;
}
 
@property (nonatomic, retain) IBOutlet UIWindow *window;
 
- (void)startupAnimationDone:(NSString *)animationID finished:(NSNumber *)finished context:(void *)context;
 
@end

Accédez au fichier « SplashScreenAppDelegate.m » pour y modifier la méthode « didFinishLaunchingWithOptions » qui a été automatiquement ajoutée par XCode lors de la création du projet.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    // Override point for customization after application launch.
    [self.window makeKeyAndVisible];
 
    splashView = [[UIImageView alloc] initWithFrame:CGRectMake(0,0, 320, 480)];
    splashView.image = [UIImage imageNamed:@"screen_tuto_mobile.png"];
    [_window addSubview:splashView];
    [_window bringSubviewToFront:splashView];
    [UIView beginAnimations:nil context:nil];
    [UIView setAnimationDuration:0.5];
    [UIView setAnimationTransition:UIViewAnimationTransitionNone forView:_window cache:YES];
    [UIView setAnimationDelegate:self];
    [UIView setAnimationDidStopSelector:@selector (startupAnimationDone:finished:context:)];
    splashView.frame = CGRectMake(-60, -60, 440, 600); splashView.alpha = 0.0; [UIView commitAnimations];
 
    return YES;
}

Pour résumer ce qui est mis en place :

• on crée notre image view qui fait toute la taille de l’écran
• on lui renseigne son image
• on l’ajoute à la vue principale ici window
• on la met en premier plan
• on lui affecte les effets d’animation (vous pouvez jouer sur les durées de transition)

Créez maintenant la méthode « startupAnimationDone: ». Nous avons précisé dans le code ci-dessus que c’est cette méthode qui doit être appelée lorsque l’animation est terminée.

- (void)startupAnimationDone:(NSString *)animationID finished:(NSNumber *)finished context:(void *)context {
    [splashView removeFromSuperview];
    [splashView release];
}

Ici on retire la vue splashView de la superview (window) et on release l’objet.

Voila ! Il ne reste plus qu’à tester et vous verrez alors l’application se lancer avec votre image de chargement et celle-ci disparaîtra au chargement complet de l’application dans un effet de transition.

Petit message en guise de conclusion

Ce tutoriel a été écrit et réalisé par Keno974. C’est sa première page sur Tutomobile, n’hésitez pas à lui faire vos remarques, à poser vos questions et surtout à l’encourager dans les commentaires. L’objectif est évidemment de lui donner envie d’en réaliser d’autres !

Vous avez été 44 à participer sur Twitter et 47 via les commentaires, merci à vous tous d’avoir tenter votre chance.

On ne va pas faire durer le suspens plus longtemps, les deux gagnants du concours via Twitter sont :

• @pcmacactufr
• @netaneo

Concernant le concours  via les commentaires, après deux tirages au sort fait grâce au site random.org, les deux gagnants sont :

C’est à dire :

• 6 : Loic - Commence dans le développement iphone, cette formation serait vraiment cool.
• 26 : benoit - C’est vraiment bien de mettre en jeu se genre de formation, ca permet de se former 

Félicitation aux gagnants, je vais prendre contact avec eux pour qu’il puisse bénéficier de leur cadeau !

]]> http://www.tutomobile.fr/concours-resultats-du-concours-pour-gagner-4-formation-video2brain-iphone/29/05/2011/feed/ 0 http://www.tutomobile.fr/concours-resultats-du-concours-pour-gagner-4-formation-video2brain-iphone/29/05/2011/ http://feedproxy.google.com/~r/TutoMobileTutorielsIphone/~3/CynKdqdtuhU/ http://www.tutomobile.fr/concours-gagner-4-formations-videos-pour-apprendre-le-developpement-iphone/23/05/2011/#comments Mon, 23 May 2011 08:12:55 +0000 Axon http://www.tutomobile.fr/?p=1859 Il y a deux semaines, nous faisions gagner quatre formations video2brain aux développeurs Android, alors cette semaine c’est au tour des développeurs iPhone de gagner une des quatres formations video2brain iPhone mis en jeu !

video2brain propose plusieurs formations vidéos iPhone et notamment celle-ci Développement d’applications pour l’iPhone. D’une valeur de 49.80€ pour 6h de formation intensive, cette formation vous permettra d’avoir de bonnes bases dans le développement iPhone. C’est donc cette formation que nous allons vous faire gagner. Et comme vous êtes nombreux à nous suivre, nous avons décider de mettre en jeu quatre formations, soit un total de lot de 199.20€ !

Vous avez jusqu’au vendredi 27 mai 23h59 pour tenter votre chance. Pour cela il y a deux moyens de gagner :

• (2 gagnants) le premier sera de laisser un commentaire sur cette article (tirage au sort grace à random.org, une seule participation par personne est autorisée)
• (2 gagnants) le second, vous devrez poster sur Twitter le tweet qui suit (et part la même occasion vous pouvez nous suivre mais ce n’est pas obligatoire @TutoMobile) :

Gagner une formation de développement #iPhone (http://goo.gl/MuuJe) grâce à @TutoMobile et @video2brainfr #concours – http://sct.me/9DB

Attention : vérifier bien que  les http soit présent dans les liens de votre tweet sinon votre candidature n’est pas pris en compte ! (MEME SI VOUS FAITES UN COPIER/COLLER, VERIFIEZ ! )

N’hésitez pas à partager ce concours sur Twitter, Facebook, mail ou autre pour nous remercier, se sera notre plus belle récompense ! 

BONNE CHANCE A TOUS !

Par la même occasion je vous annonce que lundi nous mettrons en place un petit concours pour gagner quatre formations video2brain iPhone, alors soyez au rendez-vous!

TENTEZ VOTRE CHANCE ICI !!!

Pensez à activer la HD pour un rendu optimal, sinon l’image est flou.

Préambule : NSArray et NSMutableArray

Avant de commencer à ajouter nos fonctionnalités, il est nécessaire de s’arrêter sur un point concernant les objets proposés par UIKit. Pour stocker notre liste de sites Internet, nous avons utilisé un objet de type NSArray :

@property (nonatomic, retain) NSArray *tabWebSites;

Il s’agit d’un tableau d’objets qui permet toutes sortes d’actions comme « compter le nombre d’éléments », « récupérer un élément du tableau », etc. NSArray a une limitation, et elle est de taille : il ne peut pas être modifié. Du coup cela va nous poser problème dans ce tutoriel : si je souhaite ajouter ou supprimer des éléments, il va bien falloir que je modifie mon tableau de sites.

Pour implémenter un tableau que l’on peut modifier de la sorte, on utile la classe NSMutableArray. Cette classe propose les mêmes méthodes que NSArray qu’elle surcharge et fonctionne donc de manière identique. Elle propose, en outre plusieurs méthodes nouvelles :

insertObject:atIndex:
removeObjectAtIndex:
addObject:
removeLastObject
replaceObjectAtIndex:withObject:

Alors pourquoi avoir utilisé NSArray dans le tutoriel n°8 ? Il faut évidemment considérer les performances et l’impact mémoire dans le choix de vos objets dans UIKit. NSArray est bien plus économe que NSMutableArray et, quand on développe pour iPhone (comme pour tout développement embarqué), cette question est fondamentale.

Voici donc un petit exercice nécessaire avant de continuer : transformer le tableau NSArray *tabWebSites en NSMutableArray. Il s’agit de faire les modifications dans le RootViewController (.m et .h). Faîtes cette modification (il y a plusieurs endroits à modifier) et recompilez votre application pour vérifier que tout fonctionne encore avant de passer à la suite !

Ajouter le bouton sur la vue pour ajouter un site

Nous souhaitons proposer aux utilisateurs d’ajouter le ou les sites de leur choix à la liste. Nous allons donc ajouter, dans la barre de navigation un bouton « Ajouter » qui permettra d’ouvrir un dialogue d’ajout.

Dans XCode, nous allons ajouter un IBOutlet appelé « addButtonItem » qui représentera le bouton, et une IBAction qui sera appelée quand l’utilisateur appuiera sur ce bouton. Dans RootViewController.h, nous ajoutons donc ces deux éléments :

@interface RootViewController : UITableViewController {
	NSMutableArray *websites;
	IBOutlet UIBarButtonItem *addButtonItem;
}
 
@property (nonatomic, retain) NSMutableArray *tabWebSites;
@property (nonatomic, retain) UIBarButtonItem *addButtonItem;
 
- (IBAction) addButtonPressed: (id) sender;

Dans le fichier RootViewController.m, ajouter le @synthetise et n’oubliez pas le « release » dans la méthode « dealloc ». Vous devez implémenter la méthode addButtonPressed. Ne mettons qu’un simple log pour le moment :

- (IBAction) addButtonPressed: (id) sender {
	NSLog(@"On ajoute !");
}

Maintenant il s’agit de créer effectivement l’objet. Pour ce faire, nous pouvons le faire dans le code (via XCode) ou beaucoup plus simplement à l’aide d’InterfaceBuilder. Voyons comment mettre en place cette deuxième méthode.

Ouvrez le fichier RootViewController.xib, et faîtes apparaître la fenêtre « Library ». Faîtes glisser un élément « Bar Button Item » dans la fenêtre principale.

Ouvrez la fenêtre d’inspecteur et modifiez le champ « Identifier » de bouton pour « Add » (c’est le bouton avec le « + »). Profitez en pour vous familiariser avec les différents types de boutons proposés. Vous reconnaîtrez ceux que vous avez l’habitude de voir sur la plupart des applications iPhone (Bookmarks, Search, Camera…).

Enfin, il s’agit de relier l’IBOutlet et l’IBAction que nous avons créés précédemment avec ce nouvel élément. Cliquez-droit sur « File’s owner » (dans notre cas, il s’agit d’un RootViewController) et faîtes glisser le IBOutlet « addButtonItem » vers le bouton nouvellement créé. Pour l’action, c’est presque pareil, cliquez droit sur le bouton dans la liste et faîtes glisser « selector » vers File’s Owner. Choisissez notre méthode addButtonPressed.

Sauvegardez et revenez à XCode.

Il reste une dernière formalité et pas des moindres. Il faut présenter ce nouveau bouton. Il nous faut l’ajouter dans la barre de navigation, dans la partie de gauche. Pour ce faire, rendez-vous dans la méthode viewDidLoad pour ajouter la ligne suivante :

self.navigationItem.leftBarButtonItem = self.addButtonItem;

Sauvegardez et compilez. Le bouton apparaît alors dans la barre de navigation supérieure. Quand vous cliquez dessus, la ligne de log est imprimée. Parfait !

Créer la vue qui permettra de saisir les informations du nouveau site

Si vous avez suivi la première partie de ce tutoriel, il n’y a rien, ici, de bien nouveau. Je vais donc passer rapidement là dessus en vous précisant les points essentiels :

• Dans XCode, créez une nouvelle classe, héritée de UIViewController, appelez-la ModifViewController et n’oubliez pas d’associer un fichier .h et un fichier .xib
• Ajoutez trois attributs et autant de propriétés dans le fichier .h

#import 
 
@interface ModifViewController : UIViewController {
	IBOutlet UITextField *titleTextField;
	IBOutlet UITextField *descriptionTextField;
	IBOutlet UITextField *urlTextField;
}
 
@property (nonatomic,retain) UITextField *titleTextField;
@property (nonatomic,retain) UITextField *descriptionTextField;
@property (nonatomic,retain) UITextField *urlTextField;
 
@end

• Synthétisez les dans le .m et n’oubliez pas les release dans la méthode dealloc
• Dans InterfaceBuilder, Ajoutez trois zones de textes et des labels pour obtenir le rendu suivant (on laisse de la place pour le clavier qui va apparaître par la suite) :

• Attachez les outlets avec les éléments que vous venez de déposer dans la vue.
• Revenez à XCode, compilez pour voir si tout va bien (inutile de tester : on a pas appelé la vue).

Appeler la vue quand on appuie sur le bouton « + »

Vous avez un bouton « + », vous avez une vue à appeler : il ne reste qu’à lier les deux ! Pour afficher des formulaires d’ajout et de modification, il convient d’utiliser une autre métaphore que celle employée pour la navigation (qui enchaîne les écrans en poussant l’ancien écran vers la gauche quand le nouveau arrive par la droite). Il s’agit des « Modal View« . Un exemple, sur votre iPhone, allez dans l’application « Téléphone » ou contacts et appuyez sur le « + » pour ajouter un contact. L’écran d’ajout arrive par le bas pour se superposer sur l’écran actuel. L’utilisateur sait que l’écran précédent est derrière cette nouvelle vue et s’attend à la retrouver une fois qu’il aura appuyé sur un bouton OK (ou Annuler, le cas échéant).

En terme de code, c’est sensiblement la même chose que la navigation dans un UINavigationController : on crée la vue, on la pousse, et on release. La seule différence, c’est que c’est la vue actuelle qui « supporte » la fenêtre modale, et non un UINavigationController. Rendez-vous dans méthode addButtonPressed et modifiez la comme suit :

- (IBAction) addButtonPressed: (id) sender {
	ModifViewController *addView = [[ModifViewController alloc] initWithNibName:@"ModifViewController" bundle:nil];
	[self presentModalViewController:addView animated:YES];
	[addView release];
}

Compilez, testez… La fenêtre modale apparaît comme demandée… et… GAME OVER : vous ne pouvez plus faire autre chose que quitter l’application : aucun élément ne permet de revenir.

Euh chef ?! On fait quoi maintenant ?

Super on affiche notre vue pour ajouter, mais on ne peut pas en partir sans devoir quitter l’application. Il nous faut ajouter deux boutons « Annuler » et « OK » et enregistrer le nouveau site. Généralement, ces boutons sont dans la partie supérieure de l’écran, dans une barre qui fait curieusement penser à la barre bleue qu’on a fait apparaître avec les UINavigationController. Commençons donc par mettre ce navigationController autour de notre vue :

- (IBAction) addButtonPressed: (id) sender {
	ModifViewController *addView = [[ModifViewController alloc] initWithNibName:@"ModifViewController" bundle:nil];
	UINavigationController *navc = [[UINavigationController alloc] initWithRootViewController:addView];
	[self presentModalViewController:navc animated:YES];
	[addView release];
	[navc release];
}

Ajoutons deux boutons : un « Enregistrer » et un « Annuler ». Pour cela, on procède un peu de la même façon que pour notre bouton « + » précédent. Ouvrez ModifViewController.m et modifiez la méthode ViewDidLoad comme suit :

// Implement viewDidLoad to do additional setup after loading the view, typically from a nib.
- (void)viewDidLoad {
    [super viewDidLoad];
    self.navigationItem.leftBarButtonItem = [[[UIBarButtonItem alloc]
		initWithBarButtonSystemItem:UIBarButtonSystemItemCancel
		target:self
		action:@selector(cancel:)]
	autorelease];
}

Dans ce code, on ajoute donc nos deux boutons qu’on associe avec des méthodes (@selector) : le bouton « Annuler » est associé à la méthode « cancel: » et le bouton « Enregistrer » est associé à « save ».

Commençons par implémenter la méthode « cancel ». Cette méthode doit masquer la vue pour revenir à l’écran précédent. Dans ModifViewController.h, ajoutez la déclaration de la méthode :

- (IBAction) cancel: (id) sender;

Et implémentez-la dans ModifViewController.m :

- (IBAction) cancel: (id) sender {
	[self dismissModalViewControllerAnimated:YES];
}

Vous pouvez compiler et tester. Cette fois, ouf ! nous ne sommes plus bloqués. Par contre, il est temps de se concentrer sur la sauvegarde.

Procéder à l’enregistrement du nouveau site

Petite exercice pour commencer. Ajoutez un bouton UIBarButtonSystemItemSave dans la partie droite (rightBarButtonItem) qui appelle une nouvelle méthode appelée save:. Pour le moment, dans cette méthode, fermez simplement la fenêtre modale. Si vous séchez, jetez juste un oeil un peu plus haut, nous venons de le faire.

Il s’agit maintenant de sauvegarder notre nouveau site dans notre liste de sites.

Avant de commencer, il nous faut faire un import de la classe WebSite pour qu’on puisse créer un objet de ce type. En haut du fichier ModifViewController.m, ajoutez la ligne :

#import "Website.h"

Puis nous allons créer un nouvel objet Website avec les valeurs du formulaire. Nous faisons ça au moment de sauvegarder : dans notre nouvelle méthode save:

- (IBAction) save: (id) sender {
	// Récupérer un NSUrl à partir de la valeur du champ texte
	NSURL *urlSite = [[NSURL alloc] initWithString:urlTextField.text];
 
	// Créer un nouveau site et affecter les valeurs
	Website *newSite = [[Website alloc] init];
	newSite.webSiteTitle = titleTextField.text;
	newSite.webSiteURL = urlSite;
	newSite.webSiteDescription = descriptionTextField.text;
 
	// Ne pas oublier de libérer le NSUrl qu'on vient de créer
	[urlSite release];
 
	[self dismissModalViewControllerAnimated:YES];
}

Il s’agit maintenant de rajouter notre nouveau site dans la liste des sites, mais comment ? La classe  ModifViewController ne connaît pas le tableau des sites qui est stocké dans RootViewController ! Qu’à cela ne tienne, nous allons passer ce tableau à notre classe ModifViewController qui pourra ainsi l’enrichir.

Dans ModifViewController.h ajoutez un NSMutableArray *tabWebSites :

NSMutableArray *tabWebSites;

Ajoutez la propriété pour y accéder :

@property (nonatomic, retain) NSMutableArray *tabWebSites;

Synthétisez la propriété dans ModifViewController.m et n’oubliez pas le release.

Dans la méthode addButtonPressed: de RootViewController.m, nous allons affecter notre tableau tabWebSites, comme ceci :

- (IBAction) addButtonPressed: (id) sender {
	ModifViewController *addView = [[ModifViewController alloc] initWithNibName:@"ModifViewController" bundle:nil];
 
	// On passe le tableau de sites pour que la nouvelle vue puisse le modifier
	addView.tabWebSites = self.tabWebSites;
 
	UINavigationController *navc = [[UINavigationController alloc] initWithRootViewController:addView];
	[self presentModalViewController:navc animated:YES];
	[addView release];
	[navc release];
}

Enfin, il est maintenant temps d’ajouter notre site dans notre tableau. Retournons à la méthode save: et ajoutons les deux lignes suivantes :

	/*   ...*/	
 
	// Ajouter le site web
	[tabWebSites addObject:newSite];
	[newSite release];
 
	[self dismissModalViewControllerAnimated:YES];
}

Compilez, testez… Et… Ca ne plante pas, mais pas de nouveau site à l’horizon.

Le site n’apparaît pas dans la liste, alors que je viens de l’ajouter

Il reste en effet une dernière petite chose à faire pour voir apparaître les fuits de votre labeur. Et c’est assez simple vous allez voir. Dans le paragraphe précédent, nous avons ajouté un objet dans notre tableau webSites, puis nous avons masqué la vue modal. Jamais nous n’avons averti la UITableView que son contenu avait changé. C’est pourtant une étape nécessaire : iOS ne va pas passer son temps à vérifier que quelque chose à été modifié, au risque de transformer votre iPhone en brouette. Nous allons ajouter une petite ligne de code dans la méthode viewWillAppear, qui, comme son nom l’indique, est appelée au moment où la vue va être affichée : quand elle est affichée suite au passage dans un UINavigationController, par exemple, ou quand une fenêtre modale s’efface pour laisser réapparaître la vue.

Dans le code proposé par XCode à la création du projet, la méthode viewWillAppear est déjà codée, mais mise en commentaires. Enlevez les commentaires et modifiez la comme suit :

- (void)viewWillAppear:(BOOL)animated {
	[super viewWillAppear:animated];
	[self.tableView reloadData];
}

Cette fois c’est la bonne. Compilez et essayez d’ajouter un site : il vient s’ajouter en bas de la liste et on peut en voir un aperçu en touchant la ligne correspondante dans la liste.

C’est ainsi que s’achève cette seconde partie. La troisième et dernière partie arrive très vite. Nous verrons ensemble comment, très facilement, mettre en place le « Balayer pour supprimer« , et surtout comment faire en sorte de sauvegarder vos nouveaux sites ou les modifications dans la mémoire de l’iPhone (parce pour le moment, si vous quittez, et bien vous avez tout perdu). Donc à très vite pour la suite

Tous les utilisateurs d’iPhone sont habitués à naviguer dans des listes, à toucher un élément pour afficher le détail d’un objet, et utiliser la barre de navigation supérieure pour revenir à l’écran principal. Ce fonctionnement est homogène dans toutes les applications proposées en standard par Apple sur les appareils exécutant iOS (iPhone, iPod Touch, iPad), mais pas seulement. En effet, Cocoa Touch facilite considérablement la vie du développeur qui souhaite programmer une App dans cette idée, ce qui explique l’omniprésence d’une telle approche.

Ce tutoriel sera séparée en trois parties. La première vous proposera un pas à pas pour construire une liste à partir d’un fichier à plat, puis détaillera le fonctionnement pour ouvrir une fenêtre de détails. Dans la seconde, nous verrons comment enrichir le contenu de l’application et aborderons les fenêtres modales. Enfin dans la troisième et dernière, nous verrons l’enchaînement d’objet à mettre en place pour enregistrer les modifications dans la mémoire de l’iPhone et verrons comment, en quelques clics, nous pouvons utiliser les comportements avancés des tableaux.

L’objectif

Avant de commencer, je souhaiterais vous montrer où nous souhaitons arriver à la fin de ce tutoriel. Notre application a pour ambition de présenter des sites internet de référence. Cette liste de sites sera stockée dans un fichier et présentée à l’utilisateur sous forme d’une table avec le titre du site et le début de la description. En touchant une ligne, l’utilisateur accèdera à une vue de détails présentant la description complète et une webview du site en question.

Créer le projet

On est parti ! Lancez XCode, démarrez la création d’un nouveau projet et choisissez une « Navigation-based application ». Ce template, nous ne l’avons pas utilisé dans les tutoriels précédents parce qu’il va préparer pas mal de choses pour vous :

• une première classe RootViewController (un .m, un .h et un fichier InterfaceBuilder .xib)
• cette classe sera instanciée dans un UINavigationController (nous l’avions créé nous-mêmes dans le tutoriel n°5)
• de plus cette classe RootViewController est une sous-classe de UITableViewController, ce qui signifie qu’elle propose, par défaut, une liste d’éléments.

Appelez ce projet « MyWebSites ». Vous pouvez le compiler tout de suite. Vous verrez alors apparaître un écran présentant la barre bleue de navigation en haut et une liste, vide, mais qui réagit déjà au toucher (vous pouvez « scroller » dedans).

Personnalisons cela rapidement. Ouvrez MainWindow.xib, accédez au « Navigation Controller » dans la barre de gauche. Vous remarquez que la vue qui sera affichée dans un premier temps est gérée par RootViewController. Double-cliquez dans la barre bleue pour mettre le titre en surbrillance et le modifier selon votre choix. Ceci revient à modifier la propriété title, comme nous l’avions vu dans le tutoriel précédent, et comme nous n’allons pas tarder à le faire pour la vue de détails.

Ajouter un fichier .plist contenant les informations de sites

Cette liste est bien vide, il est temps de trouver des données à y présenter. Apple propose plusieurs façons de stocker des données, comme des fichiers textes, des accès à une base de données SQLite, les mettre sur un serveur Internet et les récupérer, etc… Mais il y a mieux. Les fichiers de propriétés (les fameux .plist) sont des fichiers XML qui présentent de nombreux avantages dont celui d’être supportés nativement par les objets du framework (NSArray, NSDictionnary, …) ; cela signifie que nous allons pouvoir récupérer avec une simple ligne de code des objets entiers depuis un fichier .plist. La seconde option est CoreData, que nous aborderons en détails dans un prochain tutoriel.

Assez parlé ! Pour créer un fichier .plist qui contiendra les données de notre liste de sites Internet favoris, utilisez la commande « New File… » du menu File, et choisissez « Property List » qui se trouve dans la rubrique « Ressource ». Donnez-lui un nom (j’ai appelé le mien « websites.plist ») et retrouvez-le dans l’arborescence de XCode (il est en fin de projet).

Ici, nul besoin de connaître le moindre début de XML, XCode s’occupe de tout et vous présente le contenu du fichier dans une interface super simple et efficace à utiliser. Notre objectif, ici : obtenir un tableau d’objets (NSArray), ces objets étant des dictionnaires clé-valeur (NSDictionnary) permettant, pour chaque site, de préciser : le titre du site, son URL et une description à afficher.

Bon je m’épargne de vous expliquer par le menu comment fonctionne l’interface (petite astuce : clic-droit pour ajouter les premières lignes, après, vous avez droit à des icônes « plus » et « moins ». Voici le résultat final : un NSArray contenant des objets de types NSDictionnary ayant tous la même structure : trois NSStrings title, url et description. Courage !

(Cliquez sur l’image pour voir le résultat attendu)

Créer une classe modèle

Il est temps de coder un peu et de nous attaquer à la partie « modèle » de notre fameux MVC. Nous allons faire une « classe métier » pour représenter chacun des sites. Cette classe a pour objectifs :

• de représenter un site (avec son titre, son URL, sa description)
• de prendre en charge les actions à mener sur un site

Nous aurons, par la suite, besoin de créer un objet métier pour chacun des NSDictionnary détaillé dans notre fichier .plist. Il faut donc créer pour cette classe :

• Trois attributs (titre, URL et description)
• Trois propriétés pour pouvoir accéder aux valeurs des attributs
• Une méthode d’initialisation à partir d’un NSDictionnary

Pour créer la nouvelle classe, choisissez « New File… » dans le menu « File » et choisissez une « Objective-C class » simple. Appelez-la Website, XCode se chargera de créer les deux fichier .h (en-tête) et .m (implémentation).

Dans le fichier .h, nous allons créer les trois attributs, déclarer les propriétés ainsi que la méthode d’initialisation :

#import UIKit/UIKit.h
 
@interface Website : NSObject {
    NSString *webSiteTitle;
    NSURL *webSiteURL;
    NSString *webSiteDescription;
}
 
@property (nonatomic,retain) NSString *webSiteTitle;
@property (nonatomic,retain) NSURL *webSiteURL;
@property (nonatomic,retain) NSString *webSiteDescription;
 
- (id) initWithDictionaryFromPlist: (NSDictionary *) dictionnary;
 
@end

Dans le fichier .m, nous allons synthétiser les trois propriétés (sans oublier de faire les release correspondants dans la méthode dealloc) et implémenter la méthode initWithDictionaryFromPlist :

#import "Website.h"
 
@implementation Website
 
@synthesize webSiteTitle;
@synthesize webSiteURL;
@synthesize webSiteDescription;
 
- (id) initWithDictionaryFromPlist: (NSDictionary *) dictionnary {
    [self init];
 
    self.webSiteTitle = [dictionnary objectForKey:@"title"];
    self.webSiteURL = [NSURL URLWithString:[dictionnary objectForKey:@"url"]];
    self.webSiteDescription = [dictionnary objectForKey:@"description"];
 
    return self;
}
 
- (void)dealloc {
    [webSiteTitle release];
    [webSiteURL release];
    [webSiteDescription release];
    [super dealloc];
}
 
@end

Vous pouvez essayer de compiler, mais pour le moment rien n’a changé, ceci permettra simplement de corriger les éventuelles petites fautes de frappe.

Charger le contenu dans la liste

Il est largement temps de faire en sorte que cette liste se remplisse avec les sites que nous avons saisis dans notre fichier .plist. Retournons sur la classe RootViewController, et plus précisément dans le fichier header (.h) pour ajouter un attribut : tabWebSites qui contiendra tous les objets que nous allons charger de notre fichier .plist

#import UIKit/UIKit.h
 
@interface RootViewController : UITableViewController {
    NSArray *tabWebSites;
}
 
@property (nonatomic, retain) NSArray *tabWebSites;
 
@end

Dans le fichier .m, ajoutez les éléments suivants (ça doit commencer à devenir un reflexe quand vous déclarez une propriété) :

• le @synthetise pour la propriété
• le message release dans la méthode dealloc de la classe

(il y a un morceau de code similaire un peu plus haut dans le tutoriel).

Intéressons-nous maintenant à la méthode viewDidLoad de RootViewController.m. Cette méthode est appelée une fois que la vue est chargée, c’est à dire, dans notre cas, une fois que la liste est préparée en mémoire pour que nous puissions y ajouter des éléments. Elle est déjà pré-codée par XCode lors de la création du projet. Repérez-la : elle est en général quasi en haut du fichier.

C’est dans cette méthode que nous allons :

• Charger le fichier .plist et le parcourir
• Créer un objet Website à partir de chaque NSDictionnary extrait du fichier .plist
• Enregistrer ces objets Website dans le tableau tabWebSites que nous venons de créer

Voici le code à implémenter, j’ai détaillé les trois points :

#import "RootViewController.h"
#import "Website.h"
 
@implementation RootViewController
@synthesize tabWebSites;
 
- (void)viewDidLoad {
    [super viewDidLoad];
 
    // Charger le fichier .plist dans un tableau que l'on appelera  arrayFromFile
    NSString *path = [[NSBundle mainBundle] pathForResource:@"websites" ofType:@"plist"];
    NSDictionary *dictFromFile = [[NSDictionary alloc] initWithContentsOfFile:path];
    NSArray *arrayFromFile = [dictFromFile objectForKey:@"Root"];
 
    // Créons un tableau temporaire que nous allons remplir avec un objet Website par NSDictionnary contenu dans le fichier .plist
    // Notez l'utilisation de NSEnumerator pour parcourir un tableau
    NSMutableArray *websitesToAdd = [[NSMutableArray alloc] init];
    NSEnumerator *enumerator = [arrayFromFile objectEnumerator];
    NSDictionary *anObject;
    while ((anObject = [enumerator nextObject])) {
        Website *ws = [[Website alloc] initWithDictionaryFromPlist: anObject];
        [websitesToAdd addObject: ws];
        [ws release];
    }
 
    // Remplir la propriété tabWebSites avec le contenu du NSMutableArray précédent
    self.tabWebSites = [NSArray arrayWithArray:websitesToAdd];
 
    // Gestion de la mémoire : pour chaque alloc, n'oubliez pas le release qui va avec !
    [websitesToAdd release];
    [arrayFromFile release];
}
 
// [...]

Compilez, et tadaaa ! Non toujours rien ? Bon, c’est normal : on a chargé notre tableau, mais on a rien demandé à afficher.

En savoir plus sur UITableView

XCode a déjà préparé pas mal de méthodes dans le fichier RootViewController.m qui n’attendent qu’à être activée et personnalisées. Avant de faire en sorte que nos sites apparaissent vraiment dans la liste, laissez-moi vous parler un peu plus de UITableView (cette magnifique liste).

Le composant UITableView propose une des façons les plus simples et les plus rapides pour traiter les données : le tableau, et plus précisément la liste. Un UITableView propose en fait un ensemble de cellules (les UITableViewCell) qui sont organisées en sections :

Pour présenter des données, il ne s’agit pas de « charger » un UITableView en mettant des données dedans (comme dans un tableau NSArray, par exemple). Un UITableView a besoin d’un objet qui l’accompagne : sa source de données : un DataSource. N’importe quel objet peut être un DataSource, il suffit pour cela qu’il implémente le protocole : UITableViewDataSource. Lorsqu’il sera temps d’afficher le contenu d’une cellule, par exemple celle de la troisième ligne de la première section, le UITableView demandera alors à son DataSource : « Qu’est-ce que je dois afficher dans la ligne 3 de la section 1 ? ».

XCode a bien fait les choses quand il a préparé notre projet. Le DataSource de notre UITableView est déjà déclaré : c’est notre classe RootViewController. Pour s’en convaincre, il suffit d’aller dans RootViewController.h, constater que cette classe étend la classe UITableViewController. Si vous appuyez sur Commande (Pomme) et cliquez sur « UITableViewController », l’écran présentera la déclaration de cette classe, et vous verrez qu’elle implémente bien le protocole UITableViewDataSource.

Afficher les données dans la liste

Les méthodes du protocole UITableViewDataSource que nous avons à implémenter pour afficher les informations sont numberOfSectionsInTableView, numberOfRowsInSection et cellForRowAtIndexPath, elles sont déjà préparées dans RootViewController.m. Voici le code, commenté pour détailler les actions mises en place :

// Customize the number of sections in the table view.
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
    // On n'a besoin que d'une section pour nos sites Internet
    return 1;
}
 
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    // Nous ne tenons pas compte du numéro de section puisqu'il n'y en a qu'une
    // Dans cette unique section il y a tous les éléments du tableau, on retourne donc le nombre
    return [self.tabWebSites count];
}
 
// Customize the appearance of table view cells.
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 
    static NSString *CellIdentifier = @"Cell";
 
    // Les cellules sont mises en cache pour accélérer le traitement, sous l'identifiant "Cell",
    // on essaie récupère ce modèle de cellule s'il est déjà en cache
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
 
    // Si on n'a pas réussi à sortir une cellule du cache, on crée un nouveau modèle de cellule
    // et on l'enregistre dans le cache
    if (cell == nil) {
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:CellIdentifier] autorelease];
    }
 
    // On récupère l'objet Website qui correspon à la ligne que l'on souhaite afficher
    Website *ws = [self.tabWebSites objectAtIndex:indexPath.row];
 
    // On configure la cellule avec le titre du site et sa description
    cell.textLabel.text = ws.webSiteTitle;
    cell.detailTextLabel.text = ws.webSiteDescription;
 
    // On renvoie la cellule configurée pour l'affichage
    return cell;
}

Il est temps de compiler tout cela, et de faire notre premier test. Si tout va bien, voilà le résultat affiché :

Créer une vue de détail

Nous allons maintenant créer la vue qui sera affichée quand on touchera un élément de la liste. Il s’agit d’un UIViewController que nous allons pousser, plus tard, dans le UINavigationController. On va aller un peut plus vite pour cette partie, parce que, si vous vous êtes déjà frottés aux tutoriels précédents, ça devrait être une partie de plaisirs.

Créez une nouvelle classe, héritée de UIViewController, appelez-la DetailViewController et n’oubliez pas d’associer un fichier .h et un fichier .xib. Dans DetailViewController.h, créez trois attributs et autant de propriétés :

#import
#import "Website.h"
 
@interface DetailViewController : UIViewController {
	IBOutlet UITextView *descriptionTextView;
	IBOutlet UIWebView *webView;
	Website *ws;
}
 
@property (nonatomic,retain) UIWebView *webView;
@property (nonatomic,retain) UITextView *descriptionTextView;
@property (nonatomic,retain) Website *ws;
 
@end

Dans le fichier .m, synthétisez les trois propriétés, n’oubliez pas les release de rigueur dans la méthode dealloc et personnalisez la méthode viewDidLoad pour personnaliser l’affichage de la vue et charger la page dans la webview :

#import "DetailViewController.h"
 
@implementation DetailViewController
@synthesize descriptionTextView, ws, webView;
 
/*...*/
 
- (void)dealloc {
    [webView release];
    [descriptionTextView release];
    [ws release];	
 
    [super dealloc];
}
 
/*...*/
 
- (void)viewDidLoad {
    [super viewDidLoad];
 
    // Titre du navigation controller
    self.title = ws.webSiteTitle;
 
    // Afficher le contenu de la page web
    NSURLRequest *requestObject = [NSURLRequest requestWithURL: ws.webSiteURL];
    [webView loadRequest:requestObject];
 
    // Affecter le champ de description avec la description du site
    descriptionTextView.text = ws.webSiteDescription;
}
 
@end

Enfin, ouvrez le fichier .xib : ajoutez, un UIWebView en bas de la vue, ainsi qu’un UITextView qui présentera la description, au dessus de la vue Web.

Cliquez-droit sur l’objet « File’s owner » dans la colonne de gauche pour ouvrir l’outil vous permettant de faire les connexions. Connectez la propriété descriptionTextView :

Ainsi que l’attribut webview de notre objet :

A l’aide l’inspecteur de la colonne de droite, personnalisez l’affichage des deux éléments (n’oubliez pas, par exemple, de cocher « Scales Page To Fit » pour la WebView). Sauvegardez le tout avant de continuer.

Afficher les bonnes données dans la vue de détail

Quand l’utilisateur touche un site de la liste, il faut que la popup de détails soit poussée dans le UINavigationController. Nous avons vu ce mode de fonctionnement dans le tutoriel numéro 5 : s’agit d’instancier une classe UIViewController et d’utiliser la méthode pushViewController. Retournez donc sur le code de RootViewController.m.

Commencez par créer un lien vers la nouvelle classe avec la commande #import :

#import "DetailViewController.h"

Puis repérez la méthode didSelectRowAtIndexPath qui est appelée quand l’utilisateur touche une cellule du UITableView. Cette méthode prend en paramètre un objet NSIndexPath qui contient, dans sa propriété row, le numéro de la ligne qui a été touchée (et qui correspond, de fait à la position dans notre tableau tabWebSites). Modifiez la comme suit :

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
	DetailViewController *detailVC = [[DetailViewController alloc] initWithNibName:@"DetailViewController" bundle:nil];
	detailVC.ws = [self.tabWebSites objectAtIndex:indexPath.row];
 
	[self.navigationController pushViewController:detailVC animated:YES];
	[detailVC release];
}

Il est presque temps de compiler et d’admirer le résultat ! Mais juste avant, une petite remarque d’importance : si par hasard, vous souhaitez mettre cette application à disposition sur l’AppStore, il y a de fortes chances qu’elle soit refusée parce que qu’elle n’est pas conforme aux HIG : les fameuses et strictes iPhone Human Interface Guidelines. Je vous laisse trouver toute cette documentation dans XCode, et j’en profite vous parler des disclosure indicators elements. En effet, quand vous souhaitez indiquer à l’utilisateur que toucher une ligne va le faire avancer dans la hiérarchie des vues, vous devez le lui indiquer avec un Disclosure Indicator.

Pour ajouter ce petit point de détail (mais qui a son importance), il nous faut ajouter une dernière ligne dans la méthode cellForRowAtIndexPath de notre RootViewController (juste avant le return, par exemple) :

cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;

Cette fois c’est terminé ! Vous pouvez compiler et admirer le résultat !

Dans la seconde partie, nous parlerons de la modification des éléments de la liste. Vous verrez que ce n’est pas beaucoup plus difficile et qu’il suffit juste d’être un peu rigoureux pour ne pas perdre des modifications en route. Vous apprendrez, en outre, à gérer le magnifique glissé du doigt pour supprimer une ligne ! En attendant, n’hésitez pas à utiliser les commentaires si vous rencontrez des difficultés, et surtout, accrochez-vous : en général, la solution n’est pas très loin !

Merci pour vos commentaires et encouragements ! A très vite !

Qu’est-ce qu’un design pattern ?

La définition la plus courante d’un pattern vous laissera probablement sur votre faim :
Un pattern est une solution à un problème dans un contexte.

Soyons plus précis : dans une situation donnée, vous, développeur, avez un but défini que vous souhaitez atteindre. Mais beaucoup d’autres développeurs ont déjà eu cette même problématique. Le design pattern est une conception générique que tout le monde peut appliquer pour atteindre ce but, dans ce contexte. Un design pattern est donc mieux qu’une « best practice », c’est une  conception idéale, testée et approuvée par vos pairs.

Il existe en fait une petite vingtaine de patterns principaux (Stratégie, Singleton, Commande, Patron de méthode, Proxy …), que nous n’allons pas détailler ici mais qui sont extrêmement utiles et font partie de la boîte à outil quotidienne du parfait analyste programmeur, chef de projet technique ou architecte logiciel. Une biblio est disponible à la fin de cet article si vous souhaitez creuser la question.

Retenons donc : un design pattern est un modèle de conception éprouvé pour un problème dans un contexte donné. Son utilisation permet de garantir l’indépendance et la réutilisabilité des objets, mais aussi leur bonne évolution.

Je vous présente, MVC : pas un design pattern, LE design pattern

Le design pattern MVC pour Modèle-Vue-Contrôleur est un pattern composé : c’est à dire qu’il met en oeuvre trois patterns plus simples (Stratégie, Observateur et Composite) mais que nous ne détaillerons pas ici. A vrai dire c’est le roi des patterns composés : mis au point en 1979 dans les laboratoires de recherche Xerox PARC, il décrit une architecture qui organise les interfaces homme machine en trois parties indépendantes et réutilisables :

• le modèle : le modèle de données, la logique de l’application
• la vue : présentation des données et interactions avec l’utilisateur
• le contrôleur : logique de contrôle, gestion des événements, mise à jour du modèle et/ou de la vue

MVC est utilisé partout dans Cocoa Touch. De façon plus générale, il est au coeur de Cocoa, comme il était au coeur de NextStep et du langage SmallTalk. C’est même devenu un tube, la preuve : http://www.youtube.com/watch?v=YYvOGPMLVDo

La vue d’un côté, le modèle de l’autre : le contrôleur fait le lien

Pour une réutilisabilité maximum et garantir l’évolution des objets, il faut des frontières claires. C’est ce qu’impose le MVC. L’objet contrôleur devient alors le ciment et le lien pour afficher dans la vue les données du modèle. Un peu comme ça :

En formalisant les choses de manière moins gloutonne plus professionnelle :

1. L’utilisateur interagit avec la vue, en saisissant une valeur ou en cliquant sur un bouton, par exemple
2. Le contrôleur reçoit les actions de l’utilisateur, les interprète et demande au modèle de modifier son état
3. De même, suite à cette action, le contrôleur peut avoir besoin de demander à la vue de changer en conséquence (activer ou désactiver un champ, etc.)
4. Le modèle informe la vue de son changement d’état, suite à une modification liée à un clic de bouton ou même à une modification interne (fin d’un chargement, etc.)
5. La vue demande son état au modèle, que ce soit suite à une information du modèle ou du contrôleur

Un exemple plus concret pour fixer les idées

C’est encore un peut abstrait ? Prenons l’exemple d’un lecteur MP3, comme celui-ci :

Identifions les acteurs dans le MVC :

• La vue c’est l’écran ci-dessus avec l’affichage du nom de l’artiste, les boutons Lecture, suivant et Précédent, le contrôle du volume
• Le modèle est un objet qui a la charge de lire le fichier MP3 et d’envoyer les informations au système de son
• Le contrôleur est un objet qui va faire le lien entre les deux

Avec notre schéma précédent, cela nous donne :

1. L’utilisateur a très envie d’écouter de la musique, il appuie sur le bouton « Lecture »
2. Le contrôleur reçoit l’information « le bouton Lecture a été cliqué », il demande au modèle de commencer la lecture. La musique démarre.
3. Le contrôleur demande à la vue de transformer le bouton « Lecture » en un bouton « Pause » et d’afficher les informations du morceau en lecture.
4. Le morceau a été lu en entier, le modèle informe la vue qu’il a commencé la lecture du morceau suivant
5. La vue a été informée du changement de morceau et demande au modèle les information du nouveau morceau en lecture.

Le développement iPhone adopte le modèle MVC

Nous avons déjà eu affaire avec le MVC dans les précédents tutoriels iPhone, nous ne cesserons pas de l’utiliser par la suite.

• La vue est, dans l’immense majorité des cas, prise en charge par Interface Builder, qui nous permet de tout designer sans une ligne de code : ajouter des éléments, gérer leur positionnement.
• Nous n’avons pas encore vu de modèle à proprement parler, mais nous aurons l’occasion d’en créer, et ce dès le tutoriel n°8. Nous verrons aussi que les données peuvent être prises en charge par CoreData, moteur de données extrêmement puissant.
• Les contrôleurs, ça on en a déjà vu : UIViewController, UINavigationController, UITabBarController, … C’est pour l’instant là où nous avons codé le plus, puisque nous avons essentiellement des applications qui réagissent à l’utilisateur.

Deux questions qu’il vaut mieux poser tout de suite

1ère question : Dans le tutoriel n°4 – l’application calculette, nous n’avons pas utilisé de modèle, pourquoi ? Un modèle n’est pas utile dans ce cas ?

C’est un choix plus éditorial que de bonne conception que de ne pas utiliser de modèle dans ce tutoriel. L’objectif était de faire le plus simple possible, quitte à créer des lourdeurs et à sacrifier complètement la réutilisabilité du code mis en place. Par exemple, il est impossible d’intégrer cette calculette dans une autre appli ou même dans une autre vue de cette application sans tout recoder.

2nde question : Au final le contrôleur n’est qu’un simple passe-plat, non ? Pourquoi ne pas garder qu’un modèle et une vue et se séparer des intermédiaires ?

Le contrôleur ne fait pas que passer les plats : il est chargé d’interpréter les actions de l’utilisateur dans la vue pour manipuler le modèle en conséquence. Deux raisons expliquent qu’il n’est pas souhaitable de confier à la vue le soin de manipuler le modèle. La première est que cela imposerait à la vue d’avoir deux boulots : gérer l’interface et manipuler le modèle. La seconde est que cela imposerait un couplage fort entre la vue et le modèle, il serait alors impossible de modifier le modèle sans modifier la vue, ou l’inverse. Un couplage faible via un contrôleur vous assure une évolution plus souple des éléments par la suite. En gros : pas besoin de tout recoder parce que j’ai ajouté une fonctionnalité.

Envisager le MVC dans une application avec un enchaînement d’écrans

Une application iPhone est souvent composée de différents écran enchaînés entre eux. Un exemple : je consulte une liste d’éléments, et quand je sélectionne un événement, je consulte le détail de l’élément. Dans cet exemple, le MVC joue pleinement son rôle de patron de conception :

• Ma liste présente une série d’éléments. Un contrôleur récupère un tableau d’objets modèles représentant des éléments. Il trie ces objets (par nom, etc.) et les envoie à la vue qui sera en charge d’afficher.
• Quand l’utilisateur sélectionne un élément dans la vue, le contrôleur se charge de pousser le contrôleur de détail en lui passant l’objet modèle à détailler
• le contrôleur de détail instancie une vue et présente les éléments du modèle qui lui a été passé. Il peut aussi prendre en charge des modifications, il charge l’objet modèle de se transformer en conséquence (la vue propose un champ pour changer le nom de l’élément, le contrôleur récupère la nouvelle valeur de la vue et modifie le modèle en conséquence)
• Quand l’utilisateur appuie sur le bouton « Précédent » pour revenir à la liste, le contrôleur de liste reprend la main et rafraîchit les données. Le modèle modifié envoie son nouveau nom et la liste présentée sera à jour des modifications.

Si ce n’est pas encore tout à fait clair, un exemple sera abordé dès le tutoriel suivant.

Aller plus loin

Ce tutoriel n’a pas la prétention d’être exhaustif et de tout vous apprendre sur le MVC mais bien de vous initier à cette conception que vous retrouverez dans la plupart de vos développements. Si vous souhaitez aller (beaucoup) plus loin, je vous recommande les ouvrages suivants :

• Tête la première Design Patterns – Eric Freeman & Elisabeth Freeman avec Kathy Sierra et Bert Bates – le livre qui vous dévoilera les secrets du maître des patterns et vous propose d’injecter directement dans votre cerveau les principaux patterns (cette collection est excellente, et ce livre en particulier est la principale source de cet article)
• Design Patterns – par « the Gang of Four »
• Portland Pattern Repository – un wiki dédié à tout ce qui est lié aux patterns
• Le Hillside Group centralise les ressources sur les patterns
• Wikipedia est toujours une source d’information à ne pas négliger
• Et évidemment, la section d’Apple à propos de Cocoa

Pour conclure, adopter le Model-View-Controller, apporte de nombreux avantages pour structurer votre architecture de code, et sa maîtrise vous assurera de concevoir des applications, plus réutilisables, plus faciles à faire évoluer. Un dernier avantages des design patterns est qu’ils représentent un vocabulaire commun  pour échanger avec les autres concepteurs. Les commentaires ci-dessous sont l’occasion de faire la preuve de cette affirmation Merci !

Le SDK de l’iPhone propose de nombreux composants permettants de gagner un temps précieux lors du développement. UIVebView est de ceux-ci puisqu’il permet d’intégrer une vue WebKit dans votre application. A titre d’exemple, ce tutoriel vous propose de construire un premier navigateur web, et vous verrez que le point plus délicat à bien comprendre n’est pas forcément là où on l’attend !

Ce tutoriel sera en effet l’occasion d’en savoir plus sur le comportement de UITextField, quand il s’agira de créer la barre d’adresse et d’interagir avec le clavier virtuel de l’iPhone.

Créer le projet et y ajouter une UIWebView

Démarrez XCode et créez un nouveau projet de type « View based application ». Nous l’appellerons « MyWebBrowser ».

Dans MyWebBrowserViewController.h, nous allons ajouter un nouvel Outlet de type UIWebView, ainsi que la propriété associée.

#import
@interface MyWebBrowserViewController : UIViewController {
	IBOutlet UIWebView *webView;
}
@property (nonatomic, retain) UIWebView *webView;
@end

L’objet UIWebView, est, comme son nom l’indique bien, une vue dans laquelle va pouvoir être affiché le contenu d’une page web. Ce contenu va interagir avec l’utilisateur de la même manière qu’une page web standard : zoom, navigation, suivre les liens, remplir et envoyer les formulaires, etc. Cette instance « webView » sera donc l’objet central de notre navigateur web.

N’oubliez pas de synthétiser la propriété dans MyWebBrowserViewController.m et de faire un release dans la méthode dealloc :

@implementation MyWebBrowserViewController
@synthesize webView;
 
- (void)dealloc {
      [webView release];
      [super dealloc];
}

Sauvegardez les fichiers .h et .m, puis ouvrez le fichier « MyWebBrowserViewController.xib« . A l’aide de la bibliothèque d’objets de la colonne de droite, faîtes glisser un objet UIWebView sur la vue.

Vous allez voir que XCode vous propose que la UIWebView prenne toute la place disponible : c’est parfait ! Inutile de le contrarier outre mesure pour le moment . Associer l’outlet « webView » de l’objet File’s Owner (clic droit sur File’sOwner et tracez un trait depuis l’élément webView de la fenêtre noire vers la vue nouvellement créée).

Sauvegardez ; il ne reste plus qu’à compiler et à lancer l’application.

Premier problème : il n’y a rien dans le navigateur…

Oui, mais en même temps, nous n’avons pas précisé d’adresse en particulier ! C’est l’occasion de parler rapidement du fonctionnement de UIWebView. Les données dans UIWebView sont chargées à partir d’une requête Internet : une NSURLRequest. Cette requête est un objet créé à partir d’une adresse URL : un objet NSURL. On peut expliquer cela comme on veut, le code est encore ce qu’il y a de plus clair à comprendre. Repérez la méthode viewDidLoad qui doit être en commentaire dans le fichier MyWebBrowserViewController.m, et transformez la ainsi :

// Implement viewDidLoad to do additional setup after loading the view, typically from a nib.
- (void)viewDidLoad {
	[super viewDidLoad];
 
	// Créer une URL
	NSURL *urlAddress = [NSURL URLWithString: @"http://www.google.com"];
 
	// Faire une requête sur cette URL
	NSURLRequest *requestObject = [NSURLRequest requestWithURL:urlAddress];
 
	// Charger la requête dans la UIWebView
	[webView loadRequest:requestObject];
}

Sauvegardez et compilez. C’est mieux ! Vous voici sur le moteur de recherche. Touchez le champ Google et saisissez l’intitulé de votre recherche, touchez les liens, tout fonctionne !

Second problème : l’affichage des sites n’est pas adapté à la taille du téléphone

Google affiche correctement le moteur de recherche ainsi que les résultats, mais dès qu’on essaie d’aller un peu plus loin, ça se corse : les sites n’apparaissent pas adaptés à la taille du téléphone, à l’inverse de Safari mobile où tout est zoomé pile poil comme il faut.

Il s’agit d’une simple propriété à affecter à notre UIWebView. Ouvrez à nouveau « MyWebBrowserViewController.xib », sélectionnez la UIWebView et dans l’onglet « Attributes Inspector » de la colonne de droite, cochez la case « Scale Page To Fit ».

Sauvegardez, et recompilez. Cette fois, c’est bon.

Un navigateur a besoin d’une barre d’adresse !

Et oui ! S’il est vrai que dans cet état notre navigateur fonctionne, ce serait quand même plus pratique avec une barre d’adresse. Réouvrez le fichier MyWebBrowserViewController.h et ajoutez un nouvel outlet de type UITextField que nous appellerons adressField. Ajoutez la propriété correspondante, synthétisez la dans MyWebBrowserViewController.m et faites un release dans la méthode dealloc. C’est le même fonctionnement que précédemment !

Retournons modifier MyWebBrowserViewController.xib : réduisez la taille de la UIWebView, et ajoutez un objet UITextField qui prendra toute la largeur.

Connectez ce UITextField à l’outlet que nous venons de créer (exactement de la même façon que la UIWebView) et sauvegardez.

Comment configurer le clavier virtuel ?

Si vous compilez et lancez votre application à ce moment du projet, le toucher du champ texte va faire apparaître le clavier virtuel. Mais comment faire pour configurer ce clavier ? En effet, dans Safari Mobile, quand il s’agit de saisir l’URL, les caractères « . », « / » ou encore l’extension sont en accès rapide. De plus, le bouton en bas à droite propose généralement un bouton « Aller ».

S’il est une chose qu’il est important de bien comprendre à ce stade, c’est que vous n’avez pas la main directement pour configurer le clavier virtuel : vous ne pouvez pas l’invoquer directement ou de lui envoyer des messages. C’est au moment de l’exécution que iOS « attache » le clavier virtuel au composant qui l’a appelé. C’est donc ce composant qui va savoir quel type de clavier virtuel il souhaite se voir proposé. Cette configuration est appelée : Text Input Traits.

Dans l’interface de modification de MyWebBrowserViewController.xib, sélectionnez le UITextField et affichez l’inspecteur dans la colonne de droite. Dans l’ « Attributes Inspector », vous remarquerez une section relative à ces « Text Input Traits ».

De nombreuses options sont configurables :

• le type de clavier (par défaut, URL, numéro de téléphone, email…)
• si c’est un clavier de mot de passe ou non (l’option Secure)
• la mise en place de l’auto-correction (vous pouvez la désactiver, mais n’oubliez pas que l’utilisateur choisit, dans les préférences, son mode de fonctionnement : il n’est pas forcément du meilleur goût que de passer outre ce choix)
• le bouton de validation que vous souhaitez voir apparaître
• des options d’apparence
• etc.

Choisissez un clavier URL et le bouton « Go » pour la validation.

Récupérer le Go lancé par le clavier

Si vous compilez et lancez votre application maintenant, il va se passer quelque chose d’assez désagréable. Vous touchez le champ d’adresse, tapez http://www.tutomobile.fr et maintenant vous pourrez écraser vigoureusement le bouton Go, il ne faut pas rêver : il ne va rien se passer du tout. Toucher ce bouton doit faire deux choses :

• mettre à jour la UIWebView avec la nouvelle adresse
• masquer ce clavier qui n’est plus nécessaire jusqu’à ce qu’on retouche le champ d’adresse

Le premier réflexe serait de créer une (IBAction) dans notre MyWebBrowserViewController et de relier un événement à cette action. Une manière de faire qui pourrait ressembler à celle que nous avons employée pour les UIButton dans le Tutoriel n°3, par exemple. Mais là : problème ! Il n’y a pas vraiment l’événement qui correspond à ce Go.

Il y a une autre voie. UITextField peut (et souvent doit) être accompagné d’un Delegate (mais si, rappelez-vous le Tutoriel n°6 où nous parlions des AppDelegate) ; c’est à dire un « représentant » : un objet qui vient en soutien. Nous allons dire à notre UITextField que notre classe MyWebBrowserViewController est son représentant.

Ouvrez le fichier MyWebBrowserViewController.h et modifiez la déclaration de la classe qui devient :

@interface MyWebBrowserViewController : UIViewController <UITextFieldDelegate> {

Ceci signifie que MyWebBrowserViewController implémente désormais le protocole UITextFieldDelegate. En d’autre termes, votre classe lance un cri du coeur : « oui ! UITextField, je suis digne d’être ton delegate ! ». Pour savoir ce qu’il est nécessaire ou possible d’implémenter comme méthode dans le cadre de ce protocole, appuyez sur la touche « Commande » du clavier (euh… pomme, quoi) et double-cliquez sur <UITextFieldDelegate> pour consulter la déclaration. Toutes les méthodes sont optionnelles, celle qui nous intéresse s’appelle textFieldShouldReturn.

Retournez dans le code de MyWebBrowserViewController.m et implémentez comme suit :

- (BOOL) textFieldShouldReturn:(UITextField *)textField {
	NSURL *urlAddress = [NSURL URLWithString: textField.text];
 
	// Ouvrir l'URL
	NSURLRequest *requestObject = [NSURLRequest requestWithURL:urlAddress];
 
	//Load the request in the UIWebView.
	[webView loadRequest:requestObject];
 
	// Réduire le clavier
	[textField resignFirstResponder];
 
	return YES;
}

Pour afficher l’adresse URL saisie dans la UIWebView, vous remarquerez que le code est sensiblement le même que précédemment. Pour réduire le clavier, c’est extrêmement simple : lorsque vous touchez le UITextField, le clavier apparaît et s’inscrit comme étant le « First Responder » de l’objet. Si vous lancez le message resignFirstResponder, vous révoquez le clavier : il disparaît.

Il reste une dernière toute petite chose que nous n’avons pas faîte, assigner au UITextField son nouveau delegate. Retournez modifier MyWebBrowserViewController.xib, cliquez droit sur le UITextField, et faîtes glisser depuis « delegate » vers l’objet « File’s Owner ». Sauvegardez, compilez et testez.

Attention, dans cette version, il est nécessaire de préciser « http:// » devant les URLs que vous tapez pour que cela fonctionne. Voilà un petit exercice rapide à réaliser : ajouter automatiquement « http:// » si ce n’est pas précisé par l’utilisateur !

C’est ainsi que s’achève ce tutoriel iPhone n°7. Vous l’aviez compris, le navigateur web était un prétexte pour vous faire aussi découvrir quelques subtilités des UITextFields, que vous retrouverez dans la plupart de vos applications. Cependant, s’il vous reste quelques minutes, je vous conseille d’aller jeter un oeil sur le tutoriel Android n°9 pour voir les différences qui peuvent séparer les deux plateformes sur des objets comme une vue Web.

Si UINavigationController permet d’organiser les vues de façon hiérarchique et de permettre à l’utilisateur d’obtenir des détails sur un élément de son choix, il est souvent nécessaire de proposer plusieurs fonctions ou modes de recherche de manière parallèle. Citons par exemple l’application iPod qui permet de rechercher un morceau de musique par artiste, par album, par genre, etc. Cette navigation par onglets positionnés en bas de l’écran est gérée par une classe CocoaTouch : UITabBarController. Dans ce tutoriel, vous verrez comment articuler plusieurs vues à l’aide de UITabBarController et comment vous pourrez personnaliser l’apparence de ce dernier.

Créer deux UIViews à afficher

Pour commencer, ouvrez XCode et créez un projet de type « Window Based Application ».

Nous allons maintenant créer deux vues que nous enregistrerons par la suite dans le UITabBarController. Pour créer la première vue, choisissez « New File… » dans le menu « File » de XCode, puis choisissez le type UIViewController Subclass. N’oubliez pas de cocher la case « With XIB for user interface » pour que le fichier Interface Builder soit automatiquement créé. Appelez cette classe TabLabelViewController.

Ouvrez le fichier TabLabelViewController.xib et ajoutez un UILabel au centre présentant le texte de votre choix. Sauvegarder avant de continuer.

Pour la seconde vue, je vous propose quelque chose d’un peu plus sympa qu’un bête texte : nous allons afficher un logo de votre choix. Commençons d’abord par ajouter l’image dans le projet. Pour ce faire, localisez le fichier sur votre disque dur et faîtes le glisser dans la colonne de gauche de XCode, dans le répertoire de votre projet. N’oubliez pas de cocher la case « Copy items into destination group’s folder (if needed) » dans la fenêtre qui s’ouvre, pour que l’image soit dupliquée dans votre projet (et éviter de perdre vos petits par la suite).

Créons maintenant une nouvelle classe que nous appellerons TabImageViewController. A nouveau ouvrez le fichier .xib, et faîtes-y glisser, depuis la bibliothèque, un élément Image View, il doit occuper toute la place disponible dans la vue principale.

Dans la partie supérieure de la zone de droite, choisissez, si ce n’est pas le cas l’onglet « Attributes inspector » (matérialisé par un petit curseur). Dans le champ « Image », choisissez l’image que nous avons ajoutée précédemment. Avant de sauvegarder, modifier le mode de positionnement pour trouver celui qui correspondra le mieux à votre image.

Créer l’objet UITabBarController et insérer les deux vues

Nous avons maintenant deux objets ViewController. Il s’agit de les associer à un UITabBarController et ainsi naviguer entre les deux. Pour ce faire, ouvrez le fichier appelé xxxAppDelegate.h (où « xxx » est à remplacer par le nom de votre projet). Ajoutez-y la déclaration d’un nouvel objet UITabBarController.

@interface TabBarTutorialAppDelegate : NSObject <UIApplicationDelegate> {
    UITabBarController *tabBarController;
}

Ouvrez le fichier xxxAppDelegate.m pour modifier l’implémentation. Dans d’en-tête du fichier, importez les deux vues que nous venons de créer.

#import "TabLabelViewController.h"
#import "TabImageViewController.h"

Repérez à présent la méthode - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions. Cette méthode est appelée (comme son nom l’indique) dès que l’application a fini de se charger. Pour être très complet, la classe xxxAppDelegate est une classe qui vient en soutient de chaque application. Vous avez la possibilité d’y implémenter des méthodes qui seront utiles tout au long de la vie de l’application. Une traduction possible de « Delegate » est « Représentant » ce qui correspond bien à l’usage que nous avons des AppDelegate : ce sont les représentants de l’application ; nous leur apprenons à réagir convenablement quand il arrive quelque chose à l’application (démarrage, arrêt, mise en veille ou même problème de mémoire).

Mais je m’égare et philosophe sur les AppDelegate. Repérez donc cette méthode « didFinishLaunching » qui, pour le moment se charge d’afficher une fenêtre. Nous devons faire trois choses dans cette méthode :

1. Instancier le UITabBarController
2. Créer un TabLabelViewController et l’enregistrer dans le UITabBarController
3. Créer un TabImageViewController et l’enregistrer

Pour enregistrer les vues dans le UITabBarController, nous utiliserons sa propriété viewControllers qui est en fait un tableau de vues.

Voici donc le code à implémenter.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
	// Override point for customization after application launch.
	// Créer un tabBarViewController
	tabBarController = [[UITabBarController alloc] init];
 
	// Créer une vue 1 et affecter
	TabLabelViewController *v1 = [[TabLabelViewController alloc] initWithNibName:@"TabLabelViewController" bundle:nil];
 
	// Créer une vue image et affecter
	TabImageViewController *v2 = [[TabImageViewController alloc] initWithNibName:@"TabImageViewController" bundle:nil];
 
	tabBarController.viewControllers = [NSArray arrayWithObjects:v1, v2, nil];
 
	[v1 release];
	[v2 release];
 
	[self.window addSubview:tabBarController.view];
	[self.window makeKeyAndVisible];
	return YES;
}

Notez qu’une fois les deux UIViewController créés et ajoutés dans le NSArray, nous leur passons un signal release : ils sont en effet retenus par le UITabBarController.

Vous pouvez compiler et faire un premier essai de votre application. Vous obtiendrez bien une barre d’onglets en bas de l’écran permettant de naviguer entre les deux vues.

Personnaliser l’apparence du UITabBarController

Il y a quand même un petit problème : les onglets sont vides ! Il devraient être associés à une image et à un intitulé, au minimum. Avant de commencer, il est nécessaire de bien comprendre le fonctionnement de UITabBarController : pour savoir ce qu’il doit afficher dans l’onglet correspondant à un ViewController, il va le lui demander ! C’est le ViewController qui définit son apparence dans la barre d’onglets. Ceci se fait à l’aide d’un objet UITabBarItem qui est enregistré dans la propriété tabBarItem du UIViewController.

Le UITabBarItem permet de préciser :

• le titre qui s’affiche en bas
• une image. Cette image sera au format PNG en noir et transparent. Les pixels noirs seront automatiquement colorés par iOS avec cet effet bleuté pour indiquer que l’onglet est actif. Taille 30px par 30px
• un tag : un nombre qui pourra être affichés sous forme d’une petite pastille rouge.

Pour le TabLabelViewController, nous allons créer une image PNG de notre cru (ici un petit crayon) et choisir le titre « Label ».

Pour ce faire, créez l’image avec votre logiciel préféré (on a qu’à dire GIMP) ou téléchargez-la en faisant un clic-droit sur l’image ci-dessus, et ajoutez-la au projet en le faisant glisser vers la colonne de gauche de XCode. Ouvrez le fichier TabLabelViewController.m, repérez la méthode initWithNibName, et complétez-la avec le code suivant :

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
{
    self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
    if (self) {
        self.tabBarItem = [[[UITabBarItem alloc] initWithTitle:@"Label" image:[UIImage imageNamed:@"crayonnoir.png"] tag:0] autorelease];
    }
    return self;
}

Pour le TabImageViewController, encore plus rapide, nous allons utiliser un élément standard du système. Il en existe quelques un : une étoile pour les favoris, un livre ouvert pour les favoris, des utilisateurs, un loupe pour la recherche… Nous allons utiliser UITabBarSystemItemFeatured qui est représenté par deux spots vers le haut. Cette fois, même plus besoin de choisir de titre : tout est fait automatiquement (et traduit).

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
{
    self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
    if (self) {
        self.tabBarItem = [[[UITabBarItem alloc] initWithTabBarSystemItem:UITabBarSystemItemFeatured tag:0] autorelease];
    }
    return self;
}

Attention cependant, l’usage des icônes UITabBarSystemItem est très encadré par Apple pour maintenir une cohérence de la signification de ces onglets dans tout le système. Référez vous au guide « Human Interface guidelines » pour l’utilisation de ces icônes.

Et voilà un bon aperçu de tout ce que vous pouvez faire avec UITabBarController. Une dernière chose quand même : vous pouvez ajouter autant de ViewControllers dans votre TabBar : s’il y en a trop pour tous les afficher en une seule fois, iOS proposera de lui-même un bouton « More » et permettra à l’utilisateur de paramétrer son affichage et choisir l’ordre des onglets. Vous trouverez ce fonctionnement dans l’application iPod, par exemple.

Ce tutoriel touche à sa fin, merci d’être arrivé jusqu’au bout N’hésitez pas à réagir dans les commentaires, ni à poser vos questions : nous essaierons de vous répondre et de vous aider dans votre dev. pour iPhone !