L’année dernière, le Trophée de la meilleure utilisation des technologies Apple était revenu à Remote Buddy d’IOSpirit un utilitaire qui décuple les possibilités de la télécommande Apple Remote. Son auteur, Félix Schwarz revient sur la création de ce logiciel, sur son activité et sur les possibilités de l’iPhone pour développeurs.

Interview réalisée par Christophe Laporte et François Schuster.

L’an dernier, vous remportiez un trophée MacGeneration pour Remote Buddy alors que le logiciel n’était pas encore finalisé. Pourquoi un si long délai avant la version finale ?

Toutes ces distributions de Remote Buddy étaient très stables et comportaient, pour la plupart, des améliorations substantielles qui auraient pu justifier une mise à jour en bonne et due forme. Cependant, pour deux raisons, j’ai décidé de ne pas apposer l’étiquette “1.0″ trop prématurément.

La première tient au statut de pré-version. Au besoin, ce dernier permet de bouleverser l’interface et les fonctionnalités du produit, de façon à coller au plus près avec les attentes des utilisateurs.

La seconde raison est qu’une fois que vous avez évolué avec des pré-versions tout en distribuant des mises à jour substantielles, la barre est forcément plus haute pour la version finale. Je voulais être sûr que tout fonctionne à 101% pour cette “vraie” première version.

Le trophée vous a-t-il aidé à améliorer la popularité de votre application ? Etes-vous satisfait des ventes de Remote Buddy ?

Le trophée a contribué à drainer l’attention du public sur le projet. Beaucoup de personnes entendaient parler de Remote Buddy pour la première fois quand j’ai reçu le trophée l’an dernier. De plus, le trophée MacGeneration est un label de qualité que je suis fier de mettre en avant sur le site Web de Remote Buddy. Quant à l’objet de verre gravé, placé dans mon bureau, il ne manque pas d’attirer les regards.

S’agissant des ventes de Remote Buddy, l’application est aujourd’hui celle qui se vend le mieux parmi toutes celles que j’ai eues l’occasion de développer. J’entrevois encore un potentiel commercial qui, en passant, permettrait de financer le développement de nouvelles fonctionnalités.

Comment est venue l’idée de Remote Buddy ? N’a-t-il pas été trop difficile d’obtenir la documentation relative à Apple Remote ?

L’origine de l’application remonte à février 2006 : je voulais utiliser un iMac Intel pour visionner un DVD avec des amis. Impossible d’activer le mode plein écran ou de basculer vers Front Row pour commander la lecture en utilisant la télécommande. Un vrai four ! J’ai dû brancher le clavier et la souris pour parvenir à mes fins. À partir de là, j’ai commencé à cogiter sur l’utilisation extensive de l’Apple Remote et à réfléchir à ce que devait être une interface universelle. Créer une souris virtuelle opérable à distance était également tentant ! Mais j’ai préféré continuer à me concentrer sur la prochaine version de Picture Arena.

L’idée en est restée là jusqu’à ce que, à la fin de l’année dernière, je tombe sur le Wiki CocoaDev et que je découvre que Martin Kahr avait - en s’appuyant sur des recherches menées par d’autres membres du Wiki - créé une méthode d’accès à l’Apple Remote. Même si j’avais à ajouter quelques fonctionnalités avant de l’utiliser dans le sens désiré, ce travail constituait une bonne base de départ. Au départ, j’entendais simplement ajouter des fonctions de contrôle à distance à Picture Arena mais je suis finalement repartis sur mon idée originelle. Je me suis donné 14 jours pour mettre le truc sur pied (codage, site Web, vidéo). Ce devait être une expérimentation ludique mais l’accueil du public m’a tout simplement soufflé.

J’ai donc fait de Remote Buddy mon projet principal. Les recherches poussées sur l’Apple Remote n’ont commencé qu’après que le code de Martin devienne sujet à un bogue (introduit par une mise à jour de Sécurité Apple et non encore résolu à ce jour, ce bogue se manifeste par des déclenchements intempestifs de Front Row).

Je me suis donc penché sur le système HID (ndt : Human Interface Device, qui traduit les manipulations de l’utilisateur sur le matériel en actions au sein de Mac OS X), les extensions Kernel et Kernel Space pour trouver une solution. Par la suite, j’ai écrit un nouveau pilote d’Apple Remote pour Remote Buddy en partant de zéro. Il s’avère que l’Apple Remote est très bien documenté par Apple. C’est un périphérique HID standard qui agit exactement comme vous l’attendez. Il reste qu’il est absolument essentiel de maîtriser les concepts-clef HID. : étant donné que les développeurs Cocoa ne s’intéressent habituellement pas au système HID et que celui-ci est d’une nature assez complexe, c’est là probablement l’obstacle le plus conséquent. En revanche, une fois ces données assimilées, il n’y a plus qu’à suivre les procédures normales et l’Apple Remote devient utilisable (et continuera à l’être sous Leopard).

Au final, ces recherches ont permis d’incorporer quelques fonctionnalités exclusives : une vraie émulation de l’Apple Remote pour les configurations dépourvues de récepteur intégré, un correctif fiable du bogue Apple, la possibilité de gérer plusieurs télécommandes Apple, ainsi que la prise en compte de la durée de pression pour tous les boutons (”Menu” et “Play” inclus). À cet effet, Remote Buddy a besoin d’une extension kernel mais la solution, conforme à la documentation d’Apple, est propre.

Parlons un peu de Leopard. Quels sont vos plans, votre opinion sur le nouveau félin ?

Leopard est une mise à jour exceptionnelle pour les développeurs. Il y a énormément de nouvelles interfaces de programmation (API). Des pans entiers de Remote Buddy seront entièrement réécrits pour profiter pleinement de ces nouvelles fonctionnalités. J’aimerais entrer dans les détails mais je ne veux pas prendre le risque de violer le NDA imposé par Apple.

IOSPRIT sera présent avec son propre stand à la Mac Live Expo de Cologne en novembre. Il y a de bonnes chances que vous puissiez y voir Remote Buddy en action, prenant la pleine mesure des nouvelles fonctions de Leopard.

Vous êtes déjà en train de développer des logiciels pour l’iPhone ! Etes-vous déçu de programmer en Ajax et non en Cocoa ?

Bien sûr que je suis déçu ! J’ai beaucoup de projets qui mériteraient d’être concrétisés mais qui ne sont pas faisables dans une simple interface Web. Mêmes les possibilités au sein du navigateur de l’iPhone sont limitées : pas de support du multitouch, du glisser-déposer, etc.

J’espère qu’Apple finira par réaliser qu’ils se font du mal en barrant la route aux innovations des éditeurs tiers. Si Apple avait verrouillé iTunes de la sorte, CoverFlow, qui provient d’un développement externe, n’aurait jamais vu le jour. Or, Apple a fait l’acquisition de cette technologie qui est désormais une pièce maîtresse de ses produits… Une forteresse ne peut accoucher d’un écosystème florissant et de synergies fortes. Avec l’iPhone, Apple possède un jeu d’API et de technologies supérieures. Même si vous mettez de côté le facteur “hype”, il y aura suffisamment de développeurs pour écrire des applications dédiées à l’iPhone. Pour l’heure, Apple contrarie les effets positifs et les opportunités commerciales qu’un iPhone ouvert offrirait. Quel gâchis ! J’espère qu’ils reconsidéreront leur position…

Mais il y des aspects positifs malgré tout. J’ai trouvé là une bonne raison de m’atteler à JavaScript et AJAX. De même, Remote Buddy AJAX Remote en gagne la compatibilité avec d’autres périphériques dotés d’un support du Web : certaines consoles de jeu, certains PDA…

D’un autre côté, Remote Buddy AJAX Remote ne sera pas une solution exclusive au matériel Apple. Il aurait pu l’être…

Que suggéreriez-vous à quelqu’un qui débute dans le développement sur Mac ?

Ayez confiance en vous ! Et attelez-vous vous à Cocoa. Quand j’ai commencé à développer sur Mac, j’avais lu quelque part que Carbon était la meilleure plate-forme. J’ai fui Cocoa pendant des années, ce que je considère maintenant comme une erreur grossière. Le développement de Picture Arena aurait progressé bien plus vite si j’avais utilisé Cocoa. Vous pouvez faire facilement avec Cocoa un tas de choses qui sont compliquées, voire impossibles avec Carbon. Ceci dit, mon expérience de Carbon aura été également profitable en ce qu’elle m’a procuré une solide compréhension des fondamentaux du système. Et j’enrichis souvent mon code par des recours ponctuels à Carbon.

Je ne souhaite pas prendre part à la guerre Cocoa/Carbon qui mobilise certains développeurs. Chaque jeu d’API a ses avantages et ses inconvénients. Mais comme Cocoa est plus facile à appréhender et qu’il bénéficie de toute l’attention d’Apple, c’est certainement une bonne chose que de débuter avec lui.