Builder wordpress_id: '908' categories: - iPhone Dev tags: - cocoa touch - code - développement - interface builder - iphone - objective-c - xcode Développer pour l'iPhone - Chapitre 1 - Partie 3 - Pratique XCode / Interface | Cactus

Développer pour l'iPhone - Chapitre 1 - Partie 3 - Pratique XCode / Interface

Pour améliorer un peu le fonctionnement de notre Salut les copains et apprendre à manier un peu mieux les outils qui sont disponibles, on va utiliser et exploiter différents éléments d'interface, et commencer à faire un peu de code. On restera assez bref dans les explications sur le code en Objective-C, c'est pour la suite. On est vraiment plus dans la maîtrise des outils. 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: NSLog(@"Methode toto appelée"); 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 ` @interface SalutViewController : UIViewController { } - (IBAction) buttonPressed:(id) sender; @end SalutViewController.m ---#import "SalutViewController.h" @implementation SalutViewController - (IBAction) buttonPressed:(id) sender{ NSLog(@"On a appuyé sur le bouton"); } .... } (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 ` @interface SalutViewController : UIViewController { IBOutlet UILabel *salutLabel; } - (IBAction) buttonPressed:(id) sender; @end 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` . - (IBAction) buttonPressed:(id) sender{ NSLog(@"On a appuyé sur le bouton"); salutLabel.text = @"salut les aminches"; } 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

Publié le 25 Mar 2009
Écrit par Cyril