Amorcé en 2008, lancé à pleine vitesse cette année, le système d'exploitation mobile de Google arrive enfin chez les grands comptes ! La SNCF en est l'exemple : elle a livré aux possesseurs de smartphones Android son application de réservation / consultation des horaires de trains pour Noël. Une nouvelle illustration que l'avenir ne se joue aujourd'hui plus uniquement sur l'iPhone : le développement Android est bien en marche et constitue un challenge économique comme technique.
Un an après la sortie de son application iPhone, la SNCF nous propose un portage vers Android qui prend en compte les spécificités de l'OS. On retrouve donc les mêmes fonctionnalités que sur iPhone, avec quelques migrations spécifiques à Android : certains composants sont différents (choix de date/heures), le bouton retour spécifique à l'iPhone laisse sa place au bouton physique présent sur tous les Android, des menus contextuels viennent remplacer les barres d'action en bas des écrans...
J'ai pu réaliser un Perfection Game* sur cette application Horaires et Réservations SNCF et ai tenté de généraliser l'expérience pour tout projet mobile Android. La pratique est d'attribuer une note sur 10 représentant ce qui peut être amélioré (10/10 ne signifie pas que l'application est parfaite, mais plutôt que je n'ai aucune piste pour l'améliorer) :
Je donne à l'application une note de 7/10.
- Elle propose des écrans simples et propose un design personnalisé original : on retrouve l'identité de la SNCF dans l'application.
- Elle est adaptée aux spécificités ergonomiques d'Android : l'utilisation de menus contextuels permet de gagner de l'espace sur les écrans tout en proposant à l'utilisateur une expérience dont il a l'habitude.
- Elle est uniformisée sur ses différents supports : Android n'est pas le seul canal, que ça soit sur le site web, sur sa version web mobile, la version iPhone ou dans cette version Android, l'utilisateur n'est pas perdu et retrouve un environnement auquel il est habitué.
- Aller plus loin dans les spécificités du code Android : un device mobile est moins performant qu'un ordinateur de bureau, certaines pratiques en Java classique ne sont pas adaptées au développement Android (pour plus de détails, voir l'article très instructif http://developer.android.com/guide/practices/design/performance.html ). L'analyse des logs de l'application montre une importante présence de logs d'information et quelques logs de debug. Ces logs ne devraient pas être présents sur la version de production de l'application : ils donnent des informations inutiles pour le système et peuvent jouer sur les performances d'exécution. Il est donc conseillé de les désactiver.
- Tester l'application sur un plus grand nombre de téléphones et améliorer la gestion des exceptions : jusqu'à sa mise à jour en version 1.1, l'application s'arrête brutalement après avoir démarré sur le Desire Z. Au vu des commentaires postés sur l'Android Market, ce problème touche plusieurs téléphones HTC, ce qui peut laisser présager une spécificité bloquante de la surcouche HTC Sense. Cependant, l'analyse des logs semble identifier un problème lors de la création initale de base de données de l'application. L'origine du problème est donc obscure. Un tel cas peut difficilement se prévoir, et seuls de nombreux tests sur différentes versions de l'OS et différents téléphones pourront le faire ressortir.
- Favoriser l'accessibilité à l'application : si l'application "Horaires/Résa" se trouve facilement sur l'Android Market en cherchant "SNCF" (mot clé dans la description de l'application), elle reste difficilement accessible une fois installée sur un téléphone en utilisant la recherche Android : il faut se souvenir du nom "Horaires/résa" alors qu'on aurait plus facilement tendance à rechercher "SNCF". De manière générale, retrouver l'entité qui a créé l'application dans son nom peut être considéré comme une bonne pratique.
L'application semble aujourd'hui satisfaire ses utilisateurs avec une note proche de quatre étoiles sur cinq sur l'Android Market (note ci-dessous via le site Androlib).
Les soucis observés sur les derniers téléphones HTC ont rapidement été corrigés grâce aux retours de la communauté d'utilisateurs sur l'Android Market. C'est aussi avec cette communauté que les constructeurs peuvent faire évoluer et corriger leurs applications. "Horaires et résa" est donc un exemple des challenges qui sont et seront relevés prochainement pour s'adresser à la nouvelle population grandissante de smartphones Android. Voyons donc ce qu'un tel lancement sur la plateforme de Google entraine et nécessite.
Android est un challenge pour le positionnement mobile actuel (rappelons que 25,5 % des smartphones vendus dans le monde au dernier trimestre 2010 sont équipés d'Android). Une large population utilise et utilisera donc l'OS de Google, une raison indéniable pour se lancer dans le développement et s'informer des spécificités de cet OS qui équipe plus de 50 smartphones différents.
Depuis l'annonce de la version 2.3 de l'OS le 6 décembre dernier, Android est représenté par 5 versions majoritaires de l'OS. La répartition du 1er décembre 2010 montre une grosse domination des versions 2.1 et 2.2. On peut noter que la version 1.6 d'Android permet de toucher 95,3 % du parc et bénéficie de la gestion de multiples résolutions d'écran.
Chacune des versions d'Android est différente et apporte son lot de fonctionnalités/corrections de bugs tout en assurant une rétrocompatibilité. Une des différences notable avec l'OS de l'iPhone est que rien ne pousse l'utilisateur à mettre son système à jour. Pas de demande de mise à jour récurrente par iTunes. Parfois tout simplement pas de mise à jour disponible ! En effet selon le constructeur/opérateur téléphonique, une surcouche graphique peut être ajoutée à l'OS. On peut citer HTC Sense pour les smartphones du constructeur Taïwanais par exemple. Cette surcouche nécessite une évolution de ses composants à chaque mise à jour officielle d'Android. Selon les constructeurs et leur stratégie, cette mise à jour peut mettre un à six mois à être développée ou tout bonnement être ignorée si le modèle du téléphone est désuet par exemple. Une fragmentation des versions est donc inévitable.
Face aux versions à adresser, des choix sont donc inévitables : par exemple, les notifications push ne sont supportées qu'à partir de la version 2.2. Doit-on ne pas utiliser la fonctionnalité car près de 50 % des smartphones ne pourront en bénéficier ? Doit-on plutôt développer l'application uniquement pour la version 2.2 d'Android ? Développer une alternative selon la version de l'OS ? Ces questions doivent être posées et analysées en fonction de la cible de l'application.
A cette question des notifications push, pour une application grand public, on peut proposer une application qui fonctionne sur tous les téléphones (supérieur à 1.6) mais qui n'utilise le push que lorsque la version 2.2 est disponible. Pour cela on spécifie que l'application est compatible avec la version 1.6 (android:minSdkVersion="4") afin d'être compatible avec 95% du parc mais on utilise le SDK 2.2 pour développer (android:targetSdkVersion="8"). Ainsi dans le code, on peut vérifier la version de l'OS et proposer ou non la fonctionnalité. Un exemple technique sur la gestion des événements tactiles est proposé par Google et permet d'illustrer ce type de gestion des versions et même de proposer des alternatives pour chaque plateforme (si le cas d'usage est vraiment indispensable !).
En plus des différences d'OS, les smartphones Android ont des caractéristiques hardware très différentes. Présence ou non d'un clavier physique, résolution d'écran, présence ou non d'un accéléromètre sont autant de critères à prendre en compte pour développer l'application adaptée à son contexte.
Les spécificités hardware de chaque téléphone sont à considérer. Il est possible de définir les fonctions nécessaires que doit posséder un téléphone pour qu'une application fonctionne correctement. Ces fonctions sont inscrites dans le fichier Manifest de l'application (en quelque sorte, sa carte d'identité) avec la balise "use-feature" qui rend obligatoire ou non des spécificités, le microphone par exemple :
<uses-feature android:name="android.hardware.microphone" android:required="true"/>
Il est ainsi possible de prévoir différentes configurations hardware pour son application. L'article suivant apporte des précisions sur cette pratique : http://android-developers.blogspot.com/2010/10/five-steps-to-future-hardware-happiness.html .
En effet, entre un écran de faible résolution (240x430) et un écran HD (480x854), l'expérience utilisateur doit pouvoir rester la même !
Là encore, il faut savoir se poser la question essentielle "Qui va utiliser l'application ?" et faire les choix en conséquence. Il est évident que si aucun compromis n'est fait et que les développeurs travaillent sur une version de l'interface par version de l'OS, un projet initialement simple à réaliser se transforme en calvaire de complexité. Il est donc important de faire les choix adaptés à la solution !
En se basant sur la répartition des tailles et résolutions d'écrans ci-dessous (les pourcentages sont les derniers donnés par Google en Août 2010), on peut prendre comme cas nominal une taille d'écran "normale" et réaliser des interfaces adaptées aux moyennes et hautes densités (respectivement "mdpi" et "hdpi").
Dans la description de ces écrans, on utilisera au maximum des tailles relatives pour les composants : "wrap_content" qui permet au composant d'adapter sa taille à son contenu, ou "fill_parent" qui remplira le conteneur parent. Dans les cas où une mesure plus précise sera nécessaire, on veillera à ne pas utiliser le pixel comme unité de mesure et on préférera le "dp" (density pixel) qui s'adapte à la densité des écrans pour afficher les éléments à la bonne taille sur tous les modèles d'écran. On pourra rendre par ailleurs ces interfaces défilables si le contenu est trop dense pour des écrans de faible résolution (utiliser l'élément de disposition ScrollView). D'autres conseils pour développer pour différents écrans sont également disponibles à cette url : http://developer.android.com/guide/practices/screens_support.html.
Finalement, si le développement en XML des interfaces graphiques est nettement moins instinctif que sur iPhone qui bénéficie du logiciel Interface Builder, il n'en reste pas moins très abordable et adapté à la problématique de "multi-résolution". Quelques bons modèles et de la pratique permettent donc de triompher des pièges auxquels est confronté le développeur habitué au placement absolu des éléments sur l'écran.
Nous avons vu que le parc Android était étendu et que les applications devaient s'y adapter. De nombreux tests sont donc indispensables. S'il est possible de tester son application sur l'émulateur offert avec le SDK, il est obligatoire de le faire également sur des smartphones réels ! Face à la multitude de marques, de versions de l'OS et des surcouches graphiques différentes, quelques téléphones de test peuvent s'avérer indispensables. Le HTC G2 (ou AVD2) et le Nexus One vendus sur le site du développeur Android peuvent ainsi être rejoints par un téléphone à grand écran utilisant la surcouche HTC Sense comme le HTC Desire HD. Pour adresser d'autres marques (Motorola, Samsung, Sony Ericsson,...) et modèles physiques (clavier, résolutions...), des solutions de tests professionnels comme DeviceAnywhere peuvent être envisagées.
L'idéal est d'également former une vaste communauté de beta-testeurs et d'utiliser les retours de cette communauté avant toute release publique. Les applications Android possèdent pour cela l'avantage certain d'être facilement diffusées (en pièce jointe de mail par exemple) et installables sans autre prérequis que d'autoriser l'installation "d'applications non-market" sur les téléphones.
En conclusion, appréhender le "robot vert" n'est plus une option facultative pour une application grand public et le sera de moins en moins. Saluons donc tous les projets allant dans ce sens ! Pour être armé face à ces nouveautés, les 3 facteurs clés de succès à retenir sont : 1) connaître l'OS et ses spécificités (versions de la plateforme, ergonomie), 2) pratiquer et faire de la veille, et enfin 3) tester les applications du marché et ses applications sur une multitude de devices !
Bon développement !
-----
* Le perfection game (PG) est une pratique très courante chez OCTO qui nous permet de challenger toutes nos réalisations et présentations, ce afin d'améliorer le résultat final livré. Il consiste en deux temps : recenser tout d'abord les points positifs sur le travail, puis donner les axes d'amélioration envisageables pour lui faire atteindre l'excellence. Vous pourrez trouver des détails sur cette pratique dans notre dernier livre publié : "Partageons ce qui nous départage" ( https://blog.octo.com/octo-partage-ses-bonnes-pratiques-dans-le-livre-partageons-ce-qui-nous-departage/).