Ça y est, vous vous êtes décidé à vous lancer dans la programmation Cocoa. Bravo, mais il va falloir d’abord installer les outils de développement.

Où trouver les outils¶

Première bonne nouvelle, ces outils sont gratuits. Vous les trouverez à deux endroits:

• sur le deuxième DVD de Mac OS X qu’il soit livré avec votre machine ou acheté séparément
• sur l’Apple Developer Connection (ADC). Il faut s’inscrire sur le site. Il existe plusieurs types de comptes ADC, mais celui de base est gratuit, et vous permettra de télécharger entre autres les outils développeur.

Vous devez savoir que, selon la version de Mac OS X qui anime votre machine, vous ne pouvez pas utiliser n’importe quelle version des outils. Ainsi XCode 2.5 fonctionne sous Mac OS 10.4 et 10.5, mais XCode 3.0 est réservé à 10.5. La version actuelle est la 3.1.1.

Ce qui est installé¶

Une fois l’installation (des plus classiques) terminée, vous trouverez un dossier Developer à la racine de votre disque dur. Nous n’allons pas ici détailler ce qui fut installé (ne serait-ce que parce que je ne connais pas tous les outils); concentrons-nous sur ceux du quotidien:

XCode¶

Il s’agit d’un intégré de développement, dédié avant tout au développement Cocoa: un éditeur de texte, un éditeur des paramètres des applications, un modélisateur Core Data et de quoi s’interfacer avec les outils externes.

Les programmes en ligne de commande¶

XCode est surtout est éditeur de texte amélioré, il n’inclut pas de compilateur, mais fait appel au compilateur libre gnu C (tapez gcc dans le terminal pour vérifier qu’il est bien là), au débogueur gnu debug (gdb), ou au gestionnaire de version subversion (svn).

Vous pouvez évidemment utiliser ces outils indépendamment de XCode, mais il vous est toutefois conseillé d’installer ces outils par le biais de l’installateur de XCode, qui se chargera de bien configurer votre environnement.

Interface Builder¶

Mon programme favori, qui permet d’éditer les interfaces utilisateur. Nous verrons son utilisation de base dans un très prochain article.

Analyse des performances et débogage¶

De nombreuses applications sont fournies pour vous aider à améliorer votre application :

• MallocDebug, ObjectAlloc pour analyser les allocations et les fuites mémoire
• Instruments, Sampler et Shark pour l’étude des performances et un tas d’autres petites applications plus spécifiques que vous aurez l’occasion d’essayer.

Quartz Composer¶

Introduit avec Mac OS 10.4, il s’agit d’un programme singulier qui permet de composer des animations en couchant des blocs fonctionnels sur une feuille et en les reliant. Les animations résultantes peuvent être utilisées dans vos applications Cocoa, pour créer des économiseurs d’écran, ou être lues directement par QuickTime. Le formidable PulpMotion repose sur QuartzComposer.

Dashcode¶

Il s’agit d’un éditeur, à mi-chemin de XCode et Interface Builder, pour concevoir les Widgets. Il permet de concevoir leur interface utilisateur et de saisir directement le code JavaScript.

Nous passerons à quelque chose de plus concret dans le prochain article. En attendant, joyeuse installation !

Après l’annonce du 1er octobre, Apple vient de modifier les conditions d’utilisation du SDK iPhone. Le nouveau contrat d’utilisation est disponible au format PDF sur le site Apple.

Apple vient aussi de mettre en place un forum en version beta pour les développeurs iPhone ayant souscrits aux programmes Standard, Entreprise ou University.

Preuve de l’intérêt grandissant des langages dynamiques comme Ruby ou Python parmi les développeurs, Apple vient de publier une article sur le développement d’applications Cocoa avec MacRuby :

• Developing Cocoa Applications Using MacRuby

Après la courte présentation de Cocoa de la dernière fois, cet article vous aidera à décider s’il s’agit d’une bonne solution de développement pour votre projet.

Avantages¶

Rapidité de développement¶

Certains avancent que le développement sous Mac OS X avec Cocoa est 5 fois plus rapide que le même développement sous Windows. Je suis mal placé pour confirmer, mais comparé à d’autres outils que je connais, Cocoa est effectivement très efficace, de part la nature dynamique du langage Objective-C (tout n’a pas besoin d’être figé à la compilation) et de la qualité générale des classes. Il me semble qu’Apple possède également une avance conceptuelle, avec les récentes technologies Core Data et Cocoa Bindings. Cocoa n’est pas toujours suffisante pour coder une application, mais les autres technologies comme Core Audio ou Core Graphics présentent d’excellents compromis puissance/facilité de mise en œuvre. N’oublions pas non plus que Mac OS X est un système Unix, et nous profitons donc des qualités de ces systèmes.

API mâtures¶

Cocoa est loin d’être une nouveauté, n’étant qu’une évolution d’OpenStep, le système de développement qui existait déjà sous NeXTSTEP avant qu’il ne devienne Mac OS X. Il est connu que Tim Berners-Lee a développé le premier navigateur web et le premier serveur web grâce à OpenStep. Ces outils de développement évoluent depuis plus de vingt ans; malgré leur âge, ils sont toujours sans équivalent sur les autres plateformes.

Comportement standard¶

Cocoa est ainsi faite que les choses qui sont habituelles sous Mac OS X sont faciles à implémenter. Que ça vous plaise ou non, votre application suivra en grande partie les canons de Mac OS X et les recommandations d’Apple. En fait, votre difficulté sera parfois de déroger à ces standards !

Inconvénients¶

Portabilité¶

Cocoa n’existe que sous Mac OS X. Il existe bien une implémentation libre d’OpenStep (http://www.gnustep.org/), mais il lui manque les dernière innovations (la compatibilité avec Cocoa n’a rien de totale), il faut que l’utilisateur l’installe et les auteurs bénévoles la font progresser lentement. De même, le langage Objective-C — le plus habituel pour développer avec Cocoa — n’existe que sur Mac. Certes, Objective-C est intégré au compilateur libre et multiplateforme gnu c, mais ce compilateur est inutile sans les classes de bases (telles que NSObject, NSArray, NSDictionary, etc.).

Pour un développement multiplateforme, mieux vaut donc aller voir ailleurs, ou développer uniquement l’interface graphique avec Cocoa, et le reste en C++, par exemple (on peut mélanger Objective-C et C++ dans certaines limites).

Difficulté¶

Cocoa n’est pas pour les débutants. N’espérez pas y comprendre grand chose si vous ne connaissez ni le langage C, ni la programmation objet. Elle introduit par ailleurs de nombreux concepts, souvent étrangers aux développeurs formés à d’autres frameworks. Sa puissance est réelle, mais il faudra investir du temps et de l’énergie pour en profiter.

Outils¶

L’outil principal pour programmer Cocoa, c’est XCode, l’intégré de développement d’Apple. Et comment dire… il s’améliore à chaque version, mais c’est toujours pas ça. Le principal soucis provient de l’éditeur de texte, de sa lenteur, de son indentation automatique agaçante, tout comme sa complétion automatique. Mais on pourrait aussi citer les interfaçages avec gdb (débogueur) et Subversion (gestion de version) moyennement au point, ou encore les outils pour créer des diagrammes de classes, qui eux, sont carrément risibles.

Programmes d’exemple¶

Je me suis toujours demandé ce que foutait Apple avec ses programmes d’exemple. À moins de tomber sur une perle (mais de mémoire, je ne vois pas), les programmes d’exemple souffrent d’un ou plusieurs des maux suivants :

• pas commentés, et brouillons
• purement démonstratifs et inutilisables dans un autre contexte
• concernent vaguement le sujet
• inutilement compliqués, voire des pans entiers du source ne servent à rien
• mémoire gérée à la truelle

Heureusement que d’autres développeurs proposent les leurs.

P’tête ben un avantage, mais p’tête ben un inconvénient¶

Une communauté réduite¶

Comme souvent, c’est à la fois un avantage — les gens s’entraident, les nouveaux sont bienvenus — et un inconvénient — on galère parfois pour comprendre comment ça marche, il est difficile d’obtenir des réponses très techniques, et la documentation est parfois limitée.

Toutefois, la communauté s’agrandit, d’ailleurs, vous me lisez ! M’est avis qu’un certain téléphone tactile n’est pas étranger à ce nouvel engouement.

La solution la plus simple pour développer sur iPhone est d’installer et d’utiliser le SDK d’Apple sur votre Mac puis d’utiliser les ressources de l’iPhone Dev Center ou les livres en train de sortir. Tout cela oblige par contre à posséder un Mac et à suivre les règles d’Apple (comme l’impossibilité de tourner en tache de fond). Il est alors possible d’utiliser un certain nombre d’alternatives :

• Le première solution est d’utiliser le SDK Open Source que l’on peut découvrir avec le livre iPhone Open Application Development disponible dès maintenant en PDF, et d’ici peu en version relié. Cette solution vous permettra de créer des logiciels à installer sur un iPhone jailbreaké et qui pourront par exemple tourner en tache de fond.
• La deuxième solution, il s’agit d’un SDK pour Windows qui serait en cours de développement. Il s’agit pour l’instant uniquement d’un blog et pour l’instant il n’y a aucun code ou exécutable disponible. Il reste à voir si le projet aboutira et ce qu’il sera possible de faire avec.

Si vous vous intéressez au développement iPhone / iPod Touch et que l’anglais ne vous rebute pas, vous pouvez lire Mobile Orchard, un blog sur le développement d’applications sur iPhone. On y apprend d’ailleurs que Tap Tap Tap à toujours autant de problème en ce qui concerne la nouvelle direction que prend l’entreprise et que l’application Where To (qui a ramené 200 000$ en 3 mois) est en vente.

Cet article est très important pour Cocoa.fr, car il s’agit du premier article de Renaud Pradenc, un nouveau contributeur sur le blog.

Qu’est ce que Cocoa ?¶

Du point de vue du programmeurs, Cocoa est un ensemble de classes, écrites en langage Objective-C. Certains vous diront que Cocoa sert à créer des interfaces graphiques. Pas seulement! Cocoa permet de créer des applications de tout type, même en ligne de commande. Elle est en fait constituée de trois parties.

Cocoa = Foundation + AppKit + CoreData

Foundation est un ensemble de classes liées aux bas niveaux: gestion des types de données (chaînes, dates, tableaux, dictionnaires…), des fichiers, des connections réseau, etc.

AppKit est la partie plus connue, dédiée à la gestion des interfaces utilisateur. C’est là que se trouvent les boutons, menus et fenêtres.

CoreData est la plus récente, puisqu’elle fut introduite avec le système 10.4. Elle sert à définir une base de données pour gérer la rétention des données.

Voilà ce qu’est Cocoa. Ni plus, ni moins. Il existe d’autres bibliothèques de classes écrites en Objective-C : je pense au récent QT kit, par exemple, ou au wrapper pour mySQL. Il faudra aussi parfois utiliser les API écrites en langage C, c’est en gros ce que l’on nomme Carbon par chez nous. Ce n’est pas sale !

Interface Builder¶

On pourrait dire que cette application fait partie intégrante de Cocoa, puisqu’elle sert à générer les fichiers .nib qui décrivent l’interface graphique. Quand vous découvrirez le principe des targets/actions, la proximité de Cocoa et Interface Builder vous seront évidentes.

À ce propos: Cocoa est faite pour utiliser les .nib. Il faut les utiliser, si, si ! Beaucoup de nouveaux venus (souvent formés à l’école Java et cette horreur de Swing) veulent absolument coder l’interface graphique. Sachez que l’on peut. Mais sérieusement: coder les interfaces à la mano, c’est la préhistoire; même sur mon Atari, j’utilisais un éditeur de ressources. Préférez les .nib, c’est beaucoup plus simple, beaucoup plus flexible, beaucoup moins long.

Et au niveau du langage ?¶

Je ne vais pas y aller par quatre chemin: Cocoa fut écrite en Objective-C, c’est le langage le plus adapté à Cocoa. Il existe ce qu’on appelle des bridges qui permettent d’interfacer Cocoa avec d’autres langages: Java, Python, Ruby, Eiffel, et un tas d’autres. Je ne peux toutefois vous conseiller des les utiliser sans avoir une connaissance de base du couple Cocoa/Objective-C. Cocoa s’appuie sur les mécanismes et conventions de ce langage, et utiliser ces bridges revient à penser en Objective-C et écrire avec la syntaxe de votre langage habituel.

Apple promet qu’on peut apprendre Objective-C en une demi-journée (quand on connaît le langage C et un langage objet): je peux témoigner que c’est vrai. Il ne reste plus ensuite qu’à apprendre Cocoa… ce qui vous prendra des mois ! Ne focalisez donc pas trop sur le langage. Objective-C a certes une syntaxe particulière — faite de crochets dans tous les sens — mais je vous promets qu’elle n’est pas si mauvaise que ça. J’y reviendrai dans un prochain article.

En attendant, n’hésitez pas à laisser vos questions et remarques dans les commentaires.

• Bonjour Patrick, peux-tu te présenter en quelques mots ?

J’ai 30 ans, je programme depuis … longtemps. D’abord en C++ sous Windows, puis PHP, Javascript, et maintenant Cocoa.

• Depuis quand utilises-tu un Mac pour développer, et pourquoi être passer sur Mac ?

Sur Slashdot, beaucoup vantaient OSX. J’ai lu les documentations sur developer.apple.com, découvert Interface Builder et sa façon de ‘dessiner’ les liens entre composants … wow ! Je suis passé sur Mac avec le mini. Cocoa m’a beaucoup influencé : dans mon dernier boulot (web/js), j’avais écrit un framework pour lire un .xml contenant définition d’interface, bindings, règles de resize … tout comme un NIB :)

• Maintenant quelques questions concernant JSCocoa et tout d’abord, depuis quand est-ce que JSCocoa est-il en développement ?

Depuis Juillet. Je voulais un script facile à utiliser dans Cocoa, j’avais eu de mauvaises surprises avec RubyCocoa (rajouter une ligne vide dans une routine stoppait un plantage bizarre !), le bridge de WebKit était limité a Cocoa ‘brut’ (ni fonctions C, ni dérivation, ni structures — pas pratique pour utiliser NSPoint). Ainsi est né JSCocoa … par frustration :)

• Quels sont les atouts de JSCocoa par rapport à un programme en Objective-C/Cocoa ?
  • Avantages
    • Dynamique ! on peut charger du code en runtime facilement, ou taper du code pour inspecter son application, toujours en runtime.
    • Rapide au lancement : le code est interprété au fur et à mesure des besoins. On peut éditer le code (même dans TextEdit !), quitter, puis relancer rapidement.
    • Accès aux fonctions Javascript comme les expressions régulières, bizarrement absentes dans Cocoa.
    • Une syntaxe à points : a.b.c.d au lieu de [[[a b] c] d].
    • (peut-être) simplification de la localisation. Plutôt que NSLocalizedString et printf, donner une petite fonction Javascript qui va renvoyer une string dépendant du langage.

            // Code application
            myNSTextField.stringValue = pluralizeNoun('book', myArray.count)
            // Code localisation
            function pluralizeNounUS(noun, count) {
                return count + ' ' + noun + (count>1 ? 's' : '' )
            }
            var noun1 = { 'book' : 'buch', 'shoe' : 'schuh' }
            var noun2 = { 'book' : 'bücher', 'shoe' : 'schuhe' }
            function pluralizeNounDE(noun, count) {
                return count + ' ' + (count>1 ? noun2[noun] : noun1[noun] )
            }
            </pre></code>

         On a un code principal (JSCocoa, ou même ObjC) le plus simple possible, et un code localisation js qui peut récupérer toutes les informations nécessaires pour afficher une traduction correcte.
*   Désavantages :
    *   comme Javascript n'est pas compilé, une erreur ne sera pas détectée au
        lancement, seulement à l'activation du bout de code correspondant. D'où la
        nécessité de tests pour vérifier le programme une fois lancé
    *   Javascript est plus lent que ObjC. JSCocoa est encore plus lent — parfait
        pour écrire la logique, mais on oubliera le raytracer JSCocoa ;)