Livre: Les design patterns de Cocoa

12032010 Dans: Cocoa

Les éditions Pearson Education publieront prochainement Les design patterns en Cocoa.

Ce livre, traduit en Français par Hervé Soulard, déjà à l'origine de l'excellente traduction de Programmation Cocoa sous Mac OS X, expose la manière dont les design patterns sont mis en œuvre dans Cocoa.

Ce livre intéressera les programmeurs sérieusement investis dans la technologie d'Apple, puisqu'y sont expliqués les choix techniques opérés par ses ingénieurs, et exposées certaines techniques avancées dans l'utilisation des classes de Cocoa et du Runtime Objective-C.

L'indépendance de la résolution

20012009 Dans: Cocoa, Mac OS X

La résolution

Commençons par rappeler ce qu'est la résolution. On l'exprime habituellement en points par pouce. C'est à dire qu'il s'agit du nombre de points — pour un écran, des pixels — alignés sur un pouce de longueur (1 pouce = 2,54 cm).
L'abréviation ppp (points par pouce) se rencontre, mais l'abréviation anglaise dpi (Dots per Inch) est la plus courante.

Paradoxe: "Plus les pixels sont nombreux, et moins on les voit".

Des pixels aux centimètres

Si vous avez bien suivi, vous pourrez tenter de répondre à cette question: combien faut-il aligner de pixels pour tracer un segment d'un centimètre de long ? Réfléchissez.

En fait il vous manque quelques données pour répondre. Alors, prenons l'exemple de l'écran de mon iMac: il affiche 1440 x 900 pixels. Sa diagonale mesure 17 pouces. Les pixels sont carrés.

Calcul des dimensions physiques de l'écran

Commençons par calculer les dimensions physiques de l'écran, grâce au théorème de Pythagore:
largeur^2 + hauteur^2 = diagonale^2

Sachant que
largeur = (1440/900) x hauteur = 1,6 x hauteur

Vous devez trouver:
hauteur = 9 pouces
largeur = 14,41 pouces

Calcul de la résolution

L'écran a donc une résolution de 900 pixels / 9 pouces = 100 points/pouce.

La réponse à la question de départ

En divisant par 2,54, on trouve que 100 ppp correspond à 39,37 points/cm. Il faudra donc aligner 39 pixels pour tracer un segment d'un centimètre de long.

Où veux-tu en venir, Renaud ?

Ça vient ! Prenons l'exemple de votre traitement de texte habituel. Le format d'impression est un A4 et le zoom est réglé à 100%. Comment se fait-il alors que lorsque je superpose une feuille A4, la feuille à l'écran est plus petite ?

Réponse: parce que le traitement de texte part du principe que la résolution de votre écran est de 72 ppp. Pourquoi 72 ppp ? C'est historique; dans les années 90, c'était une résolution courante pour un écran. Sous Windows, il me semble qu'on utilise 85 ppp, ce qui est un peu plus proche de la réalité. Tout ça n'est tout de même pas très WYSIWYG.

Donc, si je veux voir la page à la taille réelle sur mon iMac, il faut que je règle le zoom à (100 / 72) = 139%.

Pourquoi ce problème n'est pas encore résolu en 2009 ?

Notez bien que la résolution de chaque écran est différente, elle est plus dense encore pour l'écran de mon MacBook. Des API existent pour connaître la définition (en pixels) de l'écran. On peut sans doute également obtenir sa diagonale (en pouces) et procéder au calcul vu plus haut. Et le problème sera résolu: le traitement de texte fera le calcul de la résolution et affichera sur l'écran de mon MacBook la feuille A4 avec une largeur mesurant très exactement 21 cm.

Bien. Imaginons que j'ai maintenant l'idée saugrenue de brancher à mon MacBook un écran externe d'une résolution de 100 ppp, et que je place la fenêtre à cheval entre les deux écrans: ça ne va plus du tout ! La page est maintenant trop grosse sur l'écran externe !

Ce problème est insoluble au niveau applicatif. La seule possibilité est que le Window Server fasse les adaptations.

Les réflexions d'Apple sur le sujet

L'indépendance de la résolution était annoncée pour Mac OS 10.5 et ne fut finalement pas présente. Il est possible qu'elle fasse son apparition dans 10.6. Il existe pourtant déjà quelques API:

Resolution Independence Guidelines

Je vous fait un petit résumé:

  • Les ingés d'Apple ont l'air de s'embrouiller avec tout ça.
  • Il faudra dessiner à 72 ppp. Quartz effectuera ensuite les conversions pour avoir les coordonnées en pixels.
  • Il est pour l'instant possible de changer le facteur d'agrandissement à l'aide de l'application Quartz Debug, dans le menu Tools > Show User Interface Resolution. Essayez, c'est marrant.

Ce petit essai devrait vous faire comprendre la complexité de la chose: c'est moche, on voit plein de gros pixels. Il va donc falloir rendre l'interface utilisateur entièrement vectorielle. C'est un énorme travail, et il est donc compréhensible qu'Apple ne l'ait pas encore complètement implémenté.

En vrac de Noël

29122008 Dans: En vrac, iPhone / iPod Touch, Liens, Objective-C

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.

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 :

Livre: Programmation Cocoa sous Mac OS X

26112008 Dans: Cocoa, Livres

CouvertureOn l'attendait avec impatience, la voici. La version française de la troisième édition de Cocoa Programming for Mac OS X vient de paraître.

L'éditeur a changé (ce n'est plus Eyrolles), et nous ne pouvons pas encore vous donner notre avis sur la traduction, mais la version anglaise reste le seul livre indispensable à tout programmeur Cocoa. À commander au père Noël d'urgence.

Note de Fabien: Je peux vous dire qu'il est vraiment sympa pour l'avoir lu dans le cadre de la relecture technique de la version française.

Le garbage-collector de Leopard

13112008 Dans: 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 :

Avantages et inconvénients de Cocoa

20102008 Dans: Articles, Cocoa

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.

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.

Une deuxième interview sur Cocoa.fr et il s'agit cette fois ci de Patrick Geiller, l'auteur de JSCocoa.

Lire la suite

Il existe déjà des bridges pour Python (PyObjC) et Ruby (RubyCocoa) et voici donc JSCocoa qui permet de développer en Cocoa avec JavaScript.

Pour ce faire, il utilise JavascriptCore (le moteur JS de WebKit) pour vous permettre d'accéder aux librairies C et Objective-C. Il permet de plus d'étendre des classes Objective-C en Javascript. Des exemples de code avec les versions Objective-C et JSCocoa sont disponible sur la page principale du projet.


Sponsors