Industrialisation des développements Android

Avec la croissance de la plateforme Android et l'annonce de Google sur le nombre de terminaux activés chaque jour, le nombre de projets Android a de bonnes chances de progresser également. Avec cette augmentation, la question de l’industrialisation des développements se pose donc. Pourquoi industrialiser ? Comment ? Des questions auxquelles nous allons répondre dans ce billet…

Pourquoi industrialiser ?

Autant sur une application de gestion, la question ne se pose quasiment pas, autant sur une application Android, on est en droit de se demander si cela vaut le coup.

Effectivement, alors que les projets java se déroulent généralement sur plusieurs mois avec des équipes un peu conséquentes, les projets d’applications mobiles sont généralement plus courtes, avec des équipes plus petites. Les applications doivent être innovantes et rapidement mises sur le Market pour arriver avant la concurrence. Cela vaut-il donc le coup d’investir dans tous les moyens habituels (build, intégration continue, …) qui peuvent paraître lourds et démesurés pour un tel projet ?

A fortiori, le versionning du code est indispensable, peu importe la nature et la taille du projet. Je ne vais pas m’étendre sur le sujet, cela fait des années que cette pratique s’est généralisée. Concernant le build et l’intégration continue, cela a un intérêt dès lors que l’équipe de développement est constituée de plus d’une personne. Cela facilitera le travail des développeurs et permettra d’avoir une version rapidement montrable au marketing ou la MOA, indispensable pour avoir du feedback rapide.

Malgré la taille réduite de ces projets, il ne faut donc pas hésiter à investir un minimum pour faciliter le travail des développeurs d’une part et dans une optique de maintenance d’autre part. L’application doit certes sortir rapidement, mais elle devra continuer de vivre et d’évoluer et donc la qualité incombe.

Maven, la bonne solution ?

Maven a ses détracteurs mais est globalement très répandu en entreprise pour construire les projets java. Concernant Android, je ne suis pas sûr qu’on puisse en dire autant pour le moment…

Après l’avoir utilisé sur l’application Sinistres de Generali, plusieurs constats :

• Les jar Android n'étaient disponibles dans aucun repo central. J’ai contacté Romain Guy pour avoir des infos sur le sujet mais aucune réponse. Ils sont disponibles depuis quelques jours sur le repo central. Enfin ! Par contre, il manque encore google maps.
• Le plugin mosabua, décrit dans le livre Maven Definitive Guide, censé remédier à cela en installant les jar dans le repo local, nécessitait il y a encore peu de temps de modifier les pom.xml pour concorder avec les versions du SDK Android (1.5 pour la 3, 1.6 pour la 4…). Cela semble aujourd’hui résolu mais nous a fait perdre pas mal de temps.
• Une fois installé, le plugin fonctionne plutôt bien et permet de compiler, tester, packager, déployer sur un émulateur… depuis sa ligne de commande mvn.
• Par contre, n’espérez pas trop utiliser le trio Eclipse - Maven - Android, y compris avec m2eclipse. Les trois s’entendent assez mal : les projets Android sous Eclipse ont un format un peu particulier (répertoire gen généré lors des modifications de ressources, référencement du sdk Android). Lorsque m2 est activé sur le projet ou simplement avec eclipse:eclipse, plus rien ne fonctionne : On perd le type Android du projet et il s’emmêle les pinceaux avec le répertoire gen donc impossible de travailler depuis Eclipse, fâcheux. Il existe un plugin eclipse supplémentaire pour tenter d'intégrer les trois mais ca n'a pas fonctionné pour moi...

Au final beaucoup de temps perdu pour avoir un environnement de développement un peu bancal et la question : est ce que Maven est vraiment utile dans notre cas ? On pense tout de suite à Maven lorsqu’il s’agit de builder notre application mais n’est-ce pas un peu too much ?

L’un des principaux bénéfices de Maven est la gestion des dépendances. Hors, dans une application Android, le nombre de dépendances est somme toute assez ridicule. Vous aurez généralement l’api google maps, éventuellement une librairie pour faire du soap, et en poussant le bouchon admob ou google analytics. Aucune dépendance transitive. Bref, pas de quoi sortir la grosse artillerie. D’autant plus qu’aucune de ces librairies n’est dispo dans un repo central et il vous faudra donc les installer manuellement dans un repo d’entreprise ou local.

Pour le reste, toutes les commandes disponibles grâce au plugin Maven le sont également avec ant, qui semble être l’outil préconisé par Google.

Ant, la solution fournie en standard

Lorsque vous créez un projet via la ligne de commande (android create project --target 8 --name AndroidAnt --path ./AndroidAntProject --activity AndroidAntActivity --package com.octo.android.androidant), un fichier build.xml est généré, contrairement aux projets créés dans Eclipse. Ce build.xml minimaliste (quasiment vide) fourni toutefois l’essentiel des tâches nécessaires :

• clean, pour nettoyer le projet
• compile, pour compiler le code et générer les classes
• debug, pour générer le package (apk) avec le keystore de debug (généralement dans $HOME/.android/debug.keystore)
• release, pour générer le package avec votre keystore (généralement celui que vous allez utiliser pour publier sur le market)
• install, pour installer l’application sur un émulateur (démarré) ou un device connecté.
• uninstall, pour désinstaller l’application précédemment installée.

C’est assez confortable car vous n’avez pas à écrire ces tâches, elles sont définies dans le fichier {SDK}/platforms/{platform}/templates/android_rules.xml. Comparé à toutes les tâches plus ou moins manuelles à effectuer avec Maven, on y gagne franchement au départ.

Par contre, la solution Ant souffre également de l'intégration avec Eclipse. En effet, les tâches étant définies dans un fichier externe, elles ne sont pas disponibles dans la vue Ant. La solution alternative consiste à utiliser les external tools avec une des commandes ci-dessus.

Intégration continue

Si les deux outils vu précédemment sont un peu en désaccord avec l’IDE, ils n’en restent pas moins tout à fait utilisable en dehors via la ligne de commande et donc également via un outil d’intégration continue comme Hudson.

Aussi simplement que sur un projet Java standard, vous pouvez configurer un build (maven ou ant) et la commande souhaitée. Mais Hudson va plus loin puisque via le plugin Android Emulator Plugin, vous pouvez démarrer l’émulateur au début du build et l’éteindre à la fin. Vous pouvez également installer l'application sur différentes configurations (version d'Android, résolution d'écran, densité d'écran, locale) afin de valider l'application sur les différentes plateformes cibles. Si vous ne testez que sur une plateforme, mieux vaut laisser un émulateur fonctionner, ca évite de perdre plus de 5 minutes à chaque build.

Pour le reste, tout se passe comme pour un build standard, la seule particularité étant d'avoir le SDK installé sur le serveur d'intégration continue.

Conclusion

Alors, Ant ou Maven ? Après nos déboires avec Maven sur le projet Generali, j'aurai conseillé Ant sans hésiter. L'arrivée (très) récente des jars dans le repo central me laisse à penser qu'on pourra bientôt travailler avec Maven, Android (et Eclipse) plus sereinement.

Android a l’avantage d’être basé sur le langage Java. On bénéficie ainsi des outils existants pour construire nos applications. Si l’intégration n’est pas totale entre l’IDE, le SDK et ces outils de builds, ils sont indispensables sur un serveur d’intégration continue. C’est aujourd’hui leur principal intérêt, car Eclipse et le plugin Android (AJDT) restent à mon sens incontournable sur le poste du développeur pour être productif.

Dans un prochain article, nous aborderons les problématiques de qualité du code et des tests...