Publié le 25 mars 2010, modifié le 8 janvier 2024.
Par La Rédaction

Les étapes de développement d’une application Android (Volet 2)

Publié le 25 mars 2010, modifié le 8 janvier 2024.
Par La Rédaction

Nous avions évoqué dans un précédent volet l'écosystème de développement d'applications sur Android ; nous allons désormais entrer davantage dans le vif du sujet en décrivant les tâches de développement d'une application Android.

Bien entendu, les étapes que nous allons décrire présentent un idéal canonique qui, dans les faits, est rarement respecté. Il est important de garder en tête deux principes majeurs : s’efforcer de développer en mode agile, en particulier de favoriser les livraisons fréquentes de l’application, et partir avec un story-board de l’application. écris par Éoduard Mercier de Smart&Soft

Voici donc les sous titres : – La définition du besoin
– Les opportunités de réutilisabilité
– Le story-boar
– Les services web
– Le graphisme de l’application
– Le développement
– La recette
– La distribution


La définition du besoin

Comme tout projet, la première chose à faire est de récolter les besoins. Jusque là, rien de bien novateur. Cependant, avant de proposer une fonction de “tweet” ou d’écriture sur le mur Facebook de l’utilisateur, avant de proposer l’affichage de points d’intérêts géographiques dans un système de réalité augmentée, il est normal de se poser la question de la légitimité de telles fonctions, et quelle est la motivation de leur mise en place. Si le but est de faire connaître l’application aux utilisateurs, n’est-il pas plus légitime de prévoir un budget de campagne de publicité ciblée sur mobile, de proposer une fonction de recommandation de l’application par le truchement d’une simple fonction d’envoi d’e-mail ? La réalité augmentée n’a que peu d’intérêt si les points géographiques sont très éloignés de l’utilisateur. Il faut rester vigilant et ne pas emprunter les autoroutes de la pensée unique. Il faut tâcher de réfléchir à des fonctions différenciatrices plutôt que de suivre systématiquement les tendances, tout en focalisant sa réflexion sur les besoins de l’utilisateur final et en tentant de maximiser la fonction d’utilité de l’application. La mise en place d’une application mobile peut nécessiter au préalable l’introduction de nouvelles fonctionnalités si elle vient compléter l’existence d’une application web ou d’un site Internet. La conclusion de cette phase de réflexion peut aller jusqu’à remettre en question la pertinence du développement d’une application mobile.

De surcroît, lorsque la portée fonctionnelle d’une application est ambitieuse, il est important de se poser la question en terme de feuille de route : vais-je développer l’intégralité d’une application pour la première version ? Ne serait-il pas raisonnable de donner des priorités aux fonctionnalités, et de lotir différentes versions de l’application ? En effet, bon nombre d’applications arrivent sur l’Android Market avec une première version très ambitieuse, mais dont la réalisation n’est finalement pas satisfaisante : on a essayé d’intégrer l’intégralité du fonctionnel dans des délais courts, et la qualité s’en trouve largement amoindrie. L’application peut être instable, présente une ergonomie mal étudiée, un graphisme peu alléchant.

Mieux vaut une application stable, intuitive, agréable à l’œil, quitte à ce que le fonctionnel ne soit pas exhaustif : les utilisateurs apprécieront davantage, noteront de manière plus positive l’application sur l’Android Market. Cela donnera lieu à d’autres versions qui viendront l’enrichir fonctionnellement, cela permet de proposer aux utilisateurs des mises-à-jour qui démontre le dynamisme du produit, et cela permet de rectifier les erreurs commises et remontées par les utilisateurs pour les futures versions. Il nous faut donc bien une feuille de route pour l’application, en terme de versions.

Les opportunités de réutilisabilité

Android présente la particularité de promouvoir de manière élégante et puissante l’usage d’autres applications. Cette particularité est très souvent méconnue et non maîtrisée par les éditeurs et les développeurs. En effet, par le mécanisme d’intention, il est tout à fait possible de faire accomplir à d’autres applications déjà installées certaines tâches : envoyer un e-mail, partager un texte, partager une image, choisir une image… Plutôt que de recoder ces fonctions dans l’application, il est important de connaître ce que le système gère déjà, voire ce que d’autres applications existantes et populaires proposent déjà. Si l’on souhaite poster un “tweet” dans une application, mieux vaut réutiliser cette fonction dans les applications spécialisées dans ce domaine : en optant pour cette stratégie, on résout de facto les problèmes d’authentification, et finalement si l’utilisateur ne dispose pas de client Tweeter sur son terminal, il n’est pas forcément nécessaire de lui proposer cette fonction de “tweet”.

À l’inverse, est-ce que l’application qui va être développée ne pourraît-elle pas être réutilisée en partie par d’autres applications Android ? Si je développe une application qui manipule des POIs, i.e. des objets de points d’intérêt géographiques (recherche suivant des critères, affichage sous forme de liste, sur une carte), n’ai-je pas intérêt à exposer une fonction de choix d’un POI associée à des coordonnées géographiques ? En effet, d’autres applications pourraient exploiter cette fonctionnalité. Si tel est le cas, il faut penser à accompagner la publication de l’application d’une documentation destinée aux développeurs, leur permettant de savoir comment réutiliser une partie de mon application. Il existe déjà depuis pratiquement le début d’Android des répertoires comme OpenIntents, qui listent et donnent l’usage d’intentions réutilisables.

Le story-board

La particularité du développement d’applications sur les mobiles est leur exigence vis-à-vis de l’ergonomie : une application qui ne présente pas une ergonomie bien pensée et en phase avec le look&feel du système d’exploitation risque fort de dérouter les utilisateurs, voire de les décourager de l’utiliser. Il est donc primordial de passer par une phase de conception qui va permettre de définir des planches graphiques présentant les différents écrans de l’application, la navigation entre ces écrans, et bien entendu l’ergonomie. Ces planches appartiennent à ce que l’on nomme le “story-board” de l’application. Il ne s’agit pas de présenter des planches qui intègrent le graphisme final de l’application, que l’on doit pouvoir aborder de manière parallèle.

Ces planches doivent répondre aux questions suivantes : quelles actions physiques l’utilisateur va-t-il devoir opérer pour réaliser telle ou telle action fonctionnelle, est-ce que le nombre d’actions est suffisamment faible au regard de l’importance et de la fréquence de cette action, le premier écran affiché met-il bien en avant les actions fonctionnelles que l’application souhaite promouvoir en priorité ? Idéalement, ces planches doivent faire apparaître la manière dont sont matérialisées les transitions entre les écrans, les attentes lorsqu’un traitement est en cours, la manière d’afficher des messages d’erreur : comment l’application doit indiquer graphiquement qu’un chargement de données recueillies depuis Internet est en cours, ce traitement doit-il se faire sur l’écran à venir ou sur l’écran depuis lequel l’action a été prise ; doit-on afficher une fenêtre modale ou bien doit-on faire apparaître un message transitoire dans le cas d’une erreur ?

Les planches doivent s’intéresser aux écrans de réglages de l’application qui sont très particuliers sur Android : un travail fonctionnel doit permettre de réduire au maximum le nombre de réglages mis à disposition de l’utilisateur, car les réglages par défaut d’une application bien pensée doivent satisfaire 95 % des utilisateurs. Muni de ces planches, et parce qu’elles constituent une matérialisation de l’application au travers de ses écrans, le responsable du produit doit pouvoir se projeter dans l’usage de l’application : ces planches doivent être l’occasion de retravailler l’ergonomie et la navigation de l’application au travers de plusieurs itérations. Elles capturent le fonctionnel de l’application et traduisent les fonctionnalités en cinématique et en ergonomie. Ces planches graphiques servent aussi à limiter le risque d’incompréhension entre l’équipe de développement et le responsable du produit : des dessins, des esquisses sont parfois bien plus explicites que des explications textuelles. Un outil comme MockUps est particulièrement bien adapté pour réaliser ces planches.

Une autre particularité d’Android est qu’il est embarqué sur des terminaux qui présentent des caractéristiques physiques très différentes : la taille de l’écran, l’orientation par défaut de l’écran, l’existence d’une roulette, la présence d’un écran tactile. L’ergonomie doit tenir compte de ces particularités, et par exemple, si l’on souhaite qu’une application fonctionne sur tous les terminaux, il ne faut pas présupposer que l’écran du terminal sur lequel elle tourne est nécessairement tactile : cela implique que les boutons doivent être atteignables par une roulette ou de manière tactile. Ces contraintes interdisent parfois des propositions graphiques très léchées au profit d’interface graphiques plus polyvalentes, et il faut bien souvent redoubler d’imagination et d’énergie pour concilier élégance et ergonomie.

Bon nombre d’applications Android résultent aujourd’hui du portage d’applications iPhone : certaines de ces applications viennent calquer l’ergonomie et la navigation, voire pire, le look&feel de leur homologue sur iPhone. Pour une application, ce type de portage est néfaste pour nombre de raisons. L’ergonomie risque de dérouter les utilisateurs, car elle ne respecte pas l’esprit d’Android, et de ce fait, risque de les décourager d’utiliser l’application. Les applications sont désormais soumises à une rude concurrence, et s’il existe une application concurrente respectant la charte, et qui rend un service similaire, il est fort à parier que l’utilisateur finira par l’adopter au détriment de notre application. Sur des terminaux ne disposant pas de roulette ou d’écran tactile, l’application risque fort de devenir inutilisable. Enfin, l’utilisateur déçu risque fort de mal noter l’application, et à partir de ce moment-là, l’application entre dans une logique de cercle vicieux que nous évoquerons plus loin.

Au delà des planches graphiques des écrans de l’application, le story-board doit s’intéresser à différents détails contribuant à la qualité de finition de l’application : comment les erreurs doivent-elles être traitées, quelles sont les erreurs que l’application passe sous silence en tentant une correction automatique ; quelles sont les données qui doivent être mise dans un cache local afin de pouvoir proposer un fonctionnement en mode dégradé en cas de non connectivité à Internet, doit-on mettre en place une politique de cache particulière ? Les messages d’erreur doivent être définis avec le responsable du produit, qui doit s’assurer qu’ils sont clairement compréhensibles par l’utilisateur, et que ces messages sont accompagnés de propositions d’action lorsque cela est possible. Un des intérêts majeurs des applications installées en comparaison avec les applications web est qu’elles ont la possibilité de fonctionner en mode déconnecté : il est donc primordial que le responsable du produit réfléchisse à la mise en place d’une stratégie de mise en cache local des données, et aux problématiques de synchronisation. Par exemple, une application de lecture de la presse écrite qui ne permet pas de lire des articles déjà téléchargés perd grandement de son intérêt. Cette mise en cache peut être très complexe à mettre en place, et peut faire déraper le calendrier de livraison de l’application, donc il est important que le story-board soit très précis à ce sujet.
Les services web

Lorsque l’application nécessite une communication avec une partie serveur, il est nécessaire de mettre en place des services web. Avant de commencer le développement de l’application Android, il est essentiel de s’assurer de différents éléments : est-ce tous les services web sont disponibles afin d’assurer une couverture fonctionnelle, l’infrastructure est-elle taillée pour supporter un nombre important de connexions, l’information qui est envoyée par l’intermédiaire des services web est-elle nécessaire et suffisante, le format de transport est-il adapté ?

Lorsque la plate-forme serveur donne de mauvais temps de réponse, l’application en souffre immédiatement, et peu importe la qualité de l’application, si elle tarde à donne des réponses à l’utilisateur, l’appréciation de l’utilisateur sera mauvaise. Lorsque les services renvoient beaucoup d’informations non utilisées, ou bien que le format n’est pas adapté, l’application est pénalisée à deux niveaux : elle consomme beaucoup de bande passante réseau (les opérateurs telecom y sont de plus en plus sensibles), les délais d’attente pour l’utilisateur sont inacceptables, l’application consomme beaucoup de CPU à transformer l’information en objets-métiers.

À l’occasion du développement d’une application Android communiquant avec un serveur, il est bien souvent nécessaire de revoir la granularité de ces services web afin qu’ils calquent au mieux avec la disposition de leur consommation dans les différents écran, et afin que la représentation des données soit adaptée (JSON est un très bon format, et de plus Android en intègre un parser natif).

Le graphisme de l’application

Certes, tout le monde ne dispose pas d’une équipe de graphisme : quelle que soit la situation, il est important de ne pas négliger le graphisme de l’application, car nous vivons dans une société de communication dans laquelle le marketing est omni-présent et a largement envahi notre inconscient. Une application présentant un graphisme alléchant lui confèrera une patte professionnelle, qui est un début de gage de qualité pour l’utilisateur. Un soin particulier doit être apporté au pictogramme de l’application, car ce dernier sera utilisé sur l’Android Market : il est nécessaire que l’icône puisse attraper l’œil et attirer la curiosité. Nous ne l’avons pas évoqué, mais le nom de l’application est également très important et il faut préférer des noms courts.

Dans le cas où l’équipe de développement ne maîtrise pas le formalisme d’habillage graphique sur Android, ou quand le responsable du produit ont encore peu de culture sur Android ou bien lorsqu’aucun graphiste n’est disponible, il est conseillé d’opter pour la sobriété : Android propose un rendu par défaut discutable mais les utilisateurs y sont habitués, et s’aventurer dans un graphisme ambitieux risque de produire un effet désastreux.

Le formalisme d’habillage graphique d’une application Android est complexe et assez mal documenté. À la manière de CSS et HTML, il permet d’appliquer des styles à des éléments graphiques. De même, Android permet de réutiliser dans différents écrans des agencements d’objets graphiques. Le développeur devra apprendre à maîtriser les différents types de conteneur graphiques, à éviter d’imbriquer trop en profondeur ces conteneurs sous peine d’erreur à l’exécution. La définition des écrans se fait par l’intermédiaire de fichiers XML, ainsi que la définition des styles. Le développeur veillera à déporter la spécification de style des éléments graphiques dans les fichiers dédiés aux styles, couleurs, tailles. Le greffon Eclipse pour Android propose une interface d’édition de ces écrans, mais elle fonctionne assez mal et ne rend pas fidèlement le résultat : mieux vaut tester le rendu des écran dans l’émulateur, voire réaliser des tests sur un éditeur d’écrans comme DroidDraw. Il est possible d’exprimer les éléments graphiques directement dans le code Java, mais comme toujours, ne vaut-il mieux pas dissocier le fond de la forme ? Si l’éditeur de l’application souhaite rendre ses graphistes autonomes au niveau de la définition des écrans, ces derniers pourront même apprendre et utiliser ce formalisme, certes à condition que ces derniers disposent d’une bonne dose d’opiniâtreté.

Le développement

Nous n’allons pas décrire la manière de coder une application Android, mais intéressons-nous à quelques spécificités.

Du fait qu’une application Android est codée en Java, avant de se mettre à écrire une fonction, le premier réflexe consister à regarder si une bibliothèque libre de droit ne serait pas déjà disponible pour la réaliser. À l’inverse, si l’application fait des appels à des services web et que l’on souhaite pouvoir réutiliser ce code dans une application web ou desktop, il faut s’efforcer de rendre cette partie de code indépendante d’Android. Idéalement, les parties du code qui s’intéressent à la modélisation des objets-métier et aux services web doivent être développées en méthodologie de programmation orientée par les tests, afin de maximiser la fiabilité du code, et ne devraient pas utiliser les “packages” Java propres à Android.

Il est important de ne pas coder “en dur” les chaînes de caractères visibles par l’utilisateur, mais à bien utiliser le mécanisme d’internationalisation mis à disposition au travers des ressources Android. De même, il est important d’embarquer certaines ressources graphiques pour différentes résolutions et densités d’écran. Il faut tenir compte qu’un écran d’application, à savoir une activité, peut être interrompue à tout moment : il est donc nécessaire de penser à sauvegarder l’état de l’écran au plus tôt, à condition de ne pas pénaliser les performances.

Le SDK d’Android propose des outils d’analyse de consommation de la mémoire, ainsi que de consommation du processeur : il est primordial d’y avoir recours lorsque des problèmes de latence et de réactivité de l’application commencent à apparaître. De manière générale, une bonne compréhension du garbage collector Java est un plus, et une programmation soucieuse de l’usage des ressources est primordiale, car n’oublions pas que l’application s’exécute dans un environnement plus restreint qu’un ordinateur classique.

Afin de bien comprendre comment l’utilisateur navigue dans l’application, et quelles fonctions sont utilisées, il est important d’intégrer des modules de statistiques spécialisés pour les mobiles, tels Flurry, Motally ou bien Google Analytics, qui proposent des bibliothèques idoines. Il faut éviter de succomber à l’usage de services de statistiques spécialisés pour Internet, pour deux raisons : la navigation dans une application mobile n’est pas comparable à celle dans une application mobile, et bien souvent ce type de service ne capture pas et ne restitue pas les informations de manières pertinente. D’autre part ces modules ne gèrent pas le mode déconnecté : lorsque l’utilisateur fait usage de l’application en mode déconnecté, les données sont perdues.

L’équipe de développement doit parfois intégrer des bannières publicitaires provenant de régies ne disposant pas de bibliothèque de développement : bien souvent, l’intégration est douloureuse, et c’est une bonne idée de réaliser des tests très tôt lors de la phase de développement.

La recette

Comme tout logiciel, une application doit être soumise à une recette. Cette recette doit se faire sur un vrai terminal physique, voire sur des terminaux disposant de des tailles d’écrans différentes. Idéalement, l’application doit être testée sur terminal qui n’est pas un haut de gamme, afin de vérifier qu’elle se comporte bien pour les terminaux les moins puissants.

En particulier, le testeur doit mettre l’accent sur le comportement de l’application en mode déconnecté, en mode de connexion intermittente. Il doit s’assurer que l’application est stable lorsque le terminal est chahuté et que l’utilisateur bascule l’écran du mode portait au mode paysage et vice-versa, lorsque le clavier physique est déployé, notamment lors des traitements longs. Le testeur doit vérifier que l’ergonomie reste bonne lorsque le clavier virtuel est déployé, et que ce dernier ne vient pas obstruer certains contrôles graphiques.

Afin de corriger au plus tôt les problèmes d’incompréhension et les bugs, mieux vaut ne pas attendre la livraison finale de l’application pour réaliser des recettes intermédiaires, dans l’optique ‘une démarche itérative. Le fait que l’installation d’une application ne nécessite rien d’autre que de fournir son fichier d’installation portant l’extension .apk permet de mettre à disposition cette version sur un Intranet, et de la déployer sur un nombre importants de terminaux. De plus, le SDK Android proposant une automatisation des tâches de construction du livrable basée sur Ant, il est tout à fait possible d’industrialiser ce processus de construction sur des software factories : c’est un énorme avantage que propose Android par rapport à la concurrence, et qui ne semble pas encore totalement exploité.

La distribution

La bonne nouvelle pour le responsable du produit, c’est qu’à la soumission de son application sur le marché Android, cette dernière sera immédiatement disponible pour ses utilisateurs. En effet, comme l’Android Market ne fonctionne pas avec un mode de modération des applications a priori, il suffit de créer un compte Google Android Market qui coûte 25$, puis de poster le fichier d’installation de l’application. Avant de poster l’application, il faudra avoir préparé un texte de présentation succinct traduit, deux captures d’écran, et décider dans quels pays l’application doit être publiée, et dans quelle catégorie elle doit figurer. Le fichier d’installation de l’application doit être signé : attention à ne perdre le fichier de l’entrepôt des clés, car sinon, il sera impossible de poster une autre version de l’application !

Et bien entendu, il est nécessaire d’avoir préparé un plan de communication et marketing de l’application : en effet, de plus en plus d’applications sont mises en ligne chaque jour sur l’Android Market, et, à moins d’être une grande marque et d’être le premier de son segment marché à publier une application, il est nécessaire de rendre l’application visible.

Il ne faut pas se hâter à publier l’application à tout prix, car le risque est de bâcler cette mise en ligne : de mauvaises notes font descendre le classement de l’application dans sa catégorie, les utilisateurs constatant une mauvaise note ne sont pas enclins à la télécharger, et l’application perd en visibilité et en crédibilité. Il est alors très difficile de relever la pente, car l’application entre dans un cercle vicieux. D’où l’intérêt de produire une première version percutante, quitte à réduire le périmètre fonctionnel. Une fois l’application mise en ligne, il reste à suivre via son compte Android Market son taux de téléchargement, à étudier les statistiques d’utilisation de l’application, et à analyser les commentaires faits par les utilisateurs sur l’Android Market. Même s’il existe des sites Internet permettant d’accéder via le navigateur Internet aux commentaires et à la notre précise, l’Android Market manque cruellement d’une telle fonction native !

Il est important de noter que l’Android Market n’est pas la seule source de publication d’applications : il existe déjà d’autres plate-formes comme SlideMe. Enfin, dans le cas où l’application est destinée au monde B2B et que l’éditeur ne souhaite pas être visible du grand public sur les places de marché, il lui suffit de proposer l’application en téléchargement directement depuis son site Internet privatif : cela constitue une alternative intéressante qui fera probablement d’Android une plate-forme d’avenir dans le monde professionnel aux côtés de RIM.

Nous nous sommes penchés sur les différentes phase de développement d’une application Android. Dans un prochain volet, nous aborderons des perspectives d’avenir du développement sur Android.

Volet 3 : Des perspectives du développement sur Android

Lire aussi