Présentation de Cocoa

14102008 Dans: Articles, C, Cocoa

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.

Articles similaires

Partager

6 Réponses à “Présentation de Cocoa”

  1. Géraud.ch
    14 octobre 2008 | 15:23

    "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 !"

    Je débute juste la programmation Cocoa/Objectiv-C et je suis arrivé à la même conclusion: Cocoa a l'air très puissant.... lorsqu'on connaît bien le framework.
    Au travail

  2. Patrick Geiller
    15 octobre 2008 | 17:49

    Un désavantage des NIBs est leur positionnement statique des éléments, du coup la traduction passe parfois mal. La dernière version d'iTunes alerte un message français sur 2 lignes, il est coupé car les devs US ont gardé la place que pour une ligne :)

  3. Renaud Pradenc
    15 octobre 2008 | 19:05

    Patrick, j'étais resté sur l'idée qu'iTunes n'utilisais pas Cocoa. On trouve bien quelques nib dans le package, mais pas l'essentiel de l'interface.
    Mais ta remarque est effectivement pertinente, même si Cocoa offre la possibilité d'étirer automatiquement certains éléments.

  4. Patrick Geiller
    16 octobre 2008 | 14:40

    Je parlais juste des NIBs. Effectivement iTunes n'utilise pas Cocoa, mais je n'avais plus d'autres exemples en tête :(

  5. Teva Merlin
    18 octobre 2008 | 12:51

    Au contraire, le positionnement statique des éléments est un avantage des fichiers NIB pour la traduction. Le travail de traduction est plus long, puisqu'il demande de faire plus que traduire les chaînes de caractères : il faut ajuster manuellement l'aspect de l'interface pour chaque langue, dans Interface Builder. Mais l'intérêt est que le résultat visuel est connu et maîtrisé. Alors qu'avec un positionnement dynamique des éléments d'interface, certes on aura la garantie de pouvoir afficher l'intégralité des chaînes mais on perd le contrôle sur l'aspect final de l'interface et sur la cohérence de l'agencement des divers éléments. Et le traducteur ne peut rien y faire, alors qu'avec les fichiers NIB le traducteur peut retoucher tout cela sans intervention du programmeur.

  6. Renaud Pradenc
    19 octobre 2008 | 11:00

    Oui, mais Patrick a raison pour le cas — certes particulier — qu'il évoque. On est parfois obligé de prévoir une dimension pour un champ sans savoir exactement quel texte y sera affiché, typiquement quand on signale une erreur. Une disposition élastique telle que celle de Swing corrige bien ce problème, mais peut en apporter d'autre, par exemple, une fenêtre qui est trop haute et qui sort du bas de l'écran…

Laisser un commentaire


Sponsors