Droidcon ’15 : Javaiste au pays des droides

Les 9 et 10 novembre dernier s’est tenue la Droidcon version française à Paris.

Bien que non officiellement développeuse Android, je m’y intéresse et quand SOAT m’a proposé une place pour y assister, j’étais plus qu’enthousiaste. Et à raison !

Même si le nombre de participants est, à vue d’œil, bien plus restreint qu’au Devoxx, les sujets étaient de haut vol et il y en avait pour tous les publics, des débutants (comme moi) aux expert(e)s.

Petit tour d’horizon des sujets marquants.

Keynote : Evolution inside the build system

Eric Lafortune, Guardsquare – Tous niveaux

Jusqu’à présent, la compilation d’un code Java (fichier .java) en bytecode (fichier .class) est la même aussi bien pour du code Android, que celle d’une application java standard :

Le .java passe par le compilateur javac d’Oracle et produit du bytecode.

Sous Android, ce bytecode est de nouveau optimisé et recompilé en .dex, avant d’être exécuté par la VM Dalvik/ART de Google (et non pas la JVM comme en java standard).

Visiblement, passer, d’une façon ou d’une autre, par le compilateur d’Oracle dérange un tout petit peu Google qui, dans le SDK 21.1, a introduit les librairies Jack et Jill.

Pour faire simple :

La librairie Jack.jar compile les .java en .dex sans utiliser le compilateur d’Oracle et produit des fichiers intermédiaires .jayce à la place des .class.

Et pour les .class qui, malgré elles, se retrouveraient dans les applis Android, la librairie jill.jar permettrait de les compiler en .jayce, passant ainsi la main au compilateur Jack pour les recompiler au format .dex.

En résumé, on passe de ça :

À ça :

L’objectif de cet article n’est pas de décrire la compilation en détails.

Si le sujet vous intéresse, le mieux reste de parcourir les PDF,  de revoir la keynote ou encore lire ce post de blog, publié par Eric Lafortune sur le sujet.

Attention, pour l’instant, ce nouveau compilateur n’est pas java 8-friendly ; il faudra suivre ce qui sera fait à l’avenir par rapport aux évolutions du langage Java.

La keynote était suffisamment bien présentée pour tout comprendre sans être expert(e) et  m’a mise en appétit pour la suite.

Performances matters

Ran Nachmany, Google – Tous niveaux

Saviez-vous qu’utiliser Json c’était mal ?  À la fin du talk, c’est la question que l’on se posait les uns aux autres parmi les Soatiens présents. Comment était-ce possible que sérialiser et dé-sérialiser des réponses de web services au format JSON soit “horrible” au point qu’un Googler nous incite à l’abandonner tant qu’on pouvait ?

Après explication, ça tombe sous le sens.

Par défaut, lorsque l’on a affaire à un payload JSON, on se préoccupe peu du type final des attributs. Au pire, on utilise GSON ou Jackson pour mapper le tout et le tour est joué.

Le problème est qu’il y a immanquablement une phase de copie en mémoire lorsque l’on veut consommer un service. Lors de cette phase de copie,  il faut pouvoir déterminer le type de chacun des attributs (Date, int, String, etc.) ce qui est coûteux en termes de performance et devient superflu avec les Flatbuffers.

Car, contrairement aux formats JSON et XML, qui favorisent la lisibilité avec leur format texte, les Flatbuffers sont des fichiers binaires, résidant directement en mémoire, dont la structure est définie en amont par un schéma fortement typé, rétrocompatible, et gérant des champs optionnels, qui va être compilé en Java.

Leurs performances par rapport au JSON et à l’XML vont bien au-delà de ce que l’on peut imaginer. La preuve :

Du zero copy on vous dit !

Nul doute que cette notion dépasse largement l’écosystème Android et qu’apprendre son existence nous transforme quasi-instantanément en adepte en puissance.

Au-delà de ce point qui m’a le plus marqué, la conférence s’applique également à montrer des solutions d’optimisation de la batterie, de la bande passante pour ce qui est de la connectivité et de la mémoire.

Je vous encourage à voir ce talk de Ran Nachmany pour en apprendre plus sur ces points.

A/B Testing sur le PlayStore

Alexis Fogel, Dashlane – Tous niveaux

Développer une application, c’est bien. Voir qu’une fois sur le store, elle est téléchargée/achetée ET utilisée/adoptée par une grande communauté d’utilisateurs/clients, c’est toujours mieux.
Alexis Fogel, nous apprend qu’il est commun pour le marketing d’observer jusqu’à 95% d’écart entre le nombre de visiteurs de notre application sur le Store et le nombre d’utilisateurs réels de notre application. Il le traduit visuellement par le schéma ci-dessous :

Pour convertir ces simples visiteurs en clients, l’une des recommandations de Google est de publier son application et ensuite, grâce à l’A/B testing, de faire varier les graphiques (icônes, images) et le texte (description) de l’application et d’analyser leur impact dans le taux de conversion et ce, directement sur le PlayStore, plus ou moins gratuitement.

Pour montrer la pertinence de l’A/B testing, Alexis Fogel présente le cas d’une campagne réussie qui, rien qu’en modifiant les fiches de présentation de l’application, permet de gagner 10% au moins de clients réels.Le talk est en fait un retour d’expérience. Pour connaître ce qu’ils ont entrepris comme expériences dans sa startup et les résultats inattendus obtenus, le mieux, comme plus haut, reste de revoir la conférence ou lire le post de blog équivalent.

À noter qu’améliorer des métriques de son application n’est pas une science exacte.

Ce qui est intéressant, justement, c’est de mener des campagnes de tests (limitées à une seule par application) au cours desquelles on modifie des composants de l’application.

En définitive, la conférence a le mérite d’aborder les aspects marketing et vente d’une application, et nul doute que l’information a été bien reçue par les développeurs à la conférence.

Kotlin : super star des conférences

 

Pas moins de 3 conférences lors de l’après-midi de la deuxième journée abordaient directement, ou indirectement, Kotlin comme THE langage pour écrire des applications Android.

Du live coding d’une application en moins d’une heure par Mounir BOUDRAA, de chez SNIPS, à l’excellent talk de Brian Egan et de Guillaume Lung de Soundcloud (résumé plus loin), sans compter les conférences auxquelles je n’ai pas pu assister, le nouveau langage de JetBrains était omniprésent.

La question n’est plus de savoir s’il faut éventuellement s’y intéresser, mais plutôt ce qu’attendent les développeurs pour utiliser le plugin mis à disposition par JetBrains pour convertir leur code Java pour Android classique en code Kotlin ?

Une soif de changement que Nabil Hachicha a tout de même tenu à modérer, lors de son talk sur les techniques avancées de gestion de la concurrence et de la mémoire, en nous priant d’éviter d’utiliser des langages ou des outils juste parce que c’est la mode, et de nous intéresser d’abord à ce qui est proposé nativement sur la plateforme.

Nativement sur la plateforme Android, il n’y a en a que pour Java 6 et 7.

JetBrains et les speakers présentent, à raison, Kotlin comme l’évidente prochaine étape à franchir pour bénéficier des nouveautés de Java 8 sous Android dès aujourd’hui.

Redux, Architecture ELM et RxJava au menu

Brian Egan et de Guillaume Lung, Soundcloud – Tous niveaux

Dans la catégorie futuriste, il y a eu la conférence  « Exploring the possibilities of Unidirectional Data Flow Architectures on Android ».

Étant collègues, Guillaume (développeur Android) et Brian (développeur Front passant au mobile) avaient du mal à détecter l’origine de certains de leurs bugs, du fait de plusieurs événements notifiant un presenter au même moment. Les logs n’aidant pas, ils ont entrepris de mutualiser leurs expériences du front et du mobile afin de débugger et de visualiser en temps réel les modifications d’états, l’idée finale étant d’aller jusqu’à visualiser le résultat des tests en temps réel !

Du talk, il fallait retenir les concepts d’Unidirectional Data Flow, d’Architecture ELM et de Redux, puis s’asseoir confortablement et admirer le résultat de leur expérience.

La mission visant à visualiser les changements d’état en temps réel est visiblement accomplie. Et moi, ébahie.
L’exemple de debug de todoList sur Android est aussi convaincant que celle du debug d’une appli web classique.

Cependant il s’agit d’une expérience et en aucun cas d’un framework/pattern/langage pour des projets allant en production. Il faudra là aussi suivre l’actualité ou participer au projet pour le voir mûrir.

Rétrospectivement, cette collaboration confirme à mes yeux, si besoin était, que notre métier de développeurs peut être décidément plus fun pour peu qu’on s’aventure hors de sa zone de confort.

Ingredients for a healthy codebase : quelle architecture pour les projets Android ?

Romain Piel, Songkick- Tous niveaux

Face à l’énumération du cas de John et Mary, je me suis sentie moins seule.

Le but ici n’est pas de re-raconter la même histoire, l’auteur le fait bien mieux que moi mais, il est nécessaire de reposer le contexte et je me permets de reprendre les images de la vidéo pour cela.

Sur le contexte, John a une idée d’application mais pas de compétence Android. J’imagine qu’il apprend sur le tas et finit par la réaliser et la publier.

Cette application est fonctionnelle et son architecture est plutôt simple.

Mary,  plus aguerrie, doit la faire évoluer. En plus d’ajouter des frameworks tendances (Retrofit et RxJava à l’heure actuelle), elle y ajoute des fonctionnalités.

L’architecture finale de ces deux développeurs reste dans l’ensemble la même.

Mais, l’application est-elle maintenable et testable ?

Pour éviter toute ambiguïté, la réponse du speaker est non, et c’est d’ailleurs pour cela qu’il propose une autre approche.

Partant du principe de clean Architecture d’Uncle Bob, il propose de reprendre les principes d’architecture MVP et de l’appliquer aux projets Android.

Sa proposition finale, ressemble à ceci (spoiler alert) :

Bien qu’elle n’ait pas fait pas l’unanimité sur l’utilisation ou non de RxJava,  le sujet reste pertinent et nécessaire tant la littérature Android sur le web et dans les conférences se focalisent souvent sur des APIs, des frameworks et des technologies, mais pas nécessairement sur l’architecture globale d’une application.

Sa solution est, pour moi, un point de repère grâce auquel on peut mesurer la distance qui nous sépare d’une architecture propre, testable et maintenable sur Android.
Il fallait aussi retenir que “quel que soit l’architecture décidée au départ, il faut s’y tenir”.

Les talks complets revenant sur les fondamentaux

Deux conférences auxquelles j’ai assisté reviennent sur les fondamentaux du développement sur Android :

Dagger 2 – Back to basics de Jérémie Martinez et Task & Document API de Mathieu Calba, tous deux désormais chez Captain Train.

Le talk de Jérémie Martinez reprend les grands principes de l’injection de dépendances avant de montrer les grandes différences entre Dagger 1, développé par Square et Dagger 2, développé par Google.

Celui de Mathieu Calba présente les APIs Task et leur successeur Document, dont la densité n’est pas toujours connue et pour lequel Google se contente de fournir la Javadoc, en nous laissant apprendre à nos dépens les effets de bords des options de Flags.

Le PDF sur Dagger 2 et celui sur les APIs Task & Document peuvent aisément servir de cheatsheet et sont suffisamment complets pour être compris par tous.

L’atelier Android Katas

Corey Latislaw, Green life Software – tous niveaux

Pendant que des barcamps se succédaient au rez de chaussée et dans les autres salles du Tapis Rouge, je faisais partie de ceux qui avaient opté pour un après-midi complet de Katas. Par curiosité, mais surtout par envie d’apprendre des trucs qui m’auraient échappé.

Le but annoncé était, comme en java, de faire des Katas mais sur Android. Malgré un wifi plus que capricieux, certains ont pu aller jusqu’au bout du premier exercice. Je ne saurai dire exactement combien d’exercices il y avait à faire mais, ma binôme et moi avions fini le premier.

De la session, je retiens les problèmes de wifi qu’une configuration d’Android Studio spéciale est nécessaire pour exécuter les tests.

Cela étant dit, les Katas sont disponibles sur le Github du speaker et sont suffisamment bien détaillés pour être reproductibles à l’envie chez soi.

Conclusion

À l’heure où Java 8 côté back connaît une adoption plus rapide que prévue et qu’Android ne supporte toujours que du Java 6 et 7, Kotlin se pose en alternative crédible à Java dès maintenant.

Il propose des APIs similaires à celles de Java 8 et, étant donné qu’il produit du bytecode de Java 6, le nouveau langage de Jetbrains est aussi compatible avec Jack and Jill. Rien ne semble donc pouvoir entraver l’adoption massive du langage pour les applications Android. Mais rencontrera-t-il le même succès sur les applications back ?

Rien n’est moins sûr. Peut-être le saura-t-on lors de Devoxx 2016.

En attendant, le rendez-vous est d’ores et déjà pris pour la prochaine grande messe des droïdes parisiens.