Cocoa.fr

Developpement Mac, Objective-C, Cocoa et Swift

Migration cocoa.fr

Un blog Mac qui garde l'esprit historique, avec une base moderne.

Theme modernise a partir de la palette d'origine. Architecture prete pour importer les anciens contenus Objective-C, Cocoa et Swift.

18 November 2008 Cocoa.fr

Des ressources sur Cappuccino

J’avais parlé il y a quelques temps de Cappuccino, un framework permettant de concevoir des applications web similaires à ce que l’on trouve sur Mac. Il utilise pour ce faire le langage Objective-J que l’on peut voir comme un mix entre Objective-C et Javascript.

J’ai essayé de l’utiliser il y a quelques semaines, mais la documentation était assez sommaire. Quelques ressources récentes me donne bien envie de le tester à nouveau d’ici peu :

PS: Concernant plus particulièrement Cocoa.fr, j’ai modifié le fil RSS des commentaires pour inclure le commentaire dans son ensemble.

12 November 2008 C

Sortie de LLVM 2.4

La version 2.4 de LLVM, le projet permettant de créer des compilateur auquel Apple attache beaucoup d’importance (voir LLVM : Le futur compilateur d’Apple ? et 2008 LLVM Developers’ Meeting), vient de sortir. Parmi les nouveautés il y a :

  • La gestion des Blocks
  • Beaucoup d’évolutions sur Clang qui devrait permettre à terme de proposer une remplacement à GCC. Il permet déjà à l’heure actuelle de compiler des projets comme SQLite, Lua ou ClamAV ainsi qu’une grande partie des exemples de code Obejctive-C de la documentation Apple.
  • Diverses optimisations concernant la vitesse de compilation.

Pour plus d’informations, vous pouvez lire :

07 November 2008 Design

Développeur sur Mac : Plus qu’un programmeur, un designer

Je parle bien de design

La plupart des gens confondent stylisme et design. Autrefois en français, on distinguait le dessin du dessein; l’homophonie a fait préférer le terme design à dessein, mais l’idée reste: le design, c’est la conception fonctionnelle, comment “marche” l’objet. Le stylisme, lui, n’est lié qu’à l’apparence d’un objet (et non pas son esthétique, il n’y a pas de notion de beau ici, juste celle de différenciation).

Les Mac sont des machines fortement designées. Il m’a toujours été difficile d’expliquer pourquoi j’avais fait le choix du Mac à des personnes qui ne connaissent que le PC. Elles ne comprennent pas pourquoi elles devraient payer plus cher pour un ordinateur, “seulement parce qu’il est plus beau”. Certainement, si vous me lisez, vous utilisez un Mac, et vous savez pourquoi: vous avez acheté plus que du matériel, vous avez acheté une expérience. Vous aimez le Mac parce qu’il a été “pensé”.

En tant que programmeur sur Mac, je suis aussi un utilisateur, et je m’arrange pour reproduire ce qui me plaît et bannir ce qui m’agace au quotidien. L’essentiel du travail de design se faisant sur l’interface utilisateur, les Apple Human Interface Guidelines restent un livre de chevet. Mais ce sont tout autant les années d’utilisation du Mac qui m’ont formé à sa culture: minimalisme, prévisibilité, cohérence.

J’ai eu l’occasion de parler avec un programmeur qui a un poste important chez un grand éditeur de logiciels d’apprentissage des langues. Nous parlions d’Eclipse, et je lui exprimais mon dégoût pour son interface. Il me répondit: ” l’interface utilisateur, c’est avant tout une question de goût”. Je ne peux pas être plus profondément en désaccord ! Il y a certes des habitudes, personnelles ou liées à l’utilisation d’une plateforme particulière, certes tout le monde ne pense pas pareil, ni n’a les mêmes aptitudes mentales, mais je suis convaincu que les trois piliers que j’ai cité plus haut (je les cite à nouveau: minimalisme, prévisibilité, cohérence) sont des principes qui peuvent s’appliquer à tous les cerveaux.

Votre rôle de designer: prendre des décisions

Voici un exemple. Un développeur a proposé que nous faisions des remarques sur son nouveau logiciel. Beaucoup de mes remarques portaient sur les Préférences, mais particulièrement sur une case à cocher. Cette case servait à activer la génération de l’aperçu QuickLook. Si, si, vous savez, QuickLook, le truc introduit par Apple avec Mac OS 10.5 et qui permet d’afficher l’aperçu des documents.

C’est utile alors. Pourquoi tu ne le laisses pas activé tout le temps ?” lui demandais-je.

Parce que la génération de l’aperçu prend du temps. Mais si la génération n’est pas faite, le Finder met plus de temps à afficher l’aperçu”, me répondit-il. Et un peu agacé par mes propos, il a laissé sa case à cocher.

Voyez-vous le travers ici ? Ce développeur n’a pas voulu faire de choix. Il laisse l’utilisateur le faire à sa place. Mettons-nous dans la peau de l’utilisateur: je me retrouve avec une case “Générer l’aperçu QuickLook”, je la coche ou pas ? À mon avis, 9 personnes sur 10 préférerons ne pas y toucher. Dans celles qui restent, certaines iront voir la doc et ne seront pas plus avancées. Elles laisseront la valeur par défaut. Il reste peut être alors une infime portion d’utilisateurs qui vont tester ce qui leur convient le mieux. Le pire, c’est que le développeur devra quand même décider si la case doit être cochée par défaut ! Les conséquences sont les suivantes:

  1. vous avez troublé vos utilisateurs
  2. vous avez peut-être codé une fonction inutile
  3. vous avez dû documenter le rôle de cette case
  4. vous avez compliqué votre source (ce qui gâte son évolution et peut éventuellement produire des bogues)

Quelle était la bonne décision alors, puisque je sais tout ? Je dirais: Imposer la meilleure option à l’utilisateur. Si la génération de l’aperçu prend moins d’une seconde, alors c’est négligeable pour l’utilisateur. Mais mon vrai choix, en vrai, aurait été de ne tout simplement pas coder cette fonctionnalité. Je n’utilise jamais l’affichage Coverflow, et très rarement QuickLook. Et j’imagine qu’il en est de même pour tout le monde, sauf Steve Jobs, pour épater la galerie lors de ses conférences. D’ailleurs, je parie que Coverflow aura disparu dans Mac OS 10.8. Et même si j’ai tort, il y avait plein d’autres choses plus importantes à coder avant.

Pour finir, ne jetons pas la pierre à ce développeur — qui a pensé avant tout à ses utilisateurs — mais balayons déjà devant notre porte: Toi, lecteur, quels choix t’es-tu refusé à faire ?

31 October 2008 Cocoa

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

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.