Co-fondateur de Spotlight Mobile, Nick Farina a décidé de porter son application de micro-géolocalisation, Meridian [1.1.1 – US – Gratuit – Spotlight Mobile, Inc.], d'iOS vers Android. Ce faisant, il explique ce qu'il a apprécié dans le développement sur Android, et ce qu'il a moins apprécié, du point de vue d'un développeur iOS.
Farina a pris une décision dès le début du projet : puisqu'il code de manière native sur iOS, il n'a aucune raison de faire autrement sur Android. Il a donc décidé de ne pas utiliser d'outils de développement multiplateforme, de coller au plus près des canons d'interface Android, et de coder en Java. Une décision importante qui conditionne de nombreux choix.
La première question a été celle du choix d'un IDE (environnement de développement intégré) : celui d'iOS est Xcode sur Mac, point — éditeur de code, SDK, outils de test, simulateurs, tout est inclus. Google fournit le SDK Android, le développeur ayant le choix de l'éditeur. Farina a pris le parti d'utiliser la solution recommandée, Eclipse, avec le plug-in ADT (Android Development Tools pour Eclipse).
« Vous allez tout simplement détester Eclipse. », assure Farina : « Vous allez brûler de haine envers lui comme un millier de soleils en furie [NdT : une phrase de développeurs en forme de référence à Cheers]. Il est lourd, et plus lourd encore que lourd […] ». Ce premier contact négatif doit cependant être surpassé pour découvrir la puissance de cet IDE monolithique : « un bon moyen de s'y retrouver dans Eclipse est de passer quelques heures, et je suis extrêmement sérieux à ce sujet, à bidouiller avec les centaines d'options, de cases à cocher et de petits bidules dans la section préférences. » Cette manière de se forcer à découvrir Eclipse, à comprendre sa logique, est le prix à payer pour développer plus facilement pour Android : « [Eclipse] va tout simplement coder à votre place ».
Farina critique aussi bien iOS qu'Android en matière de création d'interfaces. Côté iOS, Interface Builder n'est pas une solution miracle, et le développement entièrement personnalisé est parfois particulièrement complexe pour des choses finalement très simples. Même chose côté Android : on ne peut utiliser seulement Java ou seulement le système de layouts XML. Il y a cependant en matière d'animations une différence fondamentale entre les deux OS : Android a été conçu comme un concurrent de Windows Mobile et BlackBerry OS, et reprend leur logique de rendu logiciel, ce qui permet de se passer d'une puce graphique très puissante. iOS au contraire a été conçu avec l'accélération OpenGL en tête, et le système similaire dans Android 3.0 est limité. Dans un OS comme dans l'autre, il faut donc à nouveau se poser la question de la pertinence des choix techniques : suis-je près à perdre un peu de fluidité dans cette vue contre une manière un peu plus simple de coder (iOS) ? est-ce que je dois utiliser le rendu CPU à cet endroit, avec le risque de l'occuper un peu trop parce que pendant ce temps il doit aussi parser mon flux (Android) ?
Bref, Farina essaye de faire passer un message simple : si l'on veut s'éviter bien des peines, sur iOS comme sur Android, il faut prendre du recul, peser ses choix techniques, comprendre la philosophie des plateformes. Choses qui ne peuvent être accomplies avec des frameworks multiplateforme. Mais tout cela demande des compétences, et du temps — donc de l'argent : le portage de Meridian a pris quatre mois. Tous les développeurs n'ont pas ce luxe.
Farina a pris une décision dès le début du projet : puisqu'il code de manière native sur iOS, il n'a aucune raison de faire autrement sur Android. Il a donc décidé de ne pas utiliser d'outils de développement multiplateforme, de coller au plus près des canons d'interface Android, et de coder en Java. Une décision importante qui conditionne de nombreux choix.
La première question a été celle du choix d'un IDE (environnement de développement intégré) : celui d'iOS est Xcode sur Mac, point — éditeur de code, SDK, outils de test, simulateurs, tout est inclus. Google fournit le SDK Android, le développeur ayant le choix de l'éditeur. Farina a pris le parti d'utiliser la solution recommandée, Eclipse, avec le plug-in ADT (Android Development Tools pour Eclipse).
« Vous allez tout simplement détester Eclipse. », assure Farina : « Vous allez brûler de haine envers lui comme un millier de soleils en furie [NdT : une phrase de développeurs en forme de référence à Cheers]. Il est lourd, et plus lourd encore que lourd […] ». Ce premier contact négatif doit cependant être surpassé pour découvrir la puissance de cet IDE monolithique : « un bon moyen de s'y retrouver dans Eclipse est de passer quelques heures, et je suis extrêmement sérieux à ce sujet, à bidouiller avec les centaines d'options, de cases à cocher et de petits bidules dans la section préférences. » Cette manière de se forcer à découvrir Eclipse, à comprendre sa logique, est le prix à payer pour développer plus facilement pour Android : « [Eclipse] va tout simplement coder à votre place ».
La version Objective-C.
Cette manière d'approcher les choses est en fait la clef, selon Farina, pour que le développement sous Android se passe dans les meilleures conditions possibles : plutôt que de partir avec des idées préconçues sur Eclipse ou Java, il faut comprendre comment Android utilise Eclipse et Java, pourquoi, et s'y tenir. Ce serait la manière la plus simple d'éviter de nombreuses sources de frustrations : « en général, les frameworks d'Android sont plutôt bien conçus et cohérents, et les API s'intègrent parfaitement au langage Java. En fait, […] notre application a presque la même structure de classes sur Android et sur iOS. Le code lui-même est incroyablement similaire sur les deux versions ».
La version Java.
L'émulateur Android, destiné à tester les applications, n'a pas les faveurs de Farina : comme tous les émulateurs, il est lent. Le simulateur iOS a l'inconvénient de passer par une compilation x86/64 (Intel x86 et non ARM, ce qui signifie que vous pourrez passer à côté de bogues qui seront présents dans l'application sur un appareil réel), mais a l'énorme avantage d'être rapide. Selon lui, la solution est simple : il suffit de tester l'application sur un smartphone, voire sur plusieurs smartphones aux configurations différentes. Le nombre de configurations possibles est évidemment beaucoup plus grand avec Android, mais il faut de toute manière tester son application iOS sur plusieurs profils (iPod touch, iPhone, génération actuelle, génération précédente), donc autant se plier à l'exercice sur toutes les plateformes.
Farina critique aussi bien iOS qu'Android en matière de création d'interfaces. Côté iOS, Interface Builder n'est pas une solution miracle, et le développement entièrement personnalisé est parfois particulièrement complexe pour des choses finalement très simples. Même chose côté Android : on ne peut utiliser seulement Java ou seulement le système de layouts XML. Il y a cependant en matière d'animations une différence fondamentale entre les deux OS : Android a été conçu comme un concurrent de Windows Mobile et BlackBerry OS, et reprend leur logique de rendu logiciel, ce qui permet de se passer d'une puce graphique très puissante. iOS au contraire a été conçu avec l'accélération OpenGL en tête, et le système similaire dans Android 3.0 est limité. Dans un OS comme dans l'autre, il faut donc à nouveau se poser la question de la pertinence des choix techniques : suis-je près à perdre un peu de fluidité dans cette vue contre une manière un peu plus simple de coder (iOS) ? est-ce que je dois utiliser le rendu CPU à cet endroit, avec le risque de l'occuper un peu trop parce que pendant ce temps il doit aussi parser mon flux (Android) ?
Bref, Farina essaye de faire passer un message simple : si l'on veut s'éviter bien des peines, sur iOS comme sur Android, il faut prendre du recul, peser ses choix techniques, comprendre la philosophie des plateformes. Choses qui ne peuvent être accomplies avec des frameworks multiplateforme. Mais tout cela demande des compétences, et du temps — donc de l'argent : le portage de Meridian a pris quatre mois. Tous les développeurs n'ont pas ce luxe.
