Nous allons afficher les informations que l’on peut récupérer comme informations sur l’appareil, votre iPhone, votre iPod, c’est pratiquement une des premières applications que j’ai faite moi même (la première) après avoir vu les vidéos d’explications disponibles sur iTunes developer.

Nous allons aussi faire en sorte de faire fonctionner cette interface!

On va commencer justement par réaliser cette interface. Nous en avons déjà un bout, continuons sur cette lancée. On ouvre donc à nouveau le nib SalutViewController. On vérifie que le fond est bien d’un blanc immaculé, et non d’un gris clair.

Dans la bibliothèque, accessible par Tools / Library ou ⇧⌘L, on retrouve le segmented control, qui dans sa vue par défaut se présente avec un 1 et un 2. On le saisit et on le dépose au bon endroit.

On voit qu’on a que deux sélections. En sélectionnant cet objet, on fait apparaître la fenêtre d’attributs ⇧⌘1 si elle n’est pas visible, et on augment le nombre de segments (de 2 à 4). Comme les segments sont un peu petits, on peut augmenter la taille générale de l’objet. On peut aussi changer le style.

Une fois que c’est fait, on peut changer les intitulés des contrôles de la barre de contrôle. On choisit dans la liste déroulante chaque segment l’un après l’autre puis on change son nom. On peut remarquer à l’occasion que chaque segment a un numéro de 0 à 3.

On va ensuite rajouter le switch et le slider. Prenez les dans la bibliothèque et déposez les dans votre vue. Remarquez en manipulant ces objets comment Interface Builder vous présente des guides de positionnement, alignant les objets, laissant de la marge entre l’objet et le bord de la vue etc. Plaçons enfin le bouton et les trois UILabels. Notre interface est visuellement achevée.

Les textes des boutons et des labels ne sont pas bons alors changeons les. Sélectionnez chaque objet l’un après l’autre et changez son texte soit dans l’interface soit dans l’inspecteur d’attributs.

Pour commencer tout doucement avec “le truc qui pose des problèmes aux gens”, les connexions, nous allons juste appeler des méthodes. Si vous êtes un développeur WebObjects ou même Tapestry en Java, vous n’aurez aucun souci. Sinon, n’hésitez pas à relire cette page, à poser des questions. Si vous n’avez jamais fait de développement GUI, tant mieux : vous êtes encore tout frais.

On va utiliser le debugger du pauvre NSLog, comme ça:

Commençons par créer une méthode pour le bouton central. Nous allons la déclarer dans le fichier .h et l’implémenter dans le fichier .m .

SalutViewController.h

#import <UIKit/UIKit.h>

SalutViewController.m

(Note: je ne colle pas toutes les méthodes, seulement celles qui m’intéressent)

Il faut maintenant coder comment déclencher cette action. Ou le faut il? Non ce n’est pas nécessaire. Interface Builder permet de connecter simplement le bouton avec la méthode, pour faire en sorte que le message par défaut du bouton soit lié à la méthode écrite. Pour le faire, on va connecter le bouton à la méthode dans SalutViewController. Allez, un petit screencast, mais avant pesnez à sauvegarder vos fichiers:

Vous avez vu? Simple. Pas besoin de chercher midi à 14 heures.

Ce qui peut ne pas marcher

Le screencast ne donne peut être pas le bon résultat pour vous. A cela quelques raisons fréquentes que je vais rassembler ici. Première chose il faut bien sauvegarder vos fichiers de code avant de regarder dans Inerface Builder. Quand vous le faites, XCode prévient Interface Builder dans votre dos qu’il doit relire la définition de l’objet, le fichier .h.

Deuxième chose qui peut clocher : votre méthode doit accepter certains objets en paramètres et renvoyer void ou IBAction. Avec IBAction, vous êtes certains que Interface Builder sait que l’on a définit cette méthode pour qu’il puisse la manger, s’en servir. De son côté l’objet que vous allez actionner va toujours s’envoyer lui même comme paramètre de la méthode. Comme les objets peuvent être de nature de différente, on a l’habitude d’accepter id comme paramètre (ce qui désigne un objet).

Tout ça c’est ce qui peut déconner dans le fichier .h . Maintenant vous pouvez faire des erreurs dans le fichier .m Par exemple vous pouvez oublier complètement d’implémenter la méthode. Le compilateur vous préviendra avec un warning, mais ce n’est pas une cause d’échec de la compilation. Si vous vous trompez de syntaxe, ou que vous changez le type de retour de la méthode ou les objets pris en entrée, cela a le même (désastreux) effet. A l’utilisation, ce type d’erreur conduit à un crash suite à une erreur de type obc_exception_throw .

Si vous ne voyez pas votre méthode apparaître quand vous essayez de connecter, cherchez du côté de la signature de la méthode, dans le ficheir .h : bons paramètres, bon retour.

Enfin, vous pouvez oublier de faire la connexion. Alors évidemment, le bouton ne fait rien.

Allez, niveau supérieur

Le niveau supérieur, c’est dans l’autre sens : connecter des variables du code avec l’interface. On va faire simple, on va commencer juste avec le UILabel du début. Pour expliquer le concept, disons cela :

Quand l’interface se réveille, elle sait quel type d’objet contrôleur doit être désarchivé avec elle. En effectuant les connexions, on lie les variables de l’interface qui se réveille avec les variables de l’objet contrôleur correspondant.

Il faut donc avoir des variables dans le code, dans le header, pour les lier aux objets présents dans l’interface. Notre code ressemble alors à cela:

#import <UIKit/UIKit.h>

On sauvegarde et on effectue la connexion entre le code et l’interface pour que le code sache quel est l’objet correspondant, et que l’interface sache avec quelle variable du contrôleur lier l’objet qui revient à la vie.

Et hop, screencast :

Nous avons rajouté la variable salutLabel qui est un objet de type UILabel au code. Puis nous avons connecté la variable au bon objet dans l’interface.

Nous allons maintenant simplement changer le contenu du texte de salutLabel. Pour ce faire on va utiliser la méthode liée au bouton tout à l’heure. On va le faire pas trop sophistiqué pour le moment. On va remplacer la méthode buttonPressed en rajoutant un changement de la propriété text .

Voilà! On a donc fait un truc très simple. Même si le concept vous parait encore un peu étranger, ne vous posez pas plus de questions que cela pour le moment. A l’usage, un jour, si c’est encore un peu obscur, votre cerveau va s’éclaircir et verra la lumière.

Téléchargez le projet à cette étape

Si vous ne me croyez pas : Jean Marie Hullot

Passé cette boutade, parlons un peu d’Interface Builder. Pour ceux qui ne connaissent pas, Interface Builder est une révolution pour le design d’interface. en tout cas il utilise un paradigme différent des autres interfaces de création d’interface. En effet Interface Builder ne crée pas un modèle de code qu’il faudra rééditer ensite, mais un document d’interface qu’il archive sous forme de fichier, pour le désarchiver à l’exécution.

Ces fichiers .xib que vous voyez sont ( à peu de choses près) les mêmes que ceux qui sont dans votre application. Les objets y sont séchés à froid. Au désarchivage, on les reconnecte avec le code qui les concerne et ils reprennent vie.

Dans les faits, ça donne ça : double cliquez sur SalutViewController.xib. Interface Builder s’ouvre et vous présente le contenu du bundle (paquet) du bundle j’ai dit, avec la vue principale ouverte et une bibliothèque d’objets disponibles. Pour utiliser les objets, on les met dans la vue, on les connecte avec le code, on sauvegarde et voilà. C’est tout. Pas de génération de code, rien.

Et si on le faisait?

Tout d’abord, dans Interface Builder, je préfère avoir la visualisation des objets en liste. Cette présentation en liste permet en effet de montrer l’arbre de tous les objets et la façon dont ils s’insèrent les uns dans les autres. Commençons par l’objet le plus rempli, MainWindow.xib : dans XCode, double cliquez dessus pour l’ouvrir. Vous avez une fenêtre avec cinq objets.

Si vous choisissez l’affichage en liste, cela donne aussi cela.

Le premier objet est SalutAppDelegate, un objet créé automatiquement pour vous à la création du projet. Il hérite de NSObject.

Le second objet est window, qui représente la seule fenêtre de cette application.

Sélectionnez votre SalutAppDelegate et faites apparaître la fenêtre de propriétés ⇧⌘1 ou Tools / Attributes inspector. Dans cette fenêtre il y a 4 onglets : attributs, connexion, tailles et identité. Le premier onglet ici ne sert à rien car SalutAppDelegate n’a aucun attribut qui se rapporte à l’interface. Le second onglet montre les différentes connexions qui peuvent être faites entre cet objet et les autres objets accessibles par interface builder. Ainsi, ici l’objet SalutAppDelegate a deux variables qui peuvent être liées à d’autres objets : viewController et window . La première est liée à l’objet SalutViewController présent juste en dessous, la deuxième est liée à la fenêtre Window.

Pour le bénéfice de l’exercice, nous allons casser les liens faits automatiquement, et les refaire.

Dans la fenêtre des connexions, cliquez sur la petite croix présente entre viewController et Salut View Controller, puis sur la petite croix présente entre window (la variable window de l’objet SalutAppDelegate) et Window (la fenête créée dans Interface Builder). Allez, on va carrément effacer l’objet Window. On le sélectionne dans MainWindow.xib et on appuie sur la touche Backspace.

Si on sauvegarde et qu’on va dans XCode et qu’on compile…. Patatras! Une belle application avec un bel écran noir.

Retournons dans Interface Builder. On fait apparaître la bibliothèque des objets en appuyant sur ⇧⌘L ou Tools / Library. Vous voyez tous les objets disponibles par défaut pour une application Cocoa Touch. Parcourez la liste et quand vous voyez Window, sélectionnez la et faites un drag & drop vers la fenêtre MainWidow.xib : vous venez de créer un objet de type Window qui sera accessible au démarrage.

Nous allons maintenant connecter la variable window de SalutAppDelegate à cette fenêtre. Il existe trop de façons de faire les connexions. On utilisera toujours la même ici : on sélectionne l’objet d’origine, on appuie sur Ctrl, on drag vers l’objet qui nous intéresse, soit dans la fenêtre .xib, soit dans l’interface elle même, on lâche et on sélectionne la ‘prise’ l’outlet qui convient.

Tiens, un petit screencast :

Maintenant, nous allons rétablir la connexion entre viewController (la variable de SalutAppDelegate) et le le controller présent dans la fenêtre .xib . Allez y je ne vous aide pas.

On est revenu dans l’état d’origine de l’interface.

On va se concentrer maintenant sur deux choses : la fenêtre window, et le rapport entre le fichier source dans XCode et l’objet dans Interface builder.

La fenêtre Window est la vue de base de toute votre application, la fenêtre dans laquelle toutes les vues vont s’afficher. En fait quand vous allez ajouter des objets de la librairie, vous allez ajouter des vues en cascade, et c’est pour cela que j’aime bien la vue liste : elle montre la cascade de vues. Les vues ont des supervues (les vues qui les continennent) et des sous vues (les vues qu’elles contiennent éventuellement). On ne peut toutefois pas remonter plus haut que la vue de la fenêtre : celle ci n’a pas de supervue.

Cette fenêtre va nous aider à faire le lien avec la deuxième question, celle du rapport entre le code et Interface Builder. Si vous ouvrez dans XCode le code SalutAppDelegate.h, vous voyez que deux variables sont définies :

Ce sont les deux variables que l’on retrouve dans Interface Builder. Pourquoi sont elles disponibles dans Interface Builder? C’est parce que l’on a ajouté le mot clé IBOutlet devant. Si vous rajoutez une nouvelle variable, sous la forme d’une variable mais en omettant ce IBOutlet, vous ne verrez pas la prise apparaître dans Interface Builder.

C’est une erreur assez commune et qu’il m’arrive encore de faire de temps en temps. Pensez y. Les autres propriétés et variables de l’objet SalutAppDelegate ne sont pas accessibles à Interface Builder.

Quand l’interface faite avec Interface Builder est ‘initée’, initialisée, les variables deviennent les objets représentés dans Interface Builder. Il n’est donc pas nécessaire de créer ces objets : ils sortent de leur hibernation et ils sont là, tout simplement. Pas d’alloc, d’init etc pour eux.

On va retourner faire joujou avec les vues. On a vu que Window est la vue principale de l’application, celle dans laquelle on met tout. Alors ouvrez dans Interface Builder cette fenêtre et déposez y des objets avec vue : Label, Switch, TextField. etc. Sauvegardez et retournez dans XCode lancer l’application. Qu’est ce que vous obtenez? la même fenêtre grise qu’avant. Que se passe-t-il? Vos nouveaux objets sont en fait cachés par une autre vue qui vient par dessus, la vue de l’objet Salut View Controller.

C’est ce que fait le code

[window addSubview:viewController.view];

dans SalutAppDelegate.

Rouvrez donc Window et effacez les objets inutiles. Allons plutôt mettre des objets utiles dans la vue de SalutViewController. Dans XCode, double cliquez sur SalutViewController.xib et ajoutez un Label (UILabel) à cette fenêtre, toujours en drag & drop. Changez la taille de cet objet dans l’interface pour qu’il soit bien large et au centre. Puis dans ses attributs allez changer le texte. Ou changez le en double cliquant sur le texte Label dans l’interface.

Lancez votre application. Ca y est, les objets ajoutés sont visibles!

La Suite

On va essayer d’y aller tout tout doux alors.

Lancer XCode

Commençons par lancer XCode. Il est dans Developer/Applications. Vous aurez envie de le mettre dans votre Dock pour y avoir rapidement accès.

Vous êtes accueillis par cet écran

et si vous cliquez sur iPhone, par celui ci:

Les informations présentées sur cet écran sont toutes disponibles sur le site web, dans la section iPhone, et dans la documentation. Vous pouvez lire quelques instants, et passer à autre chose en fermant la fenêtre. Si vous ne vouslez plus voir cette fenêtre au démarrage, décochez la case en bas à gauche.

XCode a une vue de document, contrairement à d’autres environnements que vous connaissez peut être comme Eclipse. Cela signifie que si vous n’ouvrez aucun document (texte, projet, code etc) , vous n’avez rien à l’écran, comme dans la plupart des applications Mac. Par ailleurs, comme vous pouvez créer des documents de nature très différente, XCode ne vous propose pas un document par défaut.

On va donc créer un nouveau projet.

Créer un nouveau projet

Allez dans File / New Project… ou pressez ⇧⌘N (pomme shift N – commande shift N). Apparaît l’assistant de création de projet qui vous propose tous les modèles disponibles par défaut sur votre XCode:

Ne nous dispersons pas avec une Kernel extension ou un projet WebObjects (ah bah non, ceux ci n’existent plus) et choisissons la première ligne à gauche : iPhoneOS applications. Nous avons une série de 6 modèles préexistants que nous ne détaillerons pas ici. On va simplement choisir un des plus simples qui est View Based Application. Puis on clique sur Choose….

Le plus dur est fait… presque car il faut maintenant trouver un nom à ce projet. On choisit Salut et on on indique un emplacement où le déposer. Par défaut, XCode propose Documents ce qui n’est pas plus mal qu’un autre endroit. Personnellement j’ai créé un répertoire iPhone à la racine de mon répertoire personnel et je ets mes projets dedans. Je lui ai même donné une petite icone d’iPhone pour m’en souvenir. Pour l’occasion du bouquin, je crée même un nouveau dossier iPhoneBook dans mon dossier maison.

Cette fois le plus dur est fait!

XCode ouvre en effet une fenêtre contenant tout un tas d’objets à gauche, un tas de nom de fichier en haut. Tous les fichiers sont là. Ne soyez pas intimidé. Repérez le bouton “Build and Go ” avec une grosse flèche verte et un marteau et cliquez dessus.

L’application se compile et en quelques secondes un iPhone apparaît sur votre écran et vous montre avec fierté…. un écran vide!

Vous êtes devenu développeur iPhone, et vous pouvez rivaliser avec les premières applications apparues sur l’AppStore.

Si vous avez un peu plus d’ambition que cela, passons à l’étape suivante.

Faire connaissance avec XCode

Quittez le simulateur et votre première application iPhone. Retournons ensemble dans XCode. Première chose, la fenêtre est un peu chétive. J’ai tendance à l’agrandir pour qu’elle prenne 80% de l’écran. Elle est découpée en 4 portions : la barre d’outils, la liste de fichiers (réels et virtuels) à gauche, la fenêtre des détails en haut à droite, et la fenêtre de contenu ou éditeur, en bas à droite.

Je déteste cette mise en page. Je commence par aller dans les préférences de XCode pour afficher le mode “tout en un” qui évite d’avoir des fenêtres différentes. Il faut fermer le projet courant pour le faire.

Ensuite, au fur et à mesure que je développe je passe mon temps à cacher la fenêtre de détail en faisant ⇧⌘E .

La fenêtre de gauche vous montre tous les fichiers, les réglages et les résultats de votre projet. En cliquant sur un triangle, vous ouvrez comme dans le Finder, et vous voyez le contenu du groupe. Cliquez d’abord sur le groupe de Salut, puis sur Classes, Other Sources, Resources etc. Vous verrez tous les fichiers qui constituent votre projet.

En cliquant sur un fichier, par exemple SalutAppDelegate.h, vous le voyez s’ouvrir dans la fenêtre de l’éditeur, et prendre la place principale de la fenêtre de détail : fermez cette fenêtre inutile. Toujours dans les préférences, vous pouvez régler pour qu’elle reste fermée. On a alors une belle fenêtre et on peut se concentrer en ayant de l’espace.

Première astuce, pour passer du fichier .h (le header) au fichier .m (l’implémentation), les touches ⇧⌘ et flèches haut sont judicieusement passées. Vous allez passer de l’un à l’autre souvent, voilà une astuce qui vous simplifiera la vie.

En fonction du type de fichier choisi dans la gauche, XCode vous propose un éditeur différent. Par exemple si vous cliquez sur info.plist (dans le groupe Resources), vous aurez un éditeur de property list. Certains fichiers doivent être édités à l’extérieur, c’est le cas des .xib (ou .nib).

Reprenons la liste de la fenêtre de gauche. Le groupe Classes représente le cœur de votre programme. C’est là que vous mettrez toutes vos classes Objective-C qui feront fonctionner votre application. Vous pouvez créer des groupes à l’intérieur de ce groupe, pour vous simplifier et mieux organiser vos fichiers. J’ai des groupes habituels comme Business (classes de définition d’objets persistants dans une base de données), Controllers (le plus gros) pour tous les View Controllers, des classes utilitaires dans Utilities etc etc.

Le groupe suivant, je n’y vais pratiquement pas. Il contient le fichier .pch de header qui s’applique à toutes vos classes, et le fichier main.m : car pour ceux qui ne le savent pas, l’Objective-C, c’est du C. C’est donc la fonction main qui lance l’application. Dans des cas extrêmes, vous pouvez mettre du code là dedans pour effectuer des tâches en un seul coup. On verra si on en a besoin, mais c’est rare.

Le groupe Resources contient les ‘media’ de votre application : images, interface, fichiers de configuration etc. Dans notre cas présent, il contient deux définitions d’interface, et une liste de propriétés (une plist, ou property list).

Le groupe Frameworks commence à etre un peu bizzare, car il contient la liste des librairies qui seront liées à votre application. Les frameworks sont des librairies avec des ressources, et le moyen développé par Next et Apple de faire des librairies réutilisables par tous avec du code et des ressources (interface, boutons etc). Ici, les fichiers ne sont pas vraiment dans le projet : si vous allez voir dans le répertoire Salut, vous ne trouverez pas ces frameworks.

Ces frameworks sont toujours fournis par Apple, aussi bien sur l’iPhone que sur le simulateur : pas besoin de les copier.

Le dernier groupe Products contient le résultat de vos compilations réussies : l’application lancée tout à l’heure s’y trouve. Si vous doublez cliquez dessus, vous aurez une erreur, car elle ne peut fonctionner que sur le simulateur ou l’iPhone. Si vous allez dans Build / Clean et que vous acceptez les valeurs par défaut, vous allez effacer la version compilée. Le “produit” n’est plus là, et il apparaît alors en rouge.

Le fait de déplacer des fichiers dans l’arborescence ne change pas leur emplacement sur le disque avec les groupes que l’on a vu. Si vous voulez ranger les vrais fichiers, vous pouvez le faire dans le Finder, puis revenir dans XCode pour lui indiquer les bons chemins.

La structure du dossier salut : pas de dossier resources, ni frameworks….

XCode est aussi le principal lieu de lecture de la documentation, là où on en a besoin. Pour accéder à la documentation d’une classe, il suffit de double cliquer dessus en appuyant sur ⌥ en même temps. Normalement la première fois que vous accéderez à la documentation, elle ne sera pas téléchargée. Maintenant est un bon moment de le faire, alors sélectionnez Help / Documentation, puis à gauche la bibliothèque qui correspond à votre version d’iPhone (2.2 ou 2.2.1). Le logiciel vous propose alors d’y souscrire. Bon téléchargement!

Une fois que la doc est chargée, choisissez d’ouvrir SalutAppDelegate.h et double cliquez sur UIWindow en maintenant ⌥ appuyé. La documentation de cette classe apparaît. Vous pouvez naviguer dedans comme dans toute bonne page html. Appuyez sur commande ⌘ en cliquant sur un lien pour l’ouvrir dans une autre fenêtre, ⌘ et backspace pour revenir dans l’historique etc etc.

Dans la vue “all in one”, la fenêtre principale est alternativement en mode edition et en mode debug. Commencez par poser un point d’arrêt dans le fichier SalutAppDelegate.m en cliquant dans la gouttière à gauche de [window addSubView].

Relancez votre application : dès qu’elle rencontre ce point d’arrêt dans son exécution, elle s’arrête. XCode revient au premier plan (devant votre simulateur iPhone). Cliquez alors sur le debugger symbolisé par la bombe insecticide pour changer de vue.

On a une vue avec quatre fenêtres : la pile des instructions exécutées, la vue des variables et des différents objets, le code et le log. C’est ma vue préférée, celle où je passe des heures à m’arracher les cheveux pour des broutilles…

La barre d’outil change aussi : continue, step into etc. Ces outils vous permettent d’avance pars à pas dans vos méthodes, les unes dans les autres pour savoir ce qui cloche.

Arrêtons là pour la découverte de XCode, et passons à l’éditeur d’interface, Interface Builder.

La Suite

Configuration matérielle

Pour développer pour l’iPhone il faut un Mac avec processeur Intel. Un Mac Mini suffit amplement. J’ai personnellement travaillé pendant plusieurs mois sur un MacBook Air, une superbe machine mais pas une bête de course. Ne vous lancez pas dans l’aventure Hackintosh, vous y perdrez certainement plus de temps et vous serez perdant in fine.

Non, il ne faut pas un Mac PowerPC. J’ai bien dit un Mac Intel.

Pour tester vos applications, il faut ensuite un iPod Touch ou un iPhone. Suivant le type d’application que vous ferez, il suffira peut être d’un iPod Touch 1 ou d’un iPhone 1, et non de l’iPhone 3G. Mais si vous choisissez un iPod Touch comme destination et plateforme de tests, n’oubliez pas qu’au point de vue matériel il vous manquera plusieurs choses : * la possibilité de se connecter au réseau à peu près partout * la caméra * le GPS

A part cela, les différences sur le papier sont peu nombreuses entre les deux.

Configuration logicielle

Il faut avoir Leopard comme système d’exploitation. C’est obligatoire.

Un seul programme est nécessaire pour développer des applications pour l’iPhone. XCode 3.1. Pour l’obtenir gratuitement, rendez vous sur le site développeur d’Apple, (http://developer.apple.com). Là, vous allez vous inscrire pour avoir le sdk gratuit (free) en deux étapes distinctes.

Vous rentrez dans la partie inscription, et je vous conseille de lire les termes des contrats auxquels vous adhérez. Tout d’abord, entrez une nouvelle Apple ID si vous n’en avez pas. Si vous avez déjà acheté de la musique sur iTunes, ou un produit chez Apple, vous avez déjà un apple ID : utilisez l’adresse email correspondant à votre achat et le mot de passe que vous lui avez associé.

Une fois toutes vos coordonnées indiquées, vous devez indiquer quels sont vos secteurs d’activité préférés, votre expérience de la plate forme etc. Vous devez surtout lire le contrat qu’Apple vous propose. Une fois celui ci accepté, vous êtes inscrit.

Fin de la première étape.

La deuxième étape démarre dès que vous recevez l’email de confirmation d’Apple. Celui ci permet de valider votre inscription et valide votre adresse email.

En cliquant sur l’adresse dans le mail, vous arrivez au portail de développement iPhone, en étant déjà identifié. Il ne vous reste qu’à télécharger le SDK de près de 2 Go. Armez vous d’un peu de patience.

Voici un petit screencast de présentation de l’ensemble des opérations:

Adhérer au programme développeur

Un élément qui fait grincer beaucoup de dents pour des raisons qui m’échappent est que pour pouvoir installer une application que vous développez, il faut la signer et que pour la signer il faut adhérer au programme développeur iPhone qui est payant. A la date d’aujourd’hui, le programme coûte 79 euros TTC.

Cette étape peut prendre un peu plus de temps. En effet, il faut s’inscrire au programme, attendre qu’Apple valide cet élément, vous recevez un mail et vous avez accès au paiement du programme. Prévoyez quelques jours de marge dans le pire des cas.

Cet accès au programme vous permet de récupérer un certificat Apple, de faire une demande de certificat pour votre poste de travail, de signer vos applications pour certains appareils avec votre certificat. Ce que cela vous permet surtout c’est d’uploader directement votre application sur votre iPhone ou iPod pour la tester en conditions réelles, ce qui est indispensable. Cela vous permet ensuite de faire une version AdHoc pour distribuer à vos testeurs ou clients. Enfin, cela permet de la mettre sur l’AppStore pour la distribuer partout dans le monde.

Installez XCode

Une fois XCode téléchargé, installez le sur la partition principale de votre ordinateur. Cela prend un peu de temps. Une fois fait, vous êtes enfin prêt à développer pour l’iPhone.

La Suite

L’envie me titillait depuis quelque temps déjà, à la fois suite à mon implication dans la création d’un “groupe ” de développeurs iPhone en France, et suite à ma participation au Barcamp de novembre 2008 à LaCantine sur l’iPhone : apparemment de nombreuses personnes aimeraient développer des compétences pour cette plateforme nouvelle et excitante qu’est l’iPhone, mais les ressources pour le faire ne sont pas encore disponibles.

Pour rendre cet accès plus disponible, j’ai décidé de consacrer jusqu’à une heure de mon temps chaque jour à rédiger un article pour vous faire découvrir ce que je sais. Pour ce que je ne sais pas, sur internet je pourrai vous renvoyer vers d’autres personnes, d’autres livres, des articles etc.

Un peu à la mode de 37signals et de Getting Real, mon ambition est aussi de développer ces articles jusqu’à ce qu’ils aient assez de corps pour faire un livre. Je l’annonce d’ores et déjà à ceux qui pensent que tout doit être gratuit : le livre ne le sera pas.

En attendant, les articles seront disponibles régulièrement sur ce blog, entrecoupés de réponses aux commentaires et de séances de développement (car il faut bien que je développe aussi). Profitez en et n’hésitez pas à répandre le mot autour de vous.

Qui suis je pour écrire un livre?

Quelqu’un qui a envie de le faire, avant tout. C’est une aventure longue et semée d’embûches, de désillusions. Il faut donc avoir du courage et de l’envie.

Ensuite, je développe pour l’iPhone depuis juin 2008. J’avais auparavant commis quelques petites applications pour MacOs X en 2000-2001. Je ne suis pas un super spécialiste d’Ojective-C, du C encore moins, je n’ai pas de passé de formateur.

J’ai déjà écrit deux e-books, un premier sur la photographie numérique, et un autre sur la performance des pages web. Mes qualités de rédacteur ne sont pas au top (je suis le premier à détecter des défauts quand je me relis), mais elles ne sont pas non plus exécrables. Disons que je suis dans une honnête moyenne pour de la documentation de ce niveau.

Je suis impliqué dans la création et l’existence d’un “groupe” français de développeurs iPhone, à titre personnel et ce depuis juin 2008. J’ai ouvert un site sous la forme d’un Wiki pour former un point de rassemblement de développeurs iPhone, et j’essaie d’organiser régulièrement des réunions de développeurs iPhone à Paris, pour partager des expériences, montrer des projets, boire des bières, etc.

Comment lire et suivre ce blog

Les règles du jeu? Je m’engage à écrire et consacrer une heure par jour à cet ouvrage. J’hésite encore sur les week ends, ca il faut bien que je me repose et que je me consacre à ma famille et à mes autres projets personnels. Cela ne veut pas forcément dire que je pourrai publier tous les jours de la semaine non plus : entre le code buggé qui ne fonctionne pas et le manque d’inspiration, la nécessité parfois de passer plusieurs heures pour préparer un long article ou un long chapitre, je n’y crois pas.

Le contenu sera à la fois du texte et de longues explications où à la fin du paragraphe vous ne vous souviendrez plus du début, des exemples très concis, des petites applications. Le but est d’être très proche de la pratique, et d’éviter au maximum de vous mettre dans une situation de lecteur passif.

Les sujets seront les plus divers possibles. On commencera par le tout début de l’installation, on ira voir la plupart des secteurs du développement sur iPhone sauf (et à moins l’aide d’autres rédacteurs) OpenGL ES, on ira traîner du côté de l’optimisation des programmes, à la fois avec Instruments et avec clang.

Le contenu pourra aussi être sous la forme de screencasts car parfois il faut voir les choses pour les comprendre. Je ne sais pas encore comment les mettre dans un livre ceux là…

Pour être tenu au courant des mises à jour et des nouveaux articles, le mieux est de s’abonner au fil RSS de la catégorie.

Je n’hésiterai pas à rééditer les articles au fur et à mesure pour améliorer le contenu global des articles. Je ferai dans ce cas un encart de description des modifications.

Les premières semaines de publication devraient être sans couture car je vais prendre un peu d’avance : je ne commence à publier que quand j’ai déjà un certain nombre d’articles sous la main. J’espère que vous vous régalerez et que ce sera vraiment utile pour vous.

La Suite