All posts by Jonathan Perret

About Jonathan Perret

Développeur indépendant, spécialisé en méthodes Agiles.

Il fait trop chaud pour… se répéter

Pour ceux qui continuent de coder pour iOS dans la torpeur estivale qui a saisi le pays, une petite astuce, permise par le SDK 4, qui pourrait vous économiser quelques gouttes de sueur.

On adore tous le mot-clé @synthesize qui nous évite déjà d’avoir à tartiner des accesseurs sans intérêt. Malheureusement, pour créer une propriété simple, jusqu’à présent il fallait encore définir séparément le stockage (variable d’instance ou ivar pour les intimes et les Scandinaves) et la propriété elle-même, avec le mot-clé @property :

@interface MaClasse: NSObject {
    NSString *truc;
}
@property(retain) NSString *truc;
@end

@implementation MaClasse
@synthesize truc;
@end

Or, dans la documentation des Declared Properties, on trouve la phrase suivante :

For the modern runtimes (see Runtime Versions and Platforms in Objective-C Runtime Programming Guide), instance variables are synthesized as needed.

Et si on suit la référence indiquée on arrive à :

iPhone applications and 64-bit programs on Mac OS X v10.5 and later use the modern version of the runtime.

Tout est donc OK, on devrait pouvoir profiter de cette fonctionnalité dans les projets iPhone !

Toujours à l’affut de l’économie de lignes de code, quand j’avais lu cette documentation je m’étais précipité sur le projet iPhone le plus proche, avais enlevé une définition d’ivar théoriquement inutile et tenté de compiler le code ainsi allégé :

@interface MaClasse: NSObject {
}
@property(retain) NSString *truc;
@end

@implementation MaClasse
@synthesize truc;
@end

Hélas, quelle déception ! Le compilateur ne semblait pas avoir lu le texte sus-cité et s’entêtait à exiger la définition redondante.
Comme d’habitude Google détenait la clé du mystère : si le code incriminé était rejeté, c’est parce que je compilais pour le simulateur ! Quel rapport me direz-vous ? Eh bien comme vous le savez sans doute, le simulateur iPhone est une application OS X 32 bits… qui ne bénéficie donc pas du fameux modern runtime. Effectivement, le code sans ivar se compilait sans problème dès que je choisissais “Device” comme cible.

Je n’étais bien entendu pas le premier à découvrir ce déplorable état de fait (difficile d’abandonner le simulateur pour économiser quelques lignes par classe !), et la conclusion généralement admise était qu’il perdurerait longtemps, Apple ayant choisi de ne pas rendre le modern runtime accessible aux applications OS X 32 bits, et compiler le simulateur en 64 bits étant exclu pour des raisons évidentes.

C’était sans compter… je ne sais quoi au juste, l’ingéniosité d’un développeur Apple ? Un caprice de Steve ? Toujours est-il que, sans tambour ni trompette (ce n’est même pas mentionné dans les release notes, et le bug radar n’est pas fermé !), le simulateur fourni avec le SDK 4, tout en restant une application 32 bits, utilise le modern runtime – et le compilateur associé est naturellement au courant.

Tout ça (oui, ça fait beaucoup de texte pour parler d’économies de lignes de code !) pour dire que dès aujourd’hui, si vous développez pour iOS (quelle que soit la deployment target, du moment que vous compilez avec le SDK 4), vous pouvez tirer parti de l’instance variable synthesis et omettre ces définitions décidément pas DRY.

Pour finir, à ceux qui n’auront de cesse que la dernière source de duplication stérile de code soit éliminée, et continuent de déplorer qu’il faille encore enfoncer le clou de chaque @property par un @synthesize, sachez qu’il existe un espoir : le compilateur LLVM serait capable d’inférer ces déclarations @synthesize, en l’absence bien sûr d’accesseurs explicites (plus de détails ici). Il semble qu’une petite limitation ternisse encore ce tableau presque idyllique, mais le nirvanā de la propriété en une ligne est plus que jamais à portée de main !

Un ArtGame enfin disponible sur iPad !

Eh oui, c’est bien vrai : depuis quelques dizaines d’heures, si vous tapez «artgame» dans la zone de recherche de votre AppStore favori, vous aurez une réponse dans la catégorie iPad : Number32, dont je relatais la genèse ici la semaine dernière.

Afin que ce billet ne soit pas une simple page de publicité, je partage avec vous quelques infos sur cette première expérience de soumission (j’aime pas trop ce mot, c’est peut-être parce qu’il est trop approprié…) sur l’AppStore. Rien qui dépaysera les routards de l’AppStore, mais ça pourrait en intéresser d’autres :

  • Une semaine en «Waiting for review», moins de 2 jours en «In review» : ça confirme les délais que j’avais pu lire ici ou là ;
  • D’après Google Analytics, 2 (brèves) visites venant de Californie sur la page du jeu (il y a un lien dans l’«About Box») le jour de la revue ;
  • 219 téléchargements dans les premières 24 heures, alors que je n’avais encore fait aucune communication sur la disponibilité de l’app ! Pas de quoi tomber à la renverse certes, mais ça donne une petite idée du nombre de gens qui téléchargent vraiment tout ce qui passe… Allez, je ne résiste pas au plaisir de vous livrer le détail par pays :
    139 États-Unis
    20 France
    16 Canada
    11 Royaume-Uni
    11 Allemagne
    10 Espagne
    5 Italie
    2 Suède
    1 Arabie Saoudite
    1 Pays-Bas
    1 Suisse
    1 Bulgarie
    1 Argentine

    Qui confirme que le marché US est de loin le plus gros.

  • Les premières «étoiles» sont également tombées assez vite, sur le store US :

    Oups ! Forcément, les gens qui téléchargent tout ne peuvent pas tout apprécier… 🙂
    Pas encore de «review» détaillée en revanche.

  • Pour le suivi des «ventes», j’ai testé la toute nouvelle application d’Apple «iTunes Connect Mobile» : pas très convaincant et pas mal de messages d’erreur, bof. En revanche le site http://appfigures.com m’a fait une bonne impression : il collecte tout seul les rapports d’Apple (dommage qu’il faille lui confier ses identifiants Apple pour ça ; sinon on peut aussi lui fournir les fichiers en mode manuel), récolte les «ratings» et les «reviews» dans tous les stores et fait plein de jolis graphiques. Autre fonctionnalité plaisante : on peut inscrire d’autres personnes (clients, partenaires…) qui recevront (pour les applications sélectionnées) les rapports. Le tout pour un prix qui semble modique (5$/mois pour les deux premières apps).
  • Pendant que j’écrivais ceci, les chiffres du deuxième jour sont tombés :
    52 États-Unis
    27 Japon
    17 France
    9 Canada
    9 Australie
    8 Espagne
    7 Allemagne
    7 Royaume-Uni
    3 Suisse
    3 Taiwan
    2 Italie
    2 Chine
    2 Émirats Arabes Unis
    2 Russie
    2 Thaïlande
    1 Inde
    1 Norvège
    1 Hong-Kong
    1 Singapour
    1 Philippines
    1 Grèce

    Les Américains se sont calmés (les mauvaises étoiles n’ont pas dû aider…) mais les Japonais se sont réveillés. Mais seulement deux Chinois, ça fait peu non ?

Je vous laisse sur une vidéo du jeu, et un bon gros bouton à cliquer si vous ne savez pas encore à quoi sert votre iPad — j’ai pas encore dit que c’était gratuit ?

Retour sur le ArtGame weekend (présentation du 10/6/2010)

Suite à la présentation que j’ai faite jeudi dernier, Guillaume m’a gentiment prêté les clés pour que je poste ici un compte-rendu à destination de ceux qui n’avaient pas pu être présents.

Il s’agissait de raconter comment lors du ArtGame weekend (http://artgameweekend.com) j’ai programmé un jeu pour iPad en 48 heures.

ArtGame weekend

Quelques mots sur l’ArtGame weekend (pour les flemmards qui n’ont pas été voir le site) : il s’agissait de réunir à La Cantine à Paris (http://lacantine.org) des artistes, des développeurs et des game designers pour produire sur deux jours (du vendredi soir au dimanche après-midi) des «ArtGames» sur plate-forme mobile.

ArtGame ? En gros c’est un jeu vidéo qui vise aussi à être une œuvre d’art.

Il y avait une soixantaine de participants. Le vendredi soir chacun pouvait proposer («pitcher») une idée de jeu : 33 idées ont été soumises, puis nous avons voté afin de n’en garder que 9. Ensuite les équipes se sont librement constituées autour des porteurs des idées retenues.

Voilà comment j’ai fait la connaissance de Laurent Brun (http://madeinhl.com) et Josselin Perrus (http://nilsoj.tumblr.com) : nous avons constitué la plus petite équipe de la compétition, pour travailler sur l’idée de Laurent, qui portait pour nom de code «Number32» et se résumait à «générer des formes complexes à partir de formes simples».

Étant le seul développeur (en tout cas le seul qui ait eu envie de programmer à cette occasion…) de l’équipe, je n’ai pas eu de difficultés à faire accepter mon choix de plate-forme : ce serait l’iPad dont j’avais fait l’acquisition la veille de la compétition. Les autres équipes quant à elles ont choisi de développer pour Android.

L’ensemble des productions du week-end est consultable sur le site (http://artgameweekend.com/realisations/).

Passons maintenant au vif du sujet : mon expérience de développement iPad sur ces deux jours. Il faut dire qu’avant ce week-end, je n’avais pratiquement pas écrit d’Objective-C, mes seules expériences avec le langage se limitant à ce que j’avais pu voir au Dojo iPhone organisé chez Pyxis depuis quelques mois (http://groups.google.fr/group/dojo-at-lunch). J’abordais donc le week-end avec une certaine trépidation, espérant ne pas handicaper mon équipe par mon impréparation (notons cela dit que je n’étais pas le seul développeur sur place à ne pas avoir d’expérience significative sur mobile).

Ce qui a bien marché

  • L’organisation : rien à dire, un super boulot de la part des organisateurs. Il y avait toujours à manger 🙂
  • Git (http://git-scm.com) : bien que seul à programmer, j’ai régulièrement stocké tous les fichiers du projet dans un repository git. Sa vitesse lui a permis de se faire oublier très facilement.
  • Test-Driven Development : c’est la technique que j’utilise quand je développe «professionnellement», je n’allais pas en changer sous prétexte que c’était le week-end ! Je ne liste pas tous les bénéfices ici, mais disons que la couverture importante de code obtenue m’a donné la confiance nécessaire pour faire les multiples refactorings successifs pour maintenir le code propre au cours de son évolution.
  • Google Toolbox for Mac (http://code.google.com/p/google-toolbox-for-mac/) : voilà une boîte à outils que j’ai découverte au Dojo; j’ai utilisé ses extensions de test unitaire pour iPhone, qui m’ont permis notamment d’écrire des tests comparant une image générée par mon code avec un résultat attendu, stocké sous la forme de .png.
  • Objective-C 2.0 : je n’ai pas connu la version 1, mais je serais contrarié de devoir me passer des propriétés ou de l’énumération.
  • CoreGraphics : une API pas compliquée à comprendre, sans surprises, performante.
  • La compilation universelle iPhone/iPad : à un moment dans le week-end, j’ai été pris d’une inquiétude subite : le jury allait-il considérer l’iPad comme une plate-forme «mobile» ? Plutôt que de chercher à obtenir une réponse, j’ai simplement changé la «Targeted device family» de mon projet Xcode et 5 minutes plus tard (OK, j’ai peut-être aussi dû sacrifier un poulet aux dieux du «provisioning»), le jeu tournait sur mon iPhone. Agréable. (Note: au final, je n’envoie sur l’AppStore qu’une version iPad, car je n’ai pas à ma disposition l’arsenal d’iPod touch et «vieux iPhones» nécessaire pour valider le fonctionnement de l’application sur toutes ces plate-formes)
  • Une démonstration permanente, fournissant un feed-back immédiat : voici comment j’avais installé mon poste de travail :
    Merci à @hexapode pour la photo

    La BookChair serait-elle un accessoire indispensable au développeur iPad ?
    Assez tôt (samedi dans la journée) le jeu a pu tourner sur l’iPad; à partir de là il était toujours disponible pour que les autres membres de l’équipe (ou des passants quelconques) puissent suivre en temps réel  l’état du code et suggérer des améliorations.

  • The Pomodoro Technique (http://www.pomodorotechnique.com/) : se concentrer 25 minutes, puis faire 5 minutes de pause obligatoire. Permet entre autres : d’éviter de s’enfoncer dans un trou à essayer pendant 2 heures de faire fonctionner un truc inutile, de ne pas oublier de se nourrir, enfin bref de rester efficace !
  • Un rythme soutenable : une autre pratique (avec TDD) prônée par Extreme Programming, qui consiste simplement à penser qu’on n’est efficace que lorsqu’on n’abuse pas des heures de travail. En l’occurrence, nous sommes partis nous coucher vers minuit le vendredi et le samedi soir, pour reprendre vers dix heures le samedi et le dimanche. Certes pas des horaires de bureau recommandables, mais il s’agissait de tenir le week-end, pas les six mois d’un projet ! En tout cas, il suffisait dimanche de regarder certains des autres participants pour savoir qu’ils avaient pratiqué des horaires nettement plus intenses…
  • Une équipe solidaire : Laurent et Josselin ne sont pas restés inactifs pendant que je codais : il y avait des règles de calcul à inventer, des «coachs» bien intentionnés à occuper, une présentation «avec des vrai morceaux de propos artistique dedans» à mitonner… du café à faire 🙂

Ce qui a moins bien marché

  • Xcode qui insiste pour que je confirme mon annulation : heureusement que Guillaume nous a donné la solution dans son dernier billet.
  • OCUnit : un framework de tests unitaires qui a l’immense mérite d’exister (et d’être fourni en standard avec Xcode), mais qui montre montre son âge par certains côtés : en  particulier, l’impossibilité d’omettre l’argument message dans les macros STAssertXXX génère un bruit agaçant dans le code des tests.
  • Le déploiement : j’aurais souhaité sortir du week-end avec un produit réellement déployable, voire déjà envoyé à Apple. Et bien que le jeu fût complètement fonctionnel et stable dimanche soir, il nous a fallu encore pas mal de travail derrière pour régler tous les détails, de la fenêtre de «crédits» à la description pour l’AppStore.
  • L’historisation du code : j’ai fait une utilisation un peu anarchique de git, faisant régulièrement de «gros» commits en ligne de commande (git commit -a -m "blabla") sans cohérence particulière et avec des messages approximatifs. Il aurait suffi de quelques secondes dans GitX pour éviter ça.
  • La gestion de la mémoire : à un moment, pris de culpabilité pour avoir superbement ignoré la méthode release jusque-là, j’ai codé un appel à un endroit qui me semblait en avoir besoin. Résultat : le premier plantage que j’aie eu depuis le début du projet. Finalement le jeu tourne très bien sans (et pendant des heures : j’ai vérifié !)
  • Le gameplay : nous ne nous en sommes préoccupés que tardivement, ce qui fait que nous avons livré au jury une œuvre d’art… à laquelle manquait une dimension ludique pour en faire un «ArtGame». Il semble que le jury ait bien apprécié l’application en dehors de ce défaut – nous a-t-il coûté la victoire ? Qui sait…

Voilà pour le ArtGame weekend. Si vous avez un iPad et envie d’essayer notre jeu, il devrait vous suffire de patienter encore quelques jours pour qu’il atterrisse dans l’AppStore (gratuit). En attendant voici une vidéo «promotionnelle».

Et si ce genre de week-end vous tente, sachez que BeMyApp, qui était également présent jeudi soir, organise une manifestation similaire ce week-end : plus d’infos sur http://bemyapp.com/weekends/.

Merci à ceux qui étaient présents jeudi soir, à ceux qui ont lu jusqu’ici, et à bientôt lors d’une future soirée CocoaHeads !