[Développement] Application Android

posté le 23 July 2014 à 14:37

Salut les geeks (oui, si vous avez cliqué malgré le titre, vous êtes irrémédiablement un geek, voir un nerd), et attention: voilà du wall of text!

Comme je me suis lancé dans l'aventure des applications mobiles depuis quelques mois, et que j'ai appris pas mal de choses en cours de route, je me suis dit que ça pouvait valoir la peine d'écrire un post pour:
1) partager avec ceux que ça pourrait intéresser les trucs que j'ai appris (en particulier des outils/librairies sympa comme tout)
2) apprendre vos propres trucs et astuces

J'ai mis Android dans la titre, parce que c'est mon focus du moment, mais si vous avez des trucs et astuces qui peuvent s'appliquer aux applications mobiles dans l'absolu, ça marche aussi. Par exemple (pas tout à fait au hasard: je vais avoir à faire ça dans pas longtemps donc si quelqu'un sait comment faire ça, je suis preneur d'un peu d'aide): vous connaissez un super outil pour mettre en place vite et bien un webservice en java hébergé sur l'AppEngine de google (et pouvant donc servir de backend à une application web ou mobile), allez-y, dites nous tout!

Et histoire de démarrer le truc, voilà ma première pierre à l'édifice:

Recrute majordome, mobilité et capacité à rédiger des rapports exigées

Déjà, et contrairement à ce que j'avais lu sur plusieurs sites (dont l'habituellement raisonnablement bien renseigné openclassroom, ex site du zero), il est tout à fait possible de mettre en place un environnement d'intégration continue pour un projet Android. S'il y en a qui ne savent pas ce que c'est que l'intégration continue et pourquoi c'est génial et qu'on ne peut plus s'en passer une fois qu'on y a goûté, faites-moi signe dans les commentaires (en particulier si vous bossez sur un projet avec plus de 4 personnes sur la même base de code).


Pour cela, il faut:
 - un SCM (SVN ou Git, ma préférence allant à ce dernier depuis que je l'ai adopté en janvier dernier, si ça intéresse quelqu'un je pourrais expliquer pourquoi)
 - un outil de compilation (Gradle, Ant ou Maven, je connais déjà Maven donc je reste sur celui-là mais à priori c'est possible avec les 2 autres quasiment de la même manière)
 - un serveur d'intégration continue (vous posez pas de question, c'est Jenkins qu'il vous faut)

La difficulté réside dans la capacité à faire compiler le projet avec l'outil de compilation. Par compiler, j'entends; compiler les fichiers de code .java en .class (ça Maven sait le faire en natif), produire le .dex qui les réunit tous, puis intégrer le .dex et les ressources dans l'apk (signé ou non, selon qu'on est en debug ou en release), déployer et executer sur un device (c'est à dire un téléphone ou un tablette connectée en USB et avec le mode debug activé) ou sur un émulateur (parce qu'on a pas tous les moyens d'avoir 15 devices différents pour tester toutes les tailles d'écran et toutes les versions d'android), tout ça x2 puisqu'il faut un projet "principal" (l'application en elle-même) et un projet de test (vous testez votre code, n'est-ce pas?).

Pour ma situation (Maven + Jenkins), il faut 3 outils:
1) Un "outil" appelé "Maven Android SDK deployer", qui va essentiellement ajouter à votre repository Maven local les jar des différents versions d'android (et des extra, genre les Google APIs si vous vous utiliser Google Maps, etc), sachant que sa plus-value principale est surtout sur ces extra (les jar des principales version d'android étant désormais ajoutés par google sur Maven Central).
2) un plugin maven: le bien nommé "Android Maven Plugin" qui va ajouter à maven quelques goal bien pratiques, tels que "android:deploy" pour déployer un apk sur un device ou un émulateur, ou encore "android:run" pour lancer l'execution. Et aussi un format de packaging supplémentaire "apk" (sachant que maven gère nativement "jar" et "war" il me semble).
3) un plugin Jenkins: le (lui aussi bien nommé) "Android Emulator Plugin" pour automatiser la création d'émulateurs, leur paramétrage, obtenir les résultats d'une exécution, bref, tout ce qu'il faut pour de l'intégration continue. Pardonnez moi de rester flou sur ce point, je suis tout juste en train de le mettre en place, je ne maitrise pas encore super bien (mais encore une fois, si ça intéresse du monde, je pourrais développer au fur et à mesure de mes avancées).

Tout ça c'est chouette comme tout, vous allez pouvoir mettre en place une intégration continue de votre projet Android, et tout sera pour le mieux dans le meilleur des mondes...

Plus vite nestor ou je te remplace par un mouton réplicant

... enfin presque, parce que bon, même comme ça, l'intégration continue ne va pas se déclencher toute les 3 minutes non plus et même si c'était le cas, lancer un émulateur, déployer l'apk dessus et lancer l'appli ça prend au moins quelques minutes dans le meilleur des cas. Donc pour dérouler des tests de non régression fonctionnels ça va encore, mais pour du test unitaire c'est pas idéal.

Et c'est là qu'intervient ma découverte d'hier (qui a motivé ce post interminable): Robolectric. Cette petite merveille (gratuite et open source, comme tous les outils/plugins cités jusque là) "remplace" le fichier android.jar habituel (et qui vous jettera des "java.lang.RuntimeException : Stub!" à la tronche si vous essayez de le faire tourner dans un JVM classique car il ne contient aucun vrai code, uniquement les déclarations d'API pour vous permettre de compiler) par ce qu'il faut (non, j'en sais rien et je sais même pas comment, mais ça marche) pour que vous puissiez faire tourner votre code de test dans une JVM classique, par exemple (au hasard) celle de votre IDE préféré (Eclipse pour moi, et probablement 90% des dveloppeurs d'appli Android). Ca veut dire que moyennant un peu de paramétrage de raccourcis clavier, il y a moyen d'exécuter vos tests unitaires quasiment à chaque fois que vous sauvez votre fichier de code, et qu'ils seront exécuté presque instantanément. En ce qui me concerne, j'ai re-configuré Ctrl+D pour lancer mes tests unitaires, ce qui fait que je fais très souvent Ctrl + S, Ctrl + D sans même lever le doigt de la toucher contrôle, vous allez voir que ça devient un réflexe assez vite (en vrai, je fais en général Ctrl + O, Ctrl + F, Shift + Ctrl + S, Ctrl + D, pour respectivement: organiser/nettoyer les import, formatter/indenter le code, sauver tous les fichiers ouverts et lancer les tests unitaires, les 3 premiers étant des raccourcis standard eclipse).

Attention, ça ne remplace pas des "vrais" tests fonctionnels sur émulateurs (au pire) et sur device (au mieux), ça vient les compléter. Et si vous ne pouvez pas vous permettre le luxe de faire les deux (même si d'après mon expérience personnelle c'est largement rentable sur le long terme), j'ai tendance à conseiller les test unitaires en priorité, car leur execution quasi synchrone avec l'écriture du code permet d'éviter de s'éloigner de l'objectif en cours de réalisation pour l'heure/la journée. Tandis que les tests fonctionnels délimitent les grandes lignes attendues du point de vue utilisateur que vous allez peut-être mettre des semaines voire des mois à atteindre...

La prochaine fois (c'est à dire: quand j'aurais eu le temps de tester) je vous parlerer de Dagger, une chouette librairie pour faire de l'injection de dépendance sur Android (et pour les suivantes, j'ai au menu: Mockito, un framework de mock pour compléter Robolectric, Otto, une librairie de bus évennementiel à la guava, ButterKnife pour faire l'injection des vue dans une activité, Retrofit, un client REST type safe pour android et plus largement pour Java et FestAndroid, une collection d'assertion AssertJ pour android).

Voilà, c'est tout pour aujourd'hui!

Des questions? Des avis? Vous avez rien compris mais ça vous intéresse et vous voudriez que j'explique un terme ou un concept précis? Les commentaires sont la pour ça, lâchez-vous!

tags : agilité, android, développement, intégration continue, java, jenkins, maven, mobile, robolectric, tdd, tests unitaires
9 commentaires

Commentaires

Repiemink a dit :
posté le 24 July 2014 à 09:01
C'est fantastique.
Tu fais quoi donc comme appli?
C'est toi l'inventeur de l'appli simulation de buvage de cannette?
Quand est-ce que l'action Plantmann™ va prendre la place de celle de King?

citer
Akshell a dit :
posté le 24 July 2014 à 10:06
je dirais que ça manque de concret, quel est le but ?
Parce que mettre en place un env d'intégration continue ok.
j'en ai même mis un sur le serveur, svn+jenkins+sonar, et il faudrait que je rajoute un nexus pour l'historisation, bon c'est plus pour du dev java classique.

Ce qui m'a gêné dans le dev android, et même dans le dev de ce type de projet, webservice, website, etc. c'est où est le point d'entrée, par où on commence ?

J'ai déjà tenté d'installer le devkit android, ça prend une plombe, tu galères pour installer l'émulateur. et puis tu compiles les projets de test, ça échoue, et si éventuellement tu y arrives ça marche pas sur l'émulateur.

Et puis comment on fait une putain d'interface ?

citer
kaplan a dit :
posté le 24 July 2014 à 12:20
J'ai rien compris mais bravo !
Dis nous en plus sur l'appli que tu fais !

citer
plantmann a dit :
posté le 24 July 2014 à 22:18
@tous: Tiens, je m'attendais même pas à avoir des commentaires, donc merci d'avoir lu. J'aimerai pouvoir vous dire en quoi consiste l'appli sur laquelle je bosse, mais je suis tenu par un NDA, du coup je peux même pas évoquer le domaine d'application... :( Mais promis, dès que je pourrais, je vous en causerai, parce que le projet est plutôt sympa

@Akshell:
1) déjà, rappelles-moi de t'expliquer dans un futur proche pourquoi tu devrais passer à Git (sachant que j'ai été un adepte convaincu de SVN pendant longtemps et initialement peu enclin à basculer).

2) concrètement, mettre en place un environnement d'intégration continue, c'est surtout utile pour la non régression. Quand tu as passé des heures (voir des jour) à mettre un truc en place, tu as pas envie que le travail que tu feras dans 3 jours viennent le casser sans que tu t'en rende compte, et tu n'as pas forcément envie de passer 3H par jour à tester chaque écran de l'appli pour vérifier que ça fonctionne toujours comme prévu. C'est d'autant plus important pour le TDD (test driven developpement s'il y en a qui se demandent) où tu commences par écrire les tests.

3) je suis pas un expert web loin de là (l'essentiel de mon expérience s'est faite sur des applications "lourdes" sans ou avec très peu d'aspects réseau), je m'y mets à peine, donc je peux pas trop te dire. Pour les applications mobiles, le point d'entrée c'est effectivement de faire une "bête" application type Hello World! sans aucune communication réseau, juste afficher un label, mettre un bouton, changer le contenu du label quand on appuie sur le bouton, ce genre de choses. Et pour ça, Eclipse est ton ami. Sur le site officiel Android, ils donnent un lien vers une version (assez récente) d'Eclipse avec tout ce qu'il faut de plugin installés. Ensuite, il faut utiliser le wizard de création de projet d'Eclipse pour créer une appli du genre de ce que je disais plus haut. Par contre c'est Eclipse/ADT qui gère la compilation et le packaging (et tout le reste en fait), donc pas compatible avec de l'intégration continue, mais au début, le temps de te former, rien à battre.

Allez, mon prochain article (dans qq jours probablement) sera sur la mise en place d'un environnement de développement de base pour Android et Git.

citer
kaplan a dit :
posté le 25 July 2014 à 10:02
Tiens, question idiote : pourquoi tu/vous développez sous Android alros qu'il est réputé que les applis Android sont fortement piratées et rapportent keud alors que ce sont les pigeons utilisateurs iOS qui rapportent des brouzoufs ?

Autre question : j'ai depuis lontemps une idée d'appli qui me rendrait assurément milliardaire en dongs vietnamiens (de quoi me payer un jeu PC en promo, donc).
Quel serait le meilleur moyen de :
- savoir si techniquement elle est réalisable ?
- comment estimer à la louche son prix de réalisation sous iOS et sous Android ?

T'as vu comment j'ai détourné ton post, là ?
(j'espère que ça t'emmerde pas)

citer
Cyp a dit :
posté le 25 July 2014 à 14:24
J'attends ton article sur Git alors, dans mon taf on utilise encore l'ancêtre CVS... On avait tenté de switcher sur SVN à une époque, mais le plugin eclipse déconnait pas mal.
Donc si tu peux étayer dans ton article les avantages pratiques de Git sur les autres, je ferais un copier/coller pour présenter à ma direction :p

citer
Akshell a dit :
posté le 25 July 2014 à 17:50
sache que ce qui me fait chier avec git c'est que le plugin eclipse est encore plus buggé que celui de svn et que le plus souvent, surtout en cas de conflit la seule solution est en ligne de commande après avoir cherché la commande sur stackoverflow.

citer
Ellendhel a dit :
posté le 26 July 2014 à 15:09
Ça fait un moment que je me dis "il faut que je me mette à Git" pour mes développements de scripts et autre et j'en suis toujours au point mort. Un petit article pourrait me redonner un peu de motivation.

citer
plantmann a dit :
posté le 27 July 2014 à 14:26
@kaplan: c'est très simple: android = java = confortable et rapide à développer, iOS = objective-C = lent à compiler, et pénible à écrire. Et aussi parce que l'appli sera gratuite (et sans pub et sans achats in-app, le business model est original) donc on risque pas tellement le piratage. Et aussi parce qu'android permet d'accéder à une communauté d'utilisateur beaucoup plus vite et donc de gagner en visibilité rapidement (même avec quelques utilisateurs piratés, on s'en fout). Mais iOS suivra rapidement.

@les autres: en ce qui concerne Git, le plugin Eclipse marche très bien tant qu'on se limite à de l'utilisation standard (créer une branche, stage et commit dans cette branche, changer de branche, merger une branche dans une autre, pousser ou tirer une branche depuis un autre repository). Dès qu'on veut des trucs plus complexes/plus avancés (ré-écrire l'histoire, chopper seulement certains commit d'une branche, faire un rebase, etc) la ligne de commande est effectivement conseillée. Mais d'une part c'est assez rare d'avoir à faire ce genre de choses, d'autre part c'est en général l'administrateur du repository "central" qui s'en charge et lui est souvent un admin système habitué à la ligne de commande de toutes façons

Je détaillerai tout ça dans mon article (du coup je vais d'abord en faire un sur git, je ferais les base d'android ensuite)

@Cyp: ok, mais je veux un pourcentage de la prime que tu n'auras jamais.

citer

Poster un commentaire

Invité

Vous souhaitez commenter immédiatement ce billet. Vous ne pourrez pas l'éditer une fois envoyé.

Membre

Vous êtes membre ou souhaitez vous créer un compte sur l'asile.fr