Je vous suggère vivement si vous n’avez pas lu l’article ou si vous ne connaissez pas encore grand chose au développement sous iPhone de vous y intéresser pour mieux aborder cette suite…

Une dernière chose avant de démarrer : massez-vous les tempes, faites-vous un petit café…
Prêt ?

Installer le SDK iPhone

A l’heure ou j’écris ces lignes, Apple en est à la version 2.2 du SDK iPhone.
L’installation vous mettra à disposition tous les outils dont je vais parler ici.

Ouvrir un projet d’exemple pour se familiariser avec la structure d’un projet iPhone

Je considère à présent que vous avez déjà un Mac (bah oui…), et le SDK iPhone installé dessus.

1. Ouvrez XCode.
   
2. Faites Fichier > Nouveau projet…
   
3. Choisissez « View-Based Application »
4. Entrez le nom de projet « LaFabrick » puis choisissez un emplacement, vous arrivez alors sur l’interface principale d’Xcode.

Voyons maintenant les fichiers que nous avons :

Nous sommes en Objective-C, donc pour chaque classe, vous trouverez un fichier .h définissant l’interface et un fichier .m contenant l’implémentation (amis du C bonjour !).
Ouvrons « LaFabrickAppDelegate.h »

On constate dans cette interface les déclarations d’un objet fenêtre (objet de base utilisé pour l’affichage) et le contrôleur LaFabrickViewController que nous étudierons rapidement après.
L’implémentation est simple :

Lorsque l’application vient d’être démarrée applicationDidFinishLaunching, on demande l’affichage de la vue contrôlée par notre LaFabrickViewController dans la fenêtre [window addSubview:viewController.view];.
Notez enfin la notation à crochet pour appeler une méthode d’un objet : oui oui, c’est relou.

Jetons maintenant un oeil à LaFabrickViewController (.h et .m) : il est quasiment vide ! C’est effectivement là qu’on doit travailler un peu…
Quelques questions se posent :

• Où est la vue ?
• Comment est-elle associée au contrôleur ?

Nous allons voir cela avec l’interface builder.

Utilisation de l’Interface Builder pour gérer la vue

Première réponse : notre vue est ici créée à partir d’un fichier de description d’interface géré par l’interface builder : LaFabrickViewController.xib. Double-cliquez dessus, l’interface suivante s’affiche alors :

On constate notamment dans la fenêtre centrale, les éléments suivants :

• File’s owner : LaFabrickViewController
• View : UIView

OK, donc le .xib permet de dire que la vue est associée au contrôleur LaFabrickViewController, voilà la deuxième réponse !

Sélectionnez à présent la ligne View : UIView puis sélectionnez le second onglet dans la fenêtre de droite.
Note : si cette fenêtre n’est pas visible, faites Tools > Identity Inspector

Vous pouvez visualiser l’association entre la vue View et la propriété view du contrôleur LaFabrickViewController.

Cette partie est primordiale pour que l’affichage de la vue soit effectif : souvenez-vous que dans LaFabrickAppDelegate, on charge la propriété « view » de LaFabrickViewController, aussi sans l’association effectuée dans l’Interface Builder, il serait impossible d’afficher quoi que ce soit !

D’une manière générale, chaque élément ajouté depuis l’Interface Builder devra être lié à une propriété du contrôleur (ou d’un délégué) via l’Interface Builder afin que vous puissez interagir avec depuis le code.
La propriété en question est alors nommée « Outlet » côté Interface Builder, soit « Sortie » si l’on traduit litéralement : c’est effectivement un paramètre de sortie de votre interface.

Personnaliser un peu l’interface

Depuis l’Interface Builder, ajoutez deux champs texte, deux labels et un bouton histoire d’obtenir à peu près ça :

Si vous faites Tools > Reveal in Document Window… vous verrez l’arborescence de contrôles de la vue mise à jour.

Il est maintenant temps de contrôler ces éléments depuis notre LaFabrickViewController.
Pour cela deux méthodes :

1. Directement depuis Interface Builder (cf. vidéo de démonstration)
   • Sélectionnez LaFabrickViewController depuis le Document Window
   • Dans « l’Inspector » (fenêtre de droite) choisissez le dernier onglet (i) puis ajoutez les propriétés via la section « Class Outlets »
     
   • Ceci fait vous devez enregistrer les modifications dans le fichier LaFabrickViewController.m. Pour cela, vous devez utiliser la fonction File > Write class files…
   • Faites alors « Save »
   • L’outil vous demande si vous souhaitez fusionner ou écraser : choisissez Merge (fusionner)
   • Le fichier .m n’est pas modifié, vous pouvez le fermer, en revanche vous constaterez que le .h peut être modifié comme suit :
     
     sous réserve que vous choisissiez l’action « Choose left » depuis le menu déroulant du bas
   • Sauvegardez (enfin) votre fichier fusionné
2. Mix XCode et Interface Builder
   • Déclarez manuellement les propriétés correspondant aux contrôles que vous souhaitez manipuler dans l’interface (LaFabrickViewController.h) :
IBOutlet UITextField *lastNameField;
IBOutlet UITextField *nameField;
IBOutlet UIButton *validateButton;

   • Compilez le projet
   • Rouvrez l’Interface Builder pour faire les liens

Note : la première méthode a le mauvais goût d’ouvrir l’outil de fusion de fichiers pour que vous validiez que rien n’est écrasé ou ajouté sans votre accord.
J’avoue que, malgré la nécessité de la fusion, je trouve ça très peu pratique voire franchement lourdingue, je m’attendais à mieux venant d’un monstre de l’ergonomie. Mais c’est le prix à payer pour avoir deux outils quasiment indépendants, et enfin, si vous connaissez une meilleure méthode, n’hésitez pas à poster !

– ca se voit tant que ça que je préfère la méthode à l’ancienne ? –

Ce n’est pas encore tout à fait terminé ! (si si je vous jure, c’est long)
Il reste à faire les fameux liens entre les contrôles de la vue et les propriétés que nous avons créé dans LaFabrickViewController. Pour cela, rien ne vaut l’image (et en plein écran tant qu’à faire) :

Voilà ! Vous avez lié les contrôles de votre vue à des propriétés de votre contrôleur.
Nous utiliserons désormais la technique décrite ci-dessus pour gérer nos association vue-contrôleur.

Reprenons Interface Builder pour créer un handler gérant le clic sur le bouton. Pour cela :

1. Sélectionnez LaFabrickViewController depuis la Document Window
2. Dans le dernier onglet de l’Inspector, cliquez sur le bouton + de la section Class Actions en entrez buttonClick:. Laissez le Type sur id
3. Sauvegardez, faites Write class files…, fusionnez les sources et enregistrez
4. Faites un lien entre l’événement Touch up Inside de votre bouton et LaFabrickViewController, l’éditeur vous propose alors votre fonction buttonClick:

Maintenant que votre événement est lié à votre contrôleur, ajoutons un bout de code bateau juste pour valider que l’ensemble fonctionne bien :

1. Retournez sous XCode, et ouvrez LaFabrickViewController.m
2. Modifiez le code pour avoir la méthode buttonClick: sous la forme suivante :
   - (IBAction)buttonClick:(id)sender {
[firstNameField setText:[lastNameField text]];
} 

   Le principe étant simplement de modifier le texte du prénom avec le texte du nom (je vous avais prévenu, c’est un bout de code bateau)

3. Faites Build and Go et testez !

Bien, il ne reste plus qu’à apprendre Objective-C. Pour cela, rien ne vaut quelques ressources dédiée au sujet :

• Passage de C++ à Objective-C
• Passage de Java à Objective-C

Voilà, vous avez à présent les bases nécessaires pour démarrer le développement d’une application iPhone.
A bientôt !Autres articles sur le même sujet

• L’erreur est humaine… debuguer un projet Flex distant via Flex Builder
• [Flex 3 Beta] bug : Application File doesn’t exist
• Développer une application iPhone – Introduction aux concepts de base
• Reflex #1: une micro-architecture pour Flex… simple !

Il est des petits appareils qui font envie de nos jours : l’iPhone fait certainement partie des premiers de cette liste.

Voilà donc un tutoriel d’approche d’une technologie nouvelle pour des personnes n’ayant aucune notion de développement dans ce domaine.

Je parlerai donc ici :

• Des principaux concepts à maîtriser absolument pour bien démarrer un développement pour iPhone
• De quelques exemples permettant d’illustrer les concepts

Je ne parlerai pas :

• Des différences entre un développement pour Mac par rapport à un développement pour iPhone
• De quelconques « best practices » de développement

Il s’agit plutôt d’un retour d’expérience qui permettra peut-être à d’autres personnes d’appréhender un développement pour iPhone sans trop se casser les dents.

Pour la suite, la documentation fournie par Apple est très complète et peut vous donner de quoi satisfaire vos nuits blanches pour un bon moment !

Pour bien démarrer

1. Comprendre l’environnement nécessaire au développement d’une application iPhone
   1. Les principaux concepts
   2. Les outils
2. Ouvrir quelques projets d’exemple pour se familiariser avec la syntaxe Objective-C
3. Créer son premier projet

Ce premier article présente les concepts et introduit la liste des outils nécessaires au développement.

Note aux pressés (j’en fais généralement partie)

Si vous grillez les deux premières étapes, vous risquez rapidement de vous rendre compte qu’elles vous manquent et perdrez certainement beaucoup plus de temps que si vous y consacrez une petite journée.

Comprendre l’environnement nécessaire au développement d’une application iPhone

Les principaux concepts

Pour commencer, il est indispensable de maîtriser quelques bases de fonctionnement d’un programme iPhone.

Une application iPhone est une application MVC dans sa plus pure forme. Vous concevez des vues, manipulées par des contrôleurs en faisant transiter des données d’un modèle.

Application delegate

Il s’agit de la classe en charge du lancement de l’application et de l’affichage de la fenêtre principale.
Vous pouvez vous en servir pour initialiser des éléments particuliers communs à l’ensemble des éléments de votre application :

• connexion à une base de données,
• configuration générale,
• …

View controller

Classe gérant la vue et pouvant recevoir les événements propres aux composants de la vue gérée.

View

Une vue, chargée d’afficher des contrôles.

Il faut savoir qu’une vue peut être créée par programme ou en utilisant des fichiers de ressources définis à l’aide de l’interface builder.

Ce sont deux moyens différents qui présentent leurs avantages et inconvénients… A vous de voir lequel convient le mieux à telle ou telle situation.

Delegate

C’est un terme souvent employé dans un programme.

Un délégué est un objet prenant en charge un certain nombre de méthodes remplissant des fonctions propres à un émetteur.

En pratique, un view controller est, dans la plupart des cas, désigné comme délégué des composants de la vue et va implémenter les méthodes répondant aux événements que chacun d’entre eux déclenche.

Par exemple, un composant table view (tableau) va appeler différentes méthodes de son délégué pour pouvoir s’afficher convenablement :

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
Doit renvoyer le nombre de sections dans le tableau

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
Doit renvoyer le nombre de lignes du tableau à afficher pour la section dont le numéro est passé en paramètre

- (UITableViewCell *)tableView:(UITableView *)tv cellForRowAtIndexPath:(NSIndexPath *)indexPath
Doit initialiser une cellule du tableau pour le numéro de section et de ligne passé en paramètre

Ce mode de fonctionnement permet notamment que n’importe que objet soit désigné comme délégué. On peut donc très bien imaginer avoir les deux possibilités suivantes :

• Le schéma A montre l’exemple le plus courant : une seule classe faisant office de ViewController et de Delegate pour l’ensemble des contrôles de la vue.
• Le schéma B montre une alternative intéressante lors de gestion de vues complexes : une classe Delegate par contrôle et un ViewController standard.

La différence entre ces deux solutions, c’est que le premier ViewController contiendra l’ensemble du code de BoutonDelegate, Tableau1Delegate et Tableau2Delegate, le rendant peut-être plus complexe à lire et à comprendre.

Ceci étant dit passons aux outils.

Les outils

Vous avez trois outils à votre disposition :

1. XCode : l’environnement de développement en charge de coder, compiler et lancer la deuxième application
2. Le simulateur iPhone : une application simulant à quelques restrictions près un iPhone et vous permettant de tester unitairement vos fonctionnalités
3. Interface Builder : l’outil de création d’interfaces (écrans, vues…)

XCode est un peu l’application maître et lance ses 2 gentils larbins pour faciliter le développement.

Dans le prochain article, passage aux choses sérieuses : nous ouvrirons XCode pour voir comment cette théorie se traduit en pratique, histoire d’illustrer un peu ces jolis concepts.

A la prochaine !
Autres articles sur le même sujet

• Petit cours sur l’API de dessin
• Cairngorm pour les fainéants… Tour d’horizons des code generator
• Développer une application iPhone – XCode et Interface Builder passés au crible
• Hello AFCS ( bye Cocomo ) : première application multi-utilisateurs