Cocoa.fr

Developpement Mac, Objective-C, Cocoa et Swift

Tag

objective-c

32 article(s) associe(s) a ce tag.

27 November 2009

La gestion de la mémoire (2)

Dans le premier épisode, nous avons vu qu’un objet qui avait alloué la mémoire pour un autre objet était également responsable de la libérer lorsque l’objet ne lui était plus nécessaire. Ce système est similaire à l’allocation dynamique de la mémoire telle qu’on la connaît en langage C sous la formes des fonctions malloc() et free().

Cependant, ce système comporte un inconvénient majeur dès qu’un objet est passé d’un objet à un autre. Étudions la séquence suivante:

  • Un objet A alloue un objet B.
  • L’objet A passe l’objet B à un objet C. L’objet C garde un pointeur sur l’objet B dont il a encore besoin par la suite.
  • L’objet A n’a plus besoin de l’objet B. Il lui envoie donc un message -[release].
  • L’objet C tente d’appeler une méthode de l’objet B, ce qui mène à un plantage.

Il a donc fallu incorporer un système qui permette de conserver un objet en mémoire tant qu’il est nécessaire, et le libérer lorsqu’il ne l’est plus. Ce système est l’autorelease.

Autorelease pool

Examinons l’exemple suivant:

NSArray* monArray = [[NSArray alloc] init];
[monArray autorelease];

La première ligne alloue, comme nous l’avons vu la dernière fois, un objet de type NSArray et l’initialise. La deuxième ligne ajoute monArray à l’autorelease pool courant.

Un objet de type NSAutoreleasePool conserve une liste d’objets. Ces objets seront désalloués à la fin de la boucle d’événements.

La boucle d’événements

Le moteur d’exécution (runtime) est un programme qui offre une structure à l’exécution des programmes écrits en Objective-C. Il comporte une boucle d’événements:

  • Au début de la boucle, les événements (frappe clavier, mouvements de la souris, timers écoulés, messages des autres applications, etc.) sont récupérés.
  • L’application (votre code !) traite les événements.
  • Les autorelease pools sont vidés
  • Puis on revient au début de la boucle.

Ce principe permet de garantir l’existence de l’objet pendant l’exécution d’un itération de votre code.

Dans les applications Cocoa utilisant une interface graphique, un NSAutoreleasePool est instancié automatiquement pour le thread principal. En général, vous n’avez donc pas besoin d’en créer un. Vous serez toutefois amené à le faire si vous concevez une application multi-thread, ou si vous instanciez un grand nombre d’objets dont la durée de vie est limitée.

Retain/Release

La gestion de la mémoire en Objective-C est souvent expliquée par l’analogie suivante: un petit chien se met à courir dès qu’il n’a plus aucune laisse autour du cou. Tant qu’il a au moins une laisse au cou, il ne peut s’échapper. Évidemment, s’il a plusieurs laisses qui le retiennent, il ne peut pas non plus s’enfuir.

Envoyer un message -[retain] à un objet lui passe une laisse autour du cou.

Lui envoyer un message -[release] lui retire une laisse.

Concrètement, chaque objet héritant de NSObject possède une variable d’instance retainCount. Il s’agit du nombre de “laisses”:

  • +[alloc] initialise retainCount à 1.
  • -[autorelease] décrémente retainCount et place l’objet dans l’autorelease pool courant.
  • -[release] décrémente retainCount
  • -[retain] incrémente retainCount

Lorsque survient la fin de la boucle d’événements, l’autorelease pool libère tous les objets dont le retainCount est nul.

Constructeurs de commodité

Il arrive fréquemment de créer un objet, de le passer à un autre objet, puis de ne plus en avoir besoin. Les deux exemples suivants sont équivalents. Nous voulons passer une liste d’invités à un objet fiesta:

Exemple 1:

NSArray* invites = [[NSArray alloc] initWithObjects:@"Pascal", @"Florence", @"Martin", @"Patrick"];
[invites autorelease];
[fiesta setInvites:invites];

Exemple 2:

NSArray* invites = [NSArray arrayWithObjects:@"Pascal", @"Florence", @"Martin", @"Patrick"];
[fiesta setInvites:invites];

La méthode +[arrayWithObjects:] est un constructeur de commodité, qui permet de faire l’allocation, l’initialisation et l’autorelease en une seule opération. Ce type de méthodes est très courant dans Cocoa. En fait par convention, si le premier mot du nom d’une méthode est celui de la classe, vous est certain que l’objet renvoyé est autoreleasé.

Ajout à une collection

Pour finir, sachez que les collections retiennent les objets qu’elle contiennent. C’est à dire que les objets de types: NSArray, NSSet, NSDictionary et compagnie, envoient un message -[retain] aux objets qui leurs sont ajoutés. Quand la collection est libérée, elle envoie un message -[release] à tous les objets qu’elle contient.

Exemple:

@interface Livre : NSObject
{
    NSMutableArray* pages;
}

@end

@implementation Livre
- (id) init
{
    if(self = [super init])
    {
        // Créer la liste des pages
        pages = [[NSMutableArray* alloc] init];

        // Ajouter une première page vierge
        Page* pageVierge = [[Page alloc] init];     // retainCount = 1
        [pages addObject:pageVierge];               // retainCount = 2
        [pageVierge release];                       // retainCount = 1
    }
    return self;
}

- (void) dealloc
{
    [pages release];

    [super dealloc];
}

L’objet pageVierge reçoit un message -[retain] quand elle est ajoutée au NSMutableArray pages. Nous devons donc lui envoyer un message -[release] pour qu’elle soit effectivement désallouée lorsque le livre sera désalloué.

Bientôt la suite

Nous n’en n’avons pas encore fini. Je vous encourage à poser des questions si un aspect n’est pas clair et que vous souhaitez le voir développé.

Renaud Pradenc Céroce

03 November 2009

La gestion de la mémoire (1)

La gestion de la mémoire est un sujet qui — bien qu’aussi vieux que Cocoa elle-même — semble toujours aussi mal compris. Cette série d’articles va tenter d’expliquer les choses calmement pour que les nouveaux venus à Cocoa cessent de se torturer avec une question finalement assez simple quand on a bien assimilé deux ou trois principes de base.

Manuel ou automatique

Apple a profité de la version 10.5 de son système d’exploitation pour ajouter au langage Objective-C un ramasse-miettes (garbage collector), système bien connu des programmeurs en Java. Certains en sont partisans, d’autres les exècrent; personnellement, je pense qu’historiquement les langages de programmation évoluent pour éloigner le programmeur des arcanes de la machine, et que c’est une bonne chose: ce n’est pas quand on met au point un algorithme compliqué qu’on veut que la gestion de la mémoire nous pose problème.

Ceci dit, dans mes programmes ObjC, je gère toujours la mémoire manuellement parce que le ramasse-miettes est un rajout, et que Cocoa n’a pas été pensée pour fonctionner avec un ramasse-miettes; certaines choses en deviennent très complexes. Par ailleurs, avec le temps, de nombreux outils ont été développés pour aider à diagnostiquer les problèmes de gestion manuelle de la mémoire, rendant le débogage finalement assez facile.

Si vous visez des systèmes inférieurs à 10.5, ou plus probablement, que vous programmez l’iPhone, alors vous n’avez pas le choix, vous devrez gérer manuellement la mémoire. Continuez la lecture de cet article…

Principe n°1: L’objet qui alloue la mémoire est responsable de sa libération

Un objet alloue habituellement la mémoire pour un autre objet en envoyant le message -[alloc] à sa classe.

NSString* chaine = [NSString alloc];

Ce même objet devra libérer l’objet quand il n’en aura plus besoin, en lui envoyant un message -[release]:

[chaine release];

Allocation et libération d’une variable d’instance

Utilisons ici un exemple d’un programme possédant des classes Livre et Sommaire. Un Livre possède une seule instance de Sommaire:

@interface Livre: NSObject
{
     Sommaire*  sommaire;
}

@end

La méthode -init de Livre va ressembler à ceci:

- (id) init
{
    if (self = [super init])
    {
        sommaire = [[Sommaire alloc] init];
    }

    return self;
}

L’instance de Livre a alloué à sa création une instance de Sommaire. Selon le principe n°1, elle est donc responsable de sa libération. En général, elle le fera quand elle-même est sur le point de disparaître de la mémoire, dans sa méthode -[dealloc]:

- (void) dealloc
{
    [sommaire release];

    [super dealloc];    // Permettre à la classe parente de désallouer
                    // ses propres variables d'instance
}

Quelques compléments

copy

Un objet qui envoie un message -[copy] à un autre objet, alloue nécessairement la mémoire pour stocker la copie. Il devra donc libérer la copie, mais pas l’original.

new

Cette méthode équivaut à -[[alloc init]. Il faudra donc libérer la mémoire.

[self release]

Ne doit jamais être fait. C’est l’objet qui nous a alloué qui doit nous libérer.

Pour finir

Voilà déjà pour cette première partie qui couvrait un point essentiel. Nous verrons la prochaine fois comment passer un objet dont nous n’avons plus besoin à un autre objet, tout en étant sûr qu’il sera bien libéré.

Renaud Pradenc Céroce

14 October 2009

Grand Central Dispatch, qu’est ce que ça apporte ?

Une des grandes nouveautés de Snow Leopard, est l’arrivé de Grand Central Dispatch qui permet la mise en place des taches concurrentes sur plusieurs coeurs ou plusieurs processeurs. Mais la programmation concurrente implique un paradigme différents de ce que l’on a l’habitude de voir avec les langages objets ou impératifs.

Si vous voulez apprendre à utiliser Grand Central Dispatch (GCD), je vous invite à découvrir les ressources suivante pour une prise en main rapide :

Et si vous voulez aller plus loin, l’Apple Developer Connection propose les ressources suivantes :

Sachez en plus que Apple mis le code de GDC sous licence Open source sous le nom de libdispatch, et l’on peut noter qu’un port est d’ores et déjà disponible pour FreeBSD.

07 October 2009

Les derniers livres et magazines

De retour de vacances, je vais commencer par m’intéresser aux dernières publications (livres, magazines, etc…) sur le développement à la fois Mac et iPhone :

01 April 2009

Apple passe de Objective-C à Java

Apple vient d’annoncer son projet d’abandonner le langage Objective-C en faveur de Java pour un certain nombre de raisons :

  • Il est nettement plus facile de trouver des développeurs Java que des développeurs Objective-C.
  • Java est le seul vrai langage pour écrire des applications Enterprise
  • La compatibilité des application iPhone avec les applications Android (qui utilise déjà Java).

Le SDK iPhone devrait donc rapidement apparaître dans une nouvelle version permettant l’utilisation de Java, et d’après les rumeurs, une version 4.0 de XCode basé sur Eclipse devrait être remise aux développeurs lors de la WWDC 2009.

21 January 2009

10 manières de réduire les bogues

Les bogues ne sont pas une fatalité: ce sont des défauts dus à des erreurs d’êtres humains:

  1. Trop grande complexité
  2. Méconnaissance des API ou du langage
  3. Étourderies
  4. Laxisme !

Comme vous êtes comme moi et détestez passer vos après-midi sur un débogueur, voici quelques stratégies éprouvées pour les réduire.

10. Documentez

Je vais ici seulement insister sur les aspects de la doc qui permettent de limiter les bogues :

  • Rédigez une partie de la description d’une méthode avant de la coder Vous devez réfléchir aux cas particuliers du déroulement, aux valeurs possibles des arguments d’entrée (notamment comment gérer les gammes de valeurs inattendues), et quelles erreurs peuvent subvenir pendant l’exécution. Inspirez-vous de la programmation par contrat.

  • Faites des commentaires utiles Ils ne doivent pas paraphraser le code, ni expliquer chaque appel de méthode. Expliquez le cheminement du code, et soulignez ce qui est le moins évident. C’est très utile au débogage, quand on revient au code quelques semaines plus tard.

  • Nommez vos variables avec grand soin Je suis toujours étonné qu’à notre époque, les gens nomment encore leurs variables i,j, tab[] ou ptr, dans la plus pure tradition du Kernighan & Ritchie. Il m’est arrivé de rendre des bogues évidents rien qu’en renommant.

9. Relisez-vous

D’expérience, la moitié des bogues pourraient être évités lors de l’écriture du code. Je ne parle pas des erreurs de syntaxes (signalées par le compilateur), mais utiliser une variable à la place d’une autre, effectuer les opérations dans le mauvais ordre, etc.

Si vous programmez seul, pensez à relire — avec un œil critique s’entend — votre nouveau code systématiquement avant de compiler.

8. Corrigez les bogues dès qu’ils apparaissent

Il arrive fréquemment de découvrir un bogue, et de le laisser à plus tard. Comme vous êtes un programmeur consciencieux, vous y reviendrez. Mon expérience dicte de corriger le bogue immédiatement, parce qu’il arrive souvent de commettre encore et encore la même erreur. Mieux vaut donc la corriger au plus tôt, pour ne faire l’erreur qu’une fois.

7. Testez les codes d’erreur et gérez les exceptions

À moins que cela n’alourdisse exagérément le code, il est sage de vérifier les résultats des fonctions. Gérez aussi les exceptions. Ces deux tâches triviales ne doivent pas être laissées à plus tard — c’est à dire jamais.

6. Créez des projets d’essai

Bien que je travaille sur un gros projet, je crées de nombreux petits projets annexes. Le dernier en date était destiné à vérifier sur mon site web si une nouvelle version de l’appli est disponible. Je n’avais aucune expérience du téléchargement d’un fichier texte. Sur ce petit programme de vingt lignes, j’avais tout de même commis deux bogues. Avoir un programme léger permet de les cerner rapidement.

Si j’avais intégré la fonction directement dans mon appli, je me serais demandé si les problèmes venaient du nouveau code ou de l’ancien. J’aurais peut être modifié du code valide. Enfin, maîtriser une technologie permet de savoir comment l’intégrer au mieux au reste de l’application.

5. Ayez des scénarios de test sous la main

D’expérience, il arrive que les bogues apparaissent dans des circonstances déjà rencontrées. Lorsque vous avez trouvé une procédure pour reproduire un bogue à coup sûr, notez-là et déroulez cette procédure à chaque version. Si possible, automatisez les tests. Par exemple, les tests de l’interface utilisateur peuvent être automatisés avec Instruments.

4. Écrivez des tests unitaires

Les tests unitaires s’appliquent essentiellement aux classes de la couche modèle. Ma première expérience fut une classe que je n’arrivais pas à mettre au point pour un programme de musique, qui devait renvoyer les notes faisant partie d’une gamme. J’étais capable de trouver ces notes sur le papier, mais je m’y suis repris à trois fois avant d’avoir un algorithme… qui ne marchait pas dans certains cas particuliers.

Après avoir écrit les tests unitaires, les erreurs apparaissaient de façon évidente dans la couche modèle, plutôt que de manière indirecte dans l’interface utilisateur. J’ai gagné du temps, et j’étais enfin sûr de mon code. Nous reviendrons sur les tests unitaires, à la mode, et ceci pour d’autres très bonnes raisons.

3. Réduisez les contraintes

Comme dit plus haut, la cause principale des bugs est la complexité. En effet, des scientifiques ont mesuré que les individus les plus doués étaient capables de prendre en compte simultanément sept contraintes. Pour la plupart des gens, c’est plutôt quatre (<- c’est là que je me situe).

L’idée est donc de limiter la complexité du logiciel:

  • en ajoutant de l’abstraction pour pouvoir se concentrer sur la tâche présente au lieu des détails d’implémentation.

  • en limitant le couplage c’est à dire les interdépendances entre objets.

Et cela est difficile. Très. Beaucoup de gens se disent programmeur (“oui, j’ai étudié un peu le langage C pendant mes études de biologie”), mais peu ont déjà travaillé sur un projet conséquent, un où les bogues deviennent difficiles à résoudre et semblent réapparaître sans cesse.

Je n’ai pas de secret, il faut se forger une expérience: étudier les patrons de conception, savoir comment fonctionne la machine et le système d’exploitation, étudier d’autres langages de programmation ou d’autres bibliothèques…

2. Ne construisez que les infrastructures nécessaires maintenant

Ce point est un peu en contradiction avec le précédent. En effet, quand on commence à ajouter de l’abstraction, on a ensuite tendance à vouloir rendre tout réutilisable et générique. Imaginons que vous vouliez écrire un texte en rouge. Il est tentant d’écrire une méthode générique qui prend la couleur en paramètre, pour le jour où vous voudriez écrire en vert.

Pourtant, la méthode générique sera forcément plus difficile à écrire et à tester. Pourquoi passer du temps sur quelque chose d’inutile aujourd’hui ? Attendez un jour prochain que le besoin soit réel. De plus, une méthode simple sera une bonne base de départ pour écrire une méthode plus complexe.

1. Codez moins

Aucun code n’est plus flexible que pas de code.

Il existe souvent une méthode qui rend 80% du service avec seulement 20% du travail que demanderait une méthode parfaite. Ne visez pas la perfection. La vie est trop courte ! Demandez-vous si vos utilisateurs préfèrent une fonction parfaite dans un an ou une fonction correcte aujourd’hui.

Moins de code = moins de bogues Travaillez le cœur de métier de votre logiciel. Les détails seront réglés plus tard (voire jamais).

Pour finir

Voilà les méthodes que j’utilise — avec plus ou moins de rigueur — pour conserver mes applis stables. Auriez-vous d’autres techniques à proposer ?

29 December 2008

En vrac de Noël

Après quelques jours loin de mon ordinateur pour cause de repas de Noël, et avant quelques jours loi de tous accès Internet pour le nouvel an, voici quelques articles intéressants pour finir l’année 2008 :

Le prochain billet arrivera certainement en 2009, je vous souhaite donc un très bon réveillon.

07 December 2008

Objective-C et les tests unitaires

On me demandait dans les commentaires du billet précédent ce qu’était exactement les tests unitaires, je vais donc essayer d’expliquer à quoi ils servent et vous proposer quelques ressources pour aller plus loin.

Comme le nom l’indique, il s’agit de tester le comportement d’un unité d’un programme, c’est à dire par exemple une fonction ou une classe. Pour une fonction qui convertit une température de Celsius en Fahrenheit, on va tester que le résultat de la conversion pour différentes valeurs. On testera des valeurs négatives, positives, des lettres, etc. pour s’assurer que le résultat est correct et que les erreurs sont bien traités. Les tests permettent aussi d’éviter les régressions de votre programme, car lors d’une modification de votre code, vous pouvez exécuter les tests et vous assurez que le comportement n’a pas été altéré par vos modifications récents.

Vient ensuite le concept de couverture de code. Il s’agit de connaître le pourcentage des lignes de code du programme qui sont testés par votre jeu de tests unitaires. Par exemple, si votre fonction contient du code conditionnel avec l’instruction if/else, il faut que les différents tests de la fonction fassent intervenir à la fois le code dans le bloc if que dans le bloc else. Plus le pourcentage est élevé plus vous pouvez avoir confiance dans le comportement de votre code.

Pour allez plus loin, n’hésitez pas à lire les ressources suivantes :

J’espère avoir été assez clair, mais n’hésitez pas en cas de besoin à poser vos questions dans les commentaires.

05 December 2008

Visualiser la couverture de code de ses tests unitaires

Une des pratiques importantes dans le développement logiciel, est l’utilisation de tests unitaires. Cela permet de s’assurer du comportement de son code, d’éviter les régressions et de manière général d’avoir plus confiance en son code.

Google vous propose dans le cadre de son Google Mac Developer Playground un certain nombre d’outils pour développeur dont CoverStory, qui permet de visualiser facilement le taux de couverture de votre code à partir des fichiers générés par Gcov.

CoverStory

Pour plus d’informations sur CoverStory, les outils Google pour développeurs Mac et Gcov, utilisez les liens ci-dessous :

19 November 2008

Vos débuts en Cocoa

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.

12 November 2008

Sortie de LLVM 2.4

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 :

31 October 2008

Cours de développement iPhone de Stanford

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.

03 September 2008

Les “blocks” dans C grâce à LLVM/Clang

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 :

16 August 2008

2008 LLVM Developers’ Meeting

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.

31 July 2008

Snippets pour Cocoa

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 :

07 July 2008

La FAQ Cocoa.fr

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.

21 June 2008

LLVM : Le futur compilateur d’Apple ?

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

02 June 2008

Pourquoi passer de Win32 à Cocoa, partie 3

Ars Technica vient de publier la 3ème et avant-dernière partie de la série d’articles “Pourquoi passer de Win32 à Cocoa” (From Win32 to Cocoa: a Windows user’s conversion to Mac OS X). Peter Bright après avoir abordé comment Apple à réussi à dépasser les erreurs du passé et comment Microsoft à échoué étudie ici tous les petits plus qui rendent Cocoa et le développement sous Mac OS X plus sympathique :

30 May 2008

Accéder aux API Google depuis votre application

Il peut être utile dans une application d’accéder aux services Google comme par exemple les calendriers ou les contacts. Google propose donc une librairie Objective-C (Google Data APIs Objective-C Client Library) permettant d’accéder à ces services et à d’autres depuis votre application Cocoa.

A vous donc l’accès à Google Base, Blogger, Calendar, Code Search, Contacts, Documents List, Notebook, Picasa Web Albums, Spreadsheets et YouTube.

26 May 2008

Un tutorial pour PyObjC

Il n’est pas toujours facile de trouver des informations récentes concernant le développement avec PyObjC 2.0, le tutorial sur orestis.GR est donc tout particulièrement intéressant. Il présente un petit “Hello Word” avec en bonus l’intégration d’un lecteur vidéo. Et pour ne pas gacher le plaisir une archive avec le code est fournie. Vous n’avez donc plus aucune excuse de ne pas aller lire PyObjC Hello World.

16 May 2008

Créer un format de fichier personnalisé

Lorsque l’on crée une application, on se retrouve souvent à devoir sauvegarder des données dans un fichier et aucun standard utilisable pour l’application en question. Matt Long nous propose ici sur son blog Cocoa Is My Girlfriend un article sur comment créer un format de fichier sur mesure. L’article s’intitule From Hacker to microISV: Custom File Formats et est très complet avec aussi bien des explications sur le fonctionnement des “packages” sur Mac OS X que des extraits de code.

02 May 2008

Apprendre Objective-C

Scott Stevenson de Cocoa Dev Central nous propose ici un article sur comment développer avec Objective-C. Le gros avantage de cet article est qu’il date de 2008 et que donc il prend en compte Objective-C et plus particulièrement la nouvelle syntaxe des accesseurs. Il aborde entre autre la création d’une classe, l’appel d’un méthode, la gestion de la mémoire, etc.

Lire l’article Learn Objective-C

20 April 2008

Développer en Cocoa avec Python

Même si la manière classique pour développer une application Cocoa est d’utiliser le langage Objective-C, il est aussi possible d’utiliser le langage Python grâce à PyObjC. De plus, la version 2.0 de PyObjC est livré en standard avec Mac OS X Léopard ce qui permet de s’en servir très facilement.

Vous pour retrouver sur le site de PyObjC, quelques exemples ainsi que de la documentation. On peut aussi retrouver un article sur l’Apple Developer Connection qui est malheureusement un peu ancien.

J’essairais à l’occasion de trouvez quelques ressources sur l’équivalent dans le monde Ruby : RubyCocoa

04 April 2008

La différence entre Cocoa, Carbon et Objective-C

Il n’est pas toujours facile lorsque l’on débute dans développement sous Mac OS X de bien faire la différence en Cocoa, Carbon et Objective-C. Voici donc la définition de chacun :

  • Objective-C est une langage de développement que l’on peut voir comme le langage C avec la gestion de la programmation orienté-objet. Il fonctionne par envoie de message entre les objets, et ressemble donc beaucoup plus à ce niveau là à Smalltalk qu’a C++. Pour une description détailler, la page wikipedia sur Objective-C vous permettra d’aller plus loin.
  • Cocoa est un framework de développement, c’est à dire un ensemble d’objet et de fonctions permettant de faciliter la vie du développeur. Il est écrit pour et en Objective-C.
  • Carbon est lui aussi un framework de développement mais il est conçu pour être utilisé avec C et C++ principalement. On peut le voir “en gros”, comme un framework de transition entre le développement Mac OS 9 et le développement avec Cocoa.

Pour prendre un exemple d’actualité, Photoshop CS 3 et la future version 4 sont écrit avec Carbon, mais il est prévu pour la version CS 5 de le passer sous Cocoa.

04 March 2008

Développement Mac : les blogs et sites français

Les ressources en anglais ne manquent pas sur le développement Mac, mais quant il s’agit de trouver des informations en français, cela devient plus difficile. Voici donc une liste de sites intéressants sur Cocoa, Objective-C, XCode, etc. en français :

Par contre, je n’ai trouvé aucun blog en français avec des articles récents (au moins un article en 2008). Si vous en connaissez ou que vous tenez vous-même un blog où ces sujets sont abordés, merci de me laisser un commentaire. Je serais content de pouvoir mettre en place un Planet Cocoa Fr.

Il existe aussi beaucoup de ressources assez anciennes et plus forcement très à jour. Voici quand même les principales :

  • Cocoa X, surtout des articles mais qui datent de 2004 ou avant
  • Project Omega, des articles, des astuces mais visiblement en sommeil depuis 2006.
  • MacTouch, quelques articles de 2004/2005.

27 February 2008

Apprendre XCode, Cocoa et Objective C gratuitement

Le site CocoaLab propose un livre gratuit au format PDF sur le développement Cocoa et Objective-C sous XCode. De plus le livre à été mis à jour pour XCode 3 et Mac OS X 10.5 (Leopard). Le livre s’appelle Become An Xcoder et a été écrit par Bert Altenburg, Alex Clarke et Philippe Mougin.

12 February 2008

Cocoa / Objective-C et les livres

La meilleure manière d’apprendre un langage ou une technologie est pour moi de lire un livre. Cela ne fonctionne pas forcement avec tout le monde, mais en ce qui me concerne, c’est l’idéal. J’ai donc un peu cherché les différents livres qui existent dans le monde Objective-C / Cocoa et voici mes découvertes :

J’ai en ce qui me concerne décidé de partir sur Cocoa Programming for Mac OS Xstyle=border:none que suis en train de lire et que je trouve vraiment bien. Facile à lire, facile à mettre en oeuvre, avec une répartition entre la théorie et la pratique vraiment idéale. Aaron Hillegass est vraiment un très bon auteur.

Je ferais une description plus détaillé et plus complète du livre une fois que je l’ai fini (et que j’aurais mon Mac Book Pro pour tester ce que j’aurais appris).

Pour finir, il existe aussi des livres pour les personnes ayant un niveau avancé, mais je ne m’y suis pas intéressée pour l’instant et je reviendrais dessus plus tard quand je serais une expert du développement Mac OS X ;)