Vos débuts en Cocoa

19 11 2008 In: Cocoa, Objective-C

Comme promis, cet article sera plus concret que les précédents, je ne vais toutefois pas vous épargner la théorie puisque nous allons aborder un concept important pour Cocoa, le paradigme M-V-C, et voir quelques rudiments du langage Objective-C et de l'utilisation de nos deux outils, XCode et Interface Builder.

Le programme d'exemple

Afin d'être plus concrètes, les explications s'articuleront autour d'un programme simple, pas très éloigné de l'exemple classique d'Apple, à savoir, le convertisseur de monnaie. Cependant, je m'adresse ici à des programmeurs chevronnés qui voudront rapidement en venir aux faits.

Le principe de notre programme est le suivant: une fenêtre comprend deux champs éditables. Taper une température dans le champ Degrés Fahreinheit et valider fait apparaître la conversion dans le champ Degrés Celcius et vice-versa.

Le paradigme M-V-C

À l'instar d'autres bibliothèques de développement, Cocoa est basée sur le paradigme Modèle-Vue-Contrôleur, qui sépare les Vues (l'interface utilisateur) du Modèle (la partie qui conserve les données et effectue les calculs). Le Contrôleur fait les liens entre les deux couches.

MVC

Création du projet

XCode impose la création d'un projet pour regrouper les différents fichiers constituant l'application et définir ses paramètres de construction.

Sous XCode, sélectionnez le menu File > New Project… > Application > Cocoa Application. Cliquez sur Next, tapez un nom pour le projet, et choisissez sa localisation. La fenêtre du nouveau projet s'ouvre; il y a déjà quelques fichiers dans le projet.

Programme principal

Jetez un œil à main.m, dans la rubrique Other Sources:

    #import <Cocoa/Cocoa.h>

    int main(int argc, char *argv[])
    {
        return NSApplicationMain(argc,  (const char **) argv);
    }

Nous reconnaissons la forme canonique utilisée en C pour la fonction main(). Elle ne fait qu'appeler NSApplicationMain() qui va essentiellement créer une instance de la classe NSApplication.

La directive de compilation #import est similaire à #include, si ce n'est qu'un fichier déjà inclus ne le sera pas une seconde fois. On inclut ici cocoa.h qui se trouve dans le framework Cocoa.

Ressources

Dans la rubrique Resources , vous trouverez trois fichiers:

  • Info.plist Comme vous le voyez, il s'agit d'un fichier XML. Vous pouvez d'ailleurs éditer les fichiers .plist grâce à l'utilitaire Property List Editor, mais ce fichier-là peut être édité d'une façon plus conviviale (…c'est vite dit) dans XCode (menu Project > Edit Active Target).

  • InfoPlist.strings Les fichiers .strings servent à traduire une application dans une autre langue — ce qu'on dénomme souvent par le vilain anglicisme localiser. Les clefs y sont associées aux texte traduits. Ce fichier-ci est utilisé pour le texte s'affichant dans la boîte de dialogue À propos de…

  • MainMenu.nib Ce fichier contient des éléments d'interface utilisateur. Double-cliquez-le pour l'ouvrir dans Interface Builder… il y a déjà du monde à l'intérieur.

Couche Vue

Faîtes en sorte que la fenêtre Window ressemble à ceci:

Fenetre

Vous trouverez les éléments dans la palette Library (menu Tools > Library), dans la rubrique Cocoa > Views & Cells. Les champs éditables sont des Text Fields. Les intitulés sont des Label.

Couche Modèle

Nous allons ici créer la classe CFRConvertisseur. Pourquoi pas Convertisseur tout court ? Traditionnellement, les noms de classes commencent par un suffixe pour éviter des conflits (il n'existe qu'un namespace par application). Les classes de Cocoa commencent par NS pour… Next Step.

Sous XCode, dans la fenêtre du projet, sélectionnez la rubrique Classes. Sélectionnez le menu File > New File… > Cocoa > Objective-C Class. Cliquez sur Next, vous serez alors invités à saisir le nom. Tapez donc CFRConvertisseur.m. Puis cliquez sur Finish. Deux fichiers, CFRConvertisseur.m et CFRConvertisseur.h, sont alors insérés dans le projet. Ouvrez donc le .h :

    #import <Cocoa/Cocoa.h>

    @interface CFRConvertisseur : NSObject {

    }

    @end

C'est ainsi que l'on déclare une classe en Objective-C. NSObject est l'objet de base, dont héritent tous les objets, à de rares exceptions près.

On place entre les accolades les définitions des variables d'instances (variables membres). Notre programme n'en nécessitant pas, nous les laissons vides. Nous définissons, entre l'accolade } et @end, les méthodes. Comme nos méthodes n'accèdent pas aux variables d'instance, nous les déclarons comme des méthodes de classes (ce qu'on appellerait des méthodes "statiques" en Java), en les précédant du signe + .

    + (float) convertirCelciusEnFahrenheit:(float)celcius;
    + (float) convertirFahrenheitEnCelcius:(float)fahrenheit;

Pour info: les méthodes d'instances sont précédées du signe - .

Copiez ces deux lignes et ouvrez CFRConvertisseur.m.

Pour ouvrir le .m correspondant au .h courant, et vice-versa, cliquez sur la petite icône counterpart (en haut à droite) ou bien utilisez le menu View > Switch to Header / Source File.

Collez les prototypes des méthodes, afin d'implémenter les formules de conversion:

    #import "CFRConvertisseur.h"


    @implementation CFRConvertisseur

    + (float) convertirCelciusEnFahrenheit:(float)celcius
    {
        return (9.0/5.0) * celcius + 32.0;
    }

    + (float) convertirFahrenheitEnCelcius:(float)fahrenheit
    {
        return (5.0/9.0) * (fahrenheit - 32.0);
    }

    @end

Couche contrôleur

Et maintenant, nous programmons la couche contrôleur, qui fait le lien entre les vues et le modèle. Créez un nouveau fichier source, appelé CFRControleur.m.

Déclarations des outlets

Ouvrez CFRControleur.h. Tout d'abord, nous déclarons les outlets:

    @interface CFRControleur : NSObject {
        IBOutlet NSTextField*   champFahrenheit;
        IBOutlet NSTextField*   champCelcius;
    }

Les outlets sont des variables d'instance, quand notre classe CFRControlleur sera instanciée (à la lecture du fichier .nib), Cocoa fera pointer les variables sur les objets que nous leur auront lié. Nous allons voir ces liaisons dans un instant. Ecrire IBOutlet est nécessaire pour qu'Interface Builder sache qu'il s'agit d'outlets.

N'oubliez pas de rajouter #import "CFRConvertisseur.h"

Déclaration des actions

    @interface CFRControleur : NSObject {
        IBOutlet NSTextField*   champFahrenheit;
        IBOutlet NSTextField*   champCelcius;
    }

    - (IBAction) fahrenheitModifie:(id)sender;
    - (IBAction) celciusModifie:(id)sender;

    @end

Les actions sont des méthodes qui sont appelées lorsqu'un contrôle est actionné. Pour nos champs, cela signifie qu'on aura validé leur contenu en tapant sur Entrée. Une action a forcément un prototype de cette forme. id est le type générique des objets. Nous savons évidemment qu'il s'agit de NSTextFields.

Regardez donc à quoi correspond le symbole IBAction

Sous XCode, pour accéder à la définition d'un symbole, maintenez la touche Commande appuyée, et double-cliquez le symbole.

On peut voir qu'IBAction est équivalent à void et qu'IBOutlet équivaut à rien.

Liaison des Outlets et Actions

Retournez sous Interface Builder. Faîtes apparaître la palette Library (menu Tools > Library). Dans la rubrique Library > Cocoa > Objects & Controllers, vous trouverez un cube bleu, intitulé NSObject. Glissez-le dans la fenêtre MainMenu.nib. Ainsi, Cocoa instanciera un objet de la classe NSObject à l'ouverture du .nib… mais ce n'est pas ce que nous voulons ! Sélectionnez le cube, puis dans la palette Inspector > Object Identity mettez le champ Class à CFRControleur. Vous remarquerez que les actions et outlets sont apparues au bas.

Cliquez sur le cube bleu en maintenant la touche Contrôle appuyée (ou bien clic droit), et reliez le cube au champ Fahrenheit. Quand vous lâchez le bouton, un menu apparaît: choisissez champFahrenheit. Et voilà! L'outlet, champFahrenheit est liée au champ la représentant. Faîtes de même pour le champ Celcius.

Pour les actions, c'est pareil, mais en tirant un segment du champ vers le cube. Je vous laisse faire.

Implémentation des actions

Revenons à XCode et à CFRControleur.m, pour y ajouter les deux méthodes d'actions:

    - (IBAction) fahrenheitModifie:(id)sender
    {
        // Afficher la température convertie dans le champ Celcius
        float fahrenheit = [sender floatValue];
        float celcius = [CFRConvertisseur convertirFahrenheitEnCelcius:fahrenheit];
        [champCelcius setFloatValue:celcius];
    }

Remarquez le [sender floatValue]. Il s'agit d'un appel de méthode, qu'on appelle plus volontiers un message en ObjC. Nous savons que sender est notre NSTextField Fahrenheit. Nous lui demandons de nous envoyer sa valeur sous la forme d'un float.

[CFRConvertisseur convertirFahrenheitEnCelcius:fahrenheit] est également un message, mais comme convertirFahrenheitEnCelcius: est une méthode de classe, nous la faisons précéder du nom de sa classe.

Finalement, nous demandons au champ Celcius d'afficher la valeur celcius.

Ajoutons l'autre méthode:

    - (IBAction) celciusModifie:(id)sender
    {
        // Afficher la température convertie dans le champ Fahrenheit
        [champFahrenheit setFloatValue:[CFRConvertisseur convertirCelciusEnFahrenheit:[sender floatValue]]];
    }

Cette méthode est similaire à la précedente, si ce n'est que j'ai imbriqué les messages.

Terminez par ajouter

    #import "CFRConvertisseur.h"

Alors ça marche ?

Nous n'avons plus qu'à lancer le programme: menu Run > Run. Ça doit compiler et lancer l'application. Je vous laisse jouer et essayer quelques valeurs.

Quelques améliorations

Vous aurez peut-être remarqué que le programme souffre de deux défauts:

  • trop de chiffres sont affichés (c'est inesthétique)

  • si on entre des caractères plutôt que des chiffres, cela revient à taper zéro (c'est mal).

Retournez sous Interface Builder. Dans la palette Library > Library > Cocoa > Views & Cell, recherchez le Number Formater (un rectangle avec un $ ). Glissez-le sur le champ Fahrenheit. Allez dans la première rubrique de l'Inspecteur (Number Formater Attributes), et mettez-y le menu Style à Decimal. Faîtes de même pour le champ Celcius.

Retournez sous XCode, relancez l'application… les deux défauts sont réglés !

Pour finir

Cet article n'était qu'une introduction, mais vous a cependant présenté les concepts de bases de Cocoa: MVC, édition des .nib, Outlets et actions. Les prochains articles vous aideront à approfondir ces connaissances.

Le projet complet à télécharger, si vous n'avez pas réussi.

Le garbage-collector de Leopard

13 11 2008 In: C, Cocoa, Objective-C

Pour ceux que cela interresserait, Le code du garbage collector de Leopard est disponible sous licence Apache 2.0 depuis peu. Le projet s'appelle AutoZone et il est aussi bien utilisé dans Cocoa que dans MacRuby. Il est disponible sur le site Open Source d'Apple :

Sortie de LLVM 2.4

12 11 2008 In: C, Objective-C

La version 2.4 de LLVM, le projet permettant de créer des compilateur auquel Apple attache beaucoup d'importance (voir LLVM : Le futur compilateur d'Apple ? et 2008 LLVM Developers' Meeting), vient de sortir. Parmi les nouveautés il y a :

  • La gestion des Blocks
  • Beaucoup d'évolutions sur Clang qui devrait permettre à terme de proposer une remplacement à GCC. Il permet déjà à l'heure actuelle de compiler des projets comme SQLite, Lua ou ClamAV ainsi qu'une grande partie des exemples de code Obejctive-C de la documentation Apple.
  • Diverses optimisations concernant la vitesse de compilation.

Pour plus d'informations, vous pouvez lire :

L'université de Stanford propose cette année des cours concernant le développement sur iPhone (sous le nom CS193P - iPhone Application Programming). Et si vous n'êtes pas étudiant à Stanford, vous pouvez tout de même suivre le cours grâce aux PDF et aux morceaux de code disponible en ligne sur la page dédié au cours. On notera tout particulièrement :

En espérant voir d'ici quelques temps des vidéos ou des MP3 des cours.

Les "blocks" dans C grâce à LLVM/Clang

03 09 2008 In: C, Objective-C

Depuis quelques jours, on entend pas mal parler de l'ajout des blocks dans le compilateur Clang de LLVM, projet dans lequel Apple est très investi. Voici quelques articles pour ceux qui voudrait en savoir plus :

2008 LLVM Developers' Meeting

16 08 2008 In: C, Objective-C

Le 1er août a eux lieu l'édition 2008 de la rencontre des développeurs LLVM (Low Level Virtual Machine) sur le campus d'Apple.

Les vidéos et les slides sont maintenant disponible sur la page http://llvm.org/devmtg/2008-08/. Une bonne partie des présentations viennent d'employés d'Apple, ce qui permettre de découvrir les choses à venir dans le monde du développement Mac. Il s'agit tout particulièrement des présentations suivantes :

  • Clang Internals (slides) - Clang est le nouveau front-end C/ObjC/C++ actuellement en développement du projet LLVM qui pourrait permettre de remplacer GCC. Cette présentation décris l'état actuel et l'architecture du projet, ainsi que le fonctionnement de l'AST (Abstract Syntax Trees).
  • Finding Bugs with the Clang Static Analyzer (slides) qui présente un analyseur statique du code source qui permet de découvrir plus de problème lors de la compilation que les outils actuels.

Snippets pour Cocoa

31 07 2008 In: C, Cocoa, Liens, Objective-C

Les snippets sont des extraits de code, le plus souvent court, montrant comment résoudre en problème particulier en développement. Il s'agit par exemple de savoir comment :

Voici donc quelques sites proposant des snippets pour Cocoa et le développement Mac de manière général :

Présentation sur PHP /Objective-C

25 07 2008 In: C, Cocoa, Objective-C

Wez Furlong, un des développeurs de PHP nous présente ici php-objc qui permet de développer des applications Cocoa avec PHP, un peu comme PythonObjc et RubyCocoa le permettent pour Python et Ruby. Ça permet au développeurs PHP de ne pas avoir besoin d'apprendre un nouveau langage pour développer sur Mac.

La FAQ Cocoa.fr

07 07 2008 In: Cocoa, Cocoa.fr, Objective-C

Me voilà de retour après quelques jours sans billets pour cause de déménagement. Et pour recommencer à prendre mes marques tranquillement et finir de déballer les derniers cartons, je vous présente la FAQ Cocoa.fr. Elle commence simplement avec deux questions/réponses venant d'anciens billets, qui seront je l'espère le début d'un grande série :

Si vous avez d'autres questions, voir même la question et la réponse qui va avec, je suis ouvert à tout ajout.

LLVM : Le futur compilateur d'Apple ?

21 06 2008 In: Apple, C, Objective-C

Tous les projets d'Apple ne sont pas secrets, après l'utilisation de SproutCore dans les galeries .Mac, AppleInsider nous présente ici LLVM (Low Level Virtual Machine) et l'utilisation qu'en fait Apple. Il s'agit par exemple :

  • De l'histoire entre Apple et LLVM
  • De l'utilisation conjointement à GCC et des gains possibles de performance par rapport à GCC seul
  • De l'utilisation des fonctions de compilation JIT dans la pile OpenGL de Léopard
  • Et surtout pour finir de son avenir certainement conjointement avec OpenCL.

Pour découvrir tout ça, vous pouvez lire l'article Apple's other open secret: the LLVM Complier