Cocoa.fr

Developpement Mac, Objective-C, Cocoa et Swift

Categorie

Cocoa

55 article(s) dans cette categorie.

17 June 2010

Postes de développeurs iPhone freelance

Si vous êtes développeurs Objective-C / Cocoa, l’agence Web Un Oeil sur Tout recherche un ou plusieurs freelance pour travailler sur une application iPhone. Pour plus d’informations et de détails concernant l’application, contactez Nicolas CORNET.

PS: Si vous êtes à la recherche de développeurs iPhone, merci de m’envoyer un email ou de laisser un commentaire pour que je sache s’il y aurait du monde intéressé par une section “Emplois” sur Cocoa.fr.

12 March 2010

Livre: Les design patterns de 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.

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

27 October 2009

Le développement, plus que du code

Pour changer, je vous propose aujourd’hui un billet qui ne parlera pas de code :

  • The Failure of the GPL est une réflexion sur la licence GPL et ses échecs. Le document dans son ensemble est très intéressant, mais la première page l’est tout particulièrement pour les développeurs Mac, car elle aborde le choix de LLVM par Apple et son abandon progressif de GCC.
  • From the Mouths of Developers est une interview très intéressante de divers auteurs de logiciels qui ont utilisés MacHeist afin de promouvoir leurs applications.
  • iTunes and Cocoa, une reflexion très intéressante de John Gruber sur iTunes et le peu d’intérêt actuel qu’aurait Apple à réécrire son logiciel en Cocoa.

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 :

02 July 2009

Formation Cocoa avec Aaron Hillegass

Si vous êtes disponible du 13 au 17 juillet et que vous pouvez vous rendre à Francfort en Allemagne, il reste une place de disponible pour la formation Cocoa I Bootcamp avec Aaron Hillegass (l’auteur de Programmation Cocoa sous Mac OS X). Il y a juste un dernier détail concernant cette formation, elle coûte malheureusement quand même 2800 €.

De manière plus générale, Big Nerd Ranch propose un certain nombre de formations sur des sujets aussi divers que Cocoa, Objective-C, Python, Django, Android, etc.

16 June 2009

De NeXTSTEP à Cocoa : Interview d’Erik Buck

Cocoa et Mac OS X sont relativement récents, mais les technologies dont ils sont issus (NextStep et le système d’exploitation Next) existent depuis plus de 20 ans. InformIT nous propose ici une interview de Erik Buck, développeur NextStep / Cocoa depuis quasiment aussi longtemps que la plate-forme existe. Il aborde l’évolution du framework à travers les années et l’utilisation des design patterns avec Cocoa et Objective-C :

Erik Buck est d’ailleurs l’auteur du livre Cocoa Design Patterns qui devrait être disponible d’ici la fin de l’année.

02 March 2009

En vrac

Aujourd’hui ça va du développement de jeu, aux livres en passant par des interviews de développeurs :

19 February 2009

Des ressources Cocoa en français

Les ressources en français concernant Cocoa et le développement sur Mac / iPhone sont relativement rare, alors quand plusieurs sont mise en ligne la même semaine, je ne peux m’empecher de vous les signaler :

22 January 2009

L’actualité de ces derniers jours

Après quelques jours sans billets de ma part, voici une grosse sélection des dernières actualités utiles pour les développeur Mac :

  • Cocoa for Scientists est une série d’article pour apprendre àutiliser Cocoa dans des applications scientifiques. Cela va de la présentation de données en 2D ou 3D, à la gestion du réseau avec Bonjour, en passant par la gestion des threads.
  • pysmell est un outil qui propose de l’auto-complétion du code Python dans différents logiciels dont TextMate.
  • Si vous pouvez vous rendre en Angleterre le 16 et 17 Avril 2009, essayer de faire à tour à MacDev 2009, la conférence pour les indépendants sur le développement Mac. En tout cas, la liste des conférenciers est particulièrement intéressante.

Et parce que Cocoa c’est aussi l’iPhone, voici quelques liens en provenance de Mobile Orchad qui peuvent vous être utiles :

Pour finir, je voudrais juste signaler que je vais dans la journée migrer le site sur un nouveau serveur. Les commentaires seront désactivés sur l’ancien serveur. Si vous pouvez ajouter des commentaires, c’est que vous voyez la nouvelle version.

20 January 2009

L’indépendance de la résolution

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é.

22 December 2008

Pour quelles versions de Mac OS X développer ?

En ce moment, l’une des questions les plus présentes dans mon esprit, au sujet du développement de Marquise, est sous quelles versions du système d’exploitation mon application devra être capable de tourner. L’idéal serait de gérer le maximum de versions d’OS X. Cependant, cela présente des contraintes techniques, mais surtout économiques.

Les avantages d’assurer la compatibilité avec 10.4 (voire 10.3)

Ou plutôt, le seul avantage, mais un gros avantage: pouvoir toucher un maximum de clients. Voilà maintenant sept ans que la première version de Mac OS X est sortie. Il faut être conscient qu’il y a sûrement plus de machines tournant sous les OS 10.0 à 10.4 cumulés que Mac OS 10.5.

Il faut toutefois relativiser: la plupart sont tout de même sous 10.2 à 10.4, pour deux raisons. La première, c’est que les améliorations de 10.0 à 10.1 à 10.2 à 10.3 sont très visibles. L’autre raison, c’est que la reprise des ventes de Mac s’est faite lorsque 10.4 était le système actuel.

Pourquoi j’avais fixé le ticket d’entrée à 10.4

Une raison technologique: Core Data

Cette technologie fut introduite dans OS 10.4. Apple la présente comme une solution permettant de ne pas s’occuper de la gestion des fichiers, ni de l’Undo, avec à la clef un gain de productivité. J’ai été très déçu par Core Data (ce sera l’objet d’un autre article), que j’ai remplacé depuis par un enregistrement en XML. Aujourd’hui, j’utilise la classe NSXMLDocument, qui n’est disponible qu’à partir de 10.4.

Une raison pratique: je ne peux pas tester sous des versions antérieures

Ma machine principale est un iMac G5 sous 10.5, qui était livré avec 10.4. Je me suis donc acheté un disque dur externe et y est installé 10.4 pour mes tests. Il me faudrait une autre machine pour tester sous 10.3.

Une raison de puissance

Une machine sous 10.3, je vois ce que c’est: mon vieil iMac G3. Cette machine ne pourra jamais faire tourner Marquise qui manipule des images par dizaines. Fixer le système minimum à 10.4 permet de se limiter aux machines capables de faire tourner 10.4 correctement, c’est à dire les G5 et les tous derniers G4.

Pourquoi j’envisage de mettre le ticket d’entrée à 10.5

Comme je l’écris plus haut, je dois redémarrer pour tester Marquise sous 10.4. En pratique, cela se déroule ainsi: je copie l’application sur une mémoire USB, je redémarre avec Option appuyée et sélectionne mon disque externe pour le démarrage. Enfin, j’arrive sous 10.4, je lance Marquise, et m’écrie: “Bon dieu, ce que c’est moche !”. Ce qui m’intéresse en particulier, c’est un des boutons de la barre d’outils qui devrait présenter un petit triangle, indiquant qu’un menu s’affiche, mais qui ne le fait pas. Je dois alors retourner sous 10.5, trouver un compromis sur la taille du bouton, reconstruire l’appli, la remettre sur la mémoire USB, redémarrer, etc. On peut perdre des heures sur ces manipulations. Évidemment, la solution serait de me payer une nouvelle machine, mais il va falloir que Marquise me rapporte quelques thunes avant.

D’autres développeurs, je pense à ceux de Delicious Library ou RapidWeaver, ont carrément fait le choix de ne plus développer que pour 10.5. La première raison est celle que je viens d’évoquer: maintenir leur logiciel pour deux versions d’OS X représente trop de boulot, par rapport au gain économique attendu. La deuxième raison est technologique: ainsi Delicious Library fut la première grosse application à utiliser Core Animation (introduit avec 10.5). On peut trouver cela tape-à-l’œil, mais c’est très certainement séduisant pour les clients potentiels qui essaient le logiciel.

À chaque fois que sort un de ces logiciels dédiés à 10.5, on peut lire les même commentaires aux nouvelles de MacGénération: “c’est bien dommage qu’il ne tourne pas sous 10.4”. Ce que je pense, c’est que les deux tiers des gens qui laissent ce genre de messages sont sous… 10.5. Car la réalité la voici: les gens de Delicious Monster ou Real Mac Software ne sont pas suicidaires. S’ils prennent ce genre de décisions, c’est parce qu’il savent que leurs clients sont en grande majorité (au moins 85%) sous 10.5. Ils le savent par les statistiques d’accès à leur site web. Ce n’est pas contradictoire avec ce que j’écrivais plus haut: que la majorité des machines sous OS X, étaient sous 10.4 ou antérieures. En effet, un client qui est prêt à installer et payer un shareware n’est pas un utilisateur moyen.

Ma décision alors ?

À vrai dire, je n’ai toujours pas décidé. Mon code peut encore tourner sous 10.4. Mais un élément va être décisif: l’arrivée de 10.6, certainement à la même période que la première version commerciale de Marquise. Je devrai alors travailler sous trois versions d’OS X. Je me dis que limiter à 10.5 serait une bonne idée, rien que ne pas avoir de clients qui se mettent à râler quand j’abandonnerai 10.4, ce qui arrivera. Au final, je crois que je vais regarder les statistiques de mon site web quand je proposerai les premières versions béta en téléchargement pour décider.

09 December 2008

La documentation indispensable

Ce site n’est pas l’endroit pour prodiguer un cours sur Cocoa. Non seulement, le sujet est trop étendu, mais aussi, la documentation existe déjà.

La doc d’Apple

Vous trouverez cette documentation sur le site developpeurs d’Apple, mais le plus pratique est de la consulter sous XCode via le menu Help > Documentation. Il s’agit d’une documentation de référence: elle contient beaucoup, en fait beaucoup trop d’informations; d’autant plus qu’on y trouve beaucoup de blabla. Il s’agit pourtant d’un outil quotidien, qui répondra à presque toutes vos questions, quand vous saurez où chercher.

Même si Apple a fait des efforts pour fournir quelques guides d’introduction, vous attaquer de front à la doc ne peut que vous impressionner, vous noyer et finalement vous dégoûter, ce qui nous amène à…

Cocoa Programming for Mac OS X

Couverture Cocoa Programming À sa sortie en 2002, ce livre fut accueilli avec un grand soulagement. Son auteur, Aaron Hillegass, était formateur pour NeXT avant de monter sa propre société de formation, et propose un livre simple d’accès, destiné à vous procurer le bagage minimum. À vrai dire, si vous posez des questions sur les forums, on s’attendra à ce que vous l’ayez lu, sinon on vous invitera souvent à le faire.

Les sujets couverts sont les suivants:

  • utilisation de base de XCode et d’Interface Builder
  • le langage Objective-C: syntaxe, gestion mémoire (y compris le ramasse-miettes), protocoles, catégories, propriété
  • Foundation
  • AppKit
  • Principes courants de Cocoa: délégués, archivage, notifications
  • Key-Value Coding, Bindings, Core Data
  • Core Animation

La grande force de ce livre, c’est son approche TP. Point de chichi: l’auteur vous montrera par exemple une fenêtre en écrivant “débrouillez vous pour que ça ressemble à ça”. Il s’agit d’un enseignement progressif: les objectifs sont fixés, quelques principes expliqués, puis vient le codage. En fin de chapitre, se trouve un encart “pour les plus curieux” où l’auteur fournit quelques informations sur le fonctionnement de Cocoa. Enfin, sont proposés des défis: il s’agit pour le lecteur de travailler tout seul cette fois-ci, et d’améliorer le programme. Et il est utile de le préciser: tous les défis sont faisables.

Il ne s’agit pas d’un livre de référence, on n’y découvre que quelques classes, mais ce sont des classes représentatives, et l’essentiel de chaque concept est expliqué pour pouvoir approfondir avec la doc d’Apple par la suite.

Couverture Programmation Cocoa Le livre a été mis à jour à la sortie de Mac OS 10.5. Cette troisième édition, traduite en français, vient tout juste de paraître, sous le titre Programmation Cocoa sous Mac OS X.

En résumé: conseillé sans réserve aucune, pourvu que vous ayez les pré-requis: connaître le langage C et avoir des notions de programmation orientée objet.

Objective-Cocoa.org

Il s’agit d’un forum en français qui existe depuis deux ans. L’ambiance y est détendue, les débutants bienvenus même si des usagers de Cocoa qui ont de la bouteille y participent.

Le guide du débogage

Il arrive un moment où le débogage à base de NSLog() montre ses limites. Si n’explique pas l’utilisation du débogueur, le guide suivant fournit quantités d’astuces: Technical Note TN2124.

La mailing-list d’Apple

Apple a mis en place des listes sur divers sujets. Celle qui nous intéresse est bien évidemment celle de Cocoa. À vrai dire, utiliser cette liste est à faire en dernier recours. En effet, pour poser une question, il est nécessaire de s’y abonner — normal, me direz-vous — sauf que vous allez recevoir de l’ordre de 100 messages par jour, la plupart n’ayant pas d’intérêt pour vous. Je vous conseillerais donc d’activer le mode “digest” dés le départ !

Reste qu’on y trouve des gens qui ont une connaissance poussée de Cocoa, et même parfois des ingés d’Apple. À ce propos, ces employés le font bénévolement, un hot-dog à la main, ou entre 20 et 22h. Cela dit, vous pouvez considérer que si vous n’obtenez pas la réponse sur cette liste, c’est que personne ne l’a.

Les sites spécialisés sur Cocoa

StepWise L’un des plus vieux sites. Contient beaucoup d’articles techniques et très intéressants.

Cocoa Dev Central Quelques articles d’introduction, et des liens.

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 :

26 November 2008

Livre: Programmation Cocoa sous Mac OS X

Couverture On 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.

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.

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.

28 October 2008

Cocoa et le “monde extérieur”

Il y a actuellement une actualité importante en ce qui concerne Cocoa et le développement multi-plateforme :

  • Trolltech, l’éditeur de Qt, vient de sortir une preview de la version 4.5 de Qt qui supporte Cocoa et les applications 64-bits : Same old, same new: 4.5 Technical Preview.
  • Le blog Mac Daddy World nous présente Cocotron, qui permet de compiler une application Objective-C/Cocoa pour Windows. Tout Cocoa n’est pas disponible, comme par exemple CoreData, mais le projet mérite d’être suivi : Adventures in Cocotron.

28 October 2008

Installation des outils développeur

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

14 October 2008

Interview de Patrick Geiller, auteur de JSCocoa

  • 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' 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 ;)
  • Quels sont les prochaines évolutions du projet et quels contributions recherche tu pour le projet (documentation, code, etc.) ?

Côté contributions, je recherche des gens pour écrire des exemples — n’importe quel petit projet est le bienvenu ! Et des développeurs iPhone pour tenter de faire marcher JSCocoa sur l’iPhone.

  • D’autres remarques ou un message à faire passer aux lecteurs du blog ?

J’aurai bientôt besoin de beta testeurs pour ma première application commerciale. Avis aux amateurs :)

09 October 2008

JSCocoa, pour développer avec Cocoa en Javascript

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.

08 October 2008

Vive la suppression du NDA

La levée du NDA commence à sérieusement porter ses fruits en ce qui concerne le nombre de ressources disponible sur Internet concernant le SDK iPhone :

30 September 2008

Mise à jour d’applications

Jusqu’à maintenant, quant l’on voulait mettre en place un système de mise à jour de son application, il existait Sparkle. Google vient de publier un logiciel similaire nommé Update Engine (Plus d’infos sur le blog Google).

La question que l’on se pose alors est pourquoi utiliser Update Engine si Sparkle fonctionne très bien. Sur le groupe de discussion Update Engine, Greg Miller nous répond :

  • Update Engine est de plus bas niveau que Sparkle, et il permet de mettre à jour des applications appartenant à root ou des modules kernel.
  • Update Engine permet de gérer plusieurs applications (un peu comme le système de mise à jour de Mac OS X).
  • Par contre, il semple plus complexe à mettre en place que Sparkle dans les cas simples.

Si quelqu’un à l’occasion de tester, ses remarques sont les bienvenues. Et pour en savoir plus sur l’integration dans une application, voici un petit screencast.

21 September 2008

En vrac

Après quelques jours très chargés de mon coté, voici quelques nouvelles du monde Cocoa :

  • Cocoa Programming: A Quick-Start Guide for Developers, un nouveau livre sur le développement Cocoa chez The Pragmatic Programmers qui vient de sortir en version beta. Je trouve de plus la formule PDF en beta plus livre lors de sa sortie (fin mars 2009) à 41,75$ particulièrement intéressante (le PDF seul est à 22$). Ça permet de commencer à lire de livre dès maintenant et d’avoir tout de même une version papier plus tard (pour les fétichistes des livres papiers comme moi).
  • Cocoa Tutorial: Adding Plugins to a Cocoa Application, un tutoriel du site Cocoa Is My Girlfriend sur l’ajout d’un système de plug-in (greffons) à une application Cocoa.
  • A Cocoa application driven by HTTP data, qui vous permettra de mieux comprendre comment télécharger et traiter une page web avec Cocoa (en utilisant NSXMLDocument pour parser la page et XPath pour extraire le contenu).
  • The iPhone Development Story, ou l’histoire de la création et de la publication d’une application sur l’AppStore, ainsi que les petits problèmes que l’on peut rencontrer.

05 September 2008

Sortie de Cappuccino et Objective-J

280 North, l’éditeur du clone de Apple Keynote 280 Slides vient de mettre en ligne sous licence Open Source (LGPL) son framework Cappuccino ainsi que le langage Objective-J.

Cappuccino permet donc de créer des applications web à la manière de ce que Cocoa permet sur Mac OS X. Objective-J quant à lui est un langage ressemblant à Objective-C et écrit en Javascript.

Il faut donc bien se rendre compte que Cappuccino a pour but de proposer un vrai moyen de créer des applications et pas uniquement de rendre un site plus interactif comme le propose par exemple jQuery ou mootools.

Pour en savoir plus, vous pouvez :

En tout cas, il n’y a pas à dire, mais 280Slides est vraiment impressionnant, et Cappuccino devrait permettre de faire des choses sympathiques.

28 August 2008

Utiliser le GPU avec Core Video, Core Image, etc.

J’ai déjà parlé par le passé d’OpenCL, qui apparaîtra dans Snow Leopard et qui permettra de tirer profit de la puissance des GPU (processeurs des cartes graphiques).

Christophe Ducommun, le développeur de MovieGate parle sur son blog des gains de performances qu’il à réussi à obtenir en utilisant les technologies actuelles de Mac OS X que sont Core Video, Core Image, OpenGL et QuickTime.

Il est passé de 25 images par seconde avec l’ancien encodeur, à 60 images par seconde avec la nouvelle version utilisant le GPU.

Pour plus de détails, vous pouvez lire son billet Nouveau décodeur vidéo.

28 August 2008

Créer des applications Multi Touch pour Mac OS X

Si vous désirez écrire des applications utilisant un écran multi-touch sur Mac OS X, vous pouvez utilisez le framework Touché. Il a été écrit par Georg Kaindl dans le cadre de son Master et est disponible sous licence LGPL 3. Le seul problème ici est d’arriver à obtenir un écran ou une table multi-touch de taille intéressante. Pour finir, voici une vidéo permettant de voir ce qu’il est possible de faire avec :

Touché Multitouch Framework - Simple Demo Apps from Georg Kaindl on Vimeo.


21 August 2008

Le copier / coller pour vos applications iPhone

L’ajout d’une fonctionnalité de copier / coller sur l’iPhone est actuellement en bas de la liste des priorités d’Apple. Il est tout de fois possible de proposer des fonctionnalités de ce type dans vos applications iPhone grâce à OpenClip.

Il s’agit d’un framework pour le développement iPhone qui propose un espace partagé entre les différentes applications une fois que celles-ci sont stoppées. Plus d’informations sont disponibles dans la FAQ et la FAQ pour développeur. Pour finir, la vidéo suivante permet de comprendre en détail le fonctionnement :

Cut and Paste for iPhone from Cali Lewis on Vimeo.

Edition : John Gruber de Daring Fireball a écrit un billet où il explique en détail le fonctionnement de OpenClip, et pourquoi il y a de grandes chances que le système ne fonctionne pas sur le long terme. En fait, ça ne fonctionne déjà plus sur la version 2.1 de l’iPhone OS. Pour plus d’informations, vous pouvez lire Raining on the OpenClip Parade.


15 August 2008

Systèmes de fichiers, FSEvents et fseventer

Voici quelques liens pour comprendre l’évolution du système de fichiers de Mac OS X, de comprendre les FSEvent (évenements du système de fichier) et de les suivre :

  • Mac OS X 10.5 Leopard: FSEvents, une partie de l’article sur Leopard de Ars Technica. Il revient en particulier sur l’évolution du système de fichier de Mac OS X, l’inspiration venant de BeOS et pour finir les FSEvents.
  • fseventer, un utilitaire pour suivre les événements de type FSEvents. Il permet donc de suivre les fichiers modifiés, supprimés, etc.
  • File System Events Programming Guide, le guide d’Apple sur les FSEvents.

17 July 2008

Librairie pour Cocoa Touch

Apple a décidé de ne pas inclure diverses classes Cocoa dans CocoaTouch. Jonathan Wight a donc lancer le projet OpenSource TouchCode qui propose diverses librairies dont :

  • TouchXML, un parseur XML supportant XPath et proposant une API semblable à NSXMLDocument de Cocoa
  • TouchJSON, un parser JSON qui à pour but d’être rapide et d’avoir une consommation faible en mémoire. Ça peut être tout particulièrement utile pour échanger des données avec les API de la plupart des services web “2.0” qui utilise du JSON.
  • TouchSQL, pour manipuler des bases de données SQLite

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.

29 June 2008

Penser comme un programmeur Cocoa

Scott Stevenson vient de publier un article très intéressant sur “Penser comme un programmeur Cocoa” (Thinking Like a Cocoa Programmer). L’article est sympathique, car il n’aborde pas uniquement ce qu’il faut faire, mais aussi ce qu’il ne faut pas faire.

Je vais voir avec Scott Stevenson pour proposer une traduction en français pour les personnes ne parlant pas anglais.

18 June 2008

SproutCore, le framework javascript qui s’inspire de Cocoa

Un nouveau framework Javascript est en train de faire beaucoup de bruit dans la communauté Mac, il s’agit de SproutCore. Il s’inspire de Cocoa et permet réellement de concevoir des applications web comme si l’on utilisait les classes Cocoa. En gros, d’après mes premières recherches dans la documentation, ça me semble assez proche de GWT (Google Web Toolkit) dans le sens où l’on décrit l’interface et que le framework semble s’occuper du reste.

Pour aller plus loin, il est intéressant de regarder :

Je vais regarder ça plus en détail car ça pourra certainement me servir dans un projet actuel. Enfin si j’ai le temps ;(

05 June 2008

Version beta du livre sur RubyCocoa

L’éditeur The Pragmatic Programmers vient de mettre en ligne ligne la version beta de RubyCocoa: Bringing Some Ruby Love to OS X Programming au prix de 22$ pour le PDF seul et 43.75$ pour PDF et la version imprimé lors de sa sortie.

Je n’ai pas trouvé d’extrait ou de table des matières, je ne sais pas pas exactement ce que l’on trouve dedans. Si des personnes l’achètent, je suis preneur d’un retour sur le contenu et la qualité du livre. En attendant, vous pouvez toujours visiter le site du projet RubyCocoa.

22 May 2008

Cocoa Programming for Mac OS X : 3ème édition

La nouvelle version du livre Cocoa Programming for Mac OS X de Aaron Hillegass est maintenant disponible avec quelques modifications depuis l’édition précédente. Certains chapitres qui n’était plus forcement pertinent ont été supprimé et remplacé par des chapitre sur Core Data, Core Animation, les services web ainsi que la gestion de la mémoire avec le garbage collector.

Je vais essayer dès que possible de me procurer une copie afin de pouvoir faire un compte rendu de cette nouvelle édition.

20 May 2008

Utiliser le numéro de révision Subversion dans votre application

Il peut être utile en phase de beta test d’avoir dans votre application le numéro de révision Subversion. Cela permet de définir clairement quel version utilise exactement un utilisateur. La solution nous est proposé ici par Matteo Rattotti dans l’article Sync Svn version and CFBundleVersion in Xcode.

Il s’agit d’un script en Python utilisant PyObjC et qui est lancé au moment de la compilation de votre application.

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.

07 May 2008

Quelques règles pour gérer la mémoire avec Cocoa

Bien que Objective-C 2.0 (disponible avec Leopard) propose la gestion de la mémoire avec un GC (Garbage Collector), il est toujours bon de savoir comment gérer la mémoire avec Cocoa, rien que pour les programmes devant tourner sur Mac OS X < 10.5.

Stepwise.com nous propose donc quelques règles pour gérer correctement la mémoire avec Cocoa dans un article intitulé Very simple rules for memory management in Cocoa. Et pour ceux qui connaîtrait déjà ces quelques rêgles, vous pouvez allez plus loin avec l’article Hold Me, Use Me, Free Me toujours chez Stepwise.com.

30 April 2008

Écrire un serveur web en Cocoa

Je viens de tomber sur un article écrit par Jürgen Schweizer pour MacDevCenter (datant de novembre 2006) sur l’écriture d’un serveur web en Cocoa. Je trouve l’idée assez intéressante, car cela permet d’ajouter une interface à une application pour l’administrer facilement ou accéder aux données de l’application avec différents terminaux. On peut donc par exemple imaginer une application de gestion de Post-it avec une interface web pour accéder aux notes depuis un iPhone/iPod Touch. Pour en savoir plus, lire l’article How to Write a Cocoa Web Server

24 April 2008

Pourquoi passer de Win32 à Cocoa

OSnews nous présente ici un article de Peter Bright publié sur ars technica, et intitulé From Win32 to Cocoa: a Windows user’s conversion to Mac OS X. Il présente pourquoi le développement sur Mac et avec Cocoa est de plus en plus interressant ces derniers années alors qu’au contraire le développement Win32 est de plus en plus lourd (API devant supporter des décisions ayant maintenant 20ans, etc…).

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 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 ;)