Sinistres de Generali, plusieurs constats :
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.
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 :
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.
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.
Maven | Ant | |
Simplicité / Prise en main | 2/5 <br>(plugins diverses pas encore opérationnels) | 4/5 <br>(par défaut avec Android) |
Gestion de dépendances | 3.5/5 <br>(les jars android sont enfin sur central, manque encore maps) | 2/5 <br>(pas besoin de préciser les jars android) |
Intégration IDE | 2.5/5 <br>(utiliser les external tools) | 2.5/5 <br>(utiliser les external tools) |
Intégration continue | 4/5 <br>(plugin hudson) | 4/5 <br>(plugin hudson) |
TOTAL | 12 / 20 | 12.5 / 20 |
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...