Kotlin, Gradle et Software craftsmanship étaient au programme de la 3è édition parisienne de l’évènement désormais incontournable de la scène Android française, qui a réuni les 9 et 10 novembre derniers plus de 600 participants autour de 50 sessions. Rien à redire sur la quantité, mais il est vrai qu’une part de la communauté française doutait, non sans humour, de la comparaison qualitative avec son pendant new-yorkais.

Un avant goût de nos speakers cette année...................... Vous y avez cru hein ? pic.twitter.com/K72HzJS95r

— DroidconFReuh (@droidc0nFR) 16 Octobre 2015

En effet, et contrairement à l’année dernière, nous n’avons pas eu le privilège d’être évangélisés par des speakers de Square (la boite de Jake Wharton, le Saint patron des développeurs Android), Facebook ou Twitter. Mais qu’importe ! Des grands acteurs français étaient présents (Captain Train, Genymotion, Deezer, Blablacar), et la présence de Jetbrains, Soundcloud et Novoda a suffi à satisfaire nos penchants exotiques.

Kotlin, amen

Developpeurs, développeuses Java, reccueillons-nous. Et souvenons-nous.

De la première fois où l’on a entendu ou vu s’afficher le mot “IntelliJ”. De ce moment où l’on a appris qu’une alternative incroyable à Eclipse était possible. De ce moment à partir duquel nous ne pouvions plus nous énerver de la lenteur et des freezes inexpliqués de notre IDE comme avant. De ce moment où nous sommes passés de la douleur subie à la douleur choisie.

Il nous a pourtant fallu un peu de temps avant de faire le “Grand Saut”. “Mes motivations sont-elles réellement fondées ?” “N’est-ce pas l’essence même de l’informatique que d’éteindre et de relancer un logiciel pour qu’il fonctionne ?”

Et puis... Et puis on se décide enfin à installer IntelliJ. Et à l’utiliser. On retrouve ses repères. On s’en crée très vite de nouveaux. Au bout d’une semaine, on supprime son raccourci Eclipse. Au bout de deux, on fait du prosélytisme auprès de ses collègues, sans hésiter à insulter ouvertement l’IDE qui nous a pourtant été tant bien que mal fidèle si longtemps. Et quelques années plus tard, plus de haine, juste une certaine nostalgie.

Merci qui ? Merci la société Jetbrains, à qui la productivité des développeurs du monde entier doit énormément. Alors quand Jetbrains vient vous annoncer en personne que Kotlin, le langage qu’ils ont créé en 2010, et qui est en partie utilisé au sein même d’IntelliJ, est tout indiqué pour développer sur Android, on a quelques étoiles dans les yeux.

Nous ne rentrerons pas ici dans les détails des présentations [1], mais il y avait clairement quelque chose de magique dans la manière avec laquelle on assistait à la transformation du code Java en Kotlin, notamment grâce à des extensions prévues spécialement pour notre OS préféré [2].

Voir le lien github

Avant Kotlin, je trouvais toujours que j’avais des petites rondeurs
Voir le lien github

Avec Kotlin, je suis prêt pour la plage.

Et s’il est de bonne guerre que Jetbrains fasse clairement le forcing dans le monde entier pour nous persuader de la pertinence de leur langage [3], le nombre de speakers ayant choisi de présenter du Kotlin sur leurs slides plutôt que du Java était surprenant (Deezer, Novoda, Soundcloud). Comme s’il était désormais acté qu’une application Android puisse s'écrire en Kotlin.

Ce n’est pourtant pas la première fois qu’une alternative à Java est proposée pour faire du développement natif sur Android. Il y a déjà eu Scala. Il y a déjà eu Groovy, dont la possibilité d’interagir avec Android avait d’ailleurs été présentée ici même par Guillaume Laforge l’année dernière.

Ces alternatives ont toutes pour objectifs de palier aux principaux reproches faits au langage Java (et particulièrement Java 6 et 7, puisqu’il n’est pour l’instant pas possible de développer en Java 8 sur Android) :

• Trop verbeux
• Mauvaise gestion des null
• Lambdas non disponibles

Alors en quoi Kotlin peut-il avoir plus de succès que ses concurrents ?

Tout d’abord, pour son intégration dans Android Studio. En tant que développeur Android, nous maîtrisons notre outil, et celui-ci nous donne entière confiance en Jetbrains. Alors si Jetbrains nous assure que l’interaction entre le Kotlin et leur IDE est optimale, nous les croyons les yeux fermés. A titre d’exemple, il est d’ailleurs possible sur IntelliJ de convertir une classe Java en Kotlin en un clic. C’est un avantage certain sur Groovy, puisque l’on peut constater facilement à quel point la complétion est moins efficace sur les fichier Groovy qu’elle ne l’est sur les fichiers Java (lorsque l’on modifie les fichiers build.gradle).

Ensuite, pour le coût sur la taille de l’APK, qui a longtemps été considéré comme un frein à l’adoption d’un langage alternatif. La taille du jar qu’il faut embarquer dans l’APK pour Kotlin est de 900 ko. Pour Groovy ou Scala, les fichiers à embarquer font 5 Mo avant de passer à la moulinette Proguard, qui bien configurée devrait cependant réduire leurs tailles en conséquence (pour une taille finale avoisinant 1 Mo pour Groovy selon Guillaume Laforge). À titre de comparaison, certaines des librairies Android les plus connues sont aussi assez volumineuses (les jars du support-v4 et de rx-java font chacun 700 ko).

Au final, en 2015, lorsque l’on vise des téléphones Android version JellyBean (API 16) et supérieures, est-ce si dramatique que cela d’avoir une application qui fait 4,5 Mo au lieu de 3,5 Mo, si ça n’entache en rien le rendu et la fluidité ? Il est vrai que 1 Mo fois 10.000, 100.000 voire 1.000.000 ou plus d’installations pour les plus chanceux, cela a un coût pour notre planète. Mais sûrement pas autant que la climatisation. Et quand il s’agit de vouloir avoir un peu d’air frais en été, on y pense moins à notre planète, n’est-ce pas ? Alors oui, Kotlin est sûrement un luxe. Mais notre bonheur au quotidien n’a pas de prix.

Enfin, le contexte. La plupart des développeurs Android travaillent sur des projets avec leur homologues développeurs iOS. Ces derniers avaient également un langage vieillissant, et Apple leur a offert Swift, un langage tout beau, tout fonctionnel. Alors, c’est bête, mais on est jaloux. Nous aussi on veut un langage tout neuf. Nous aussi on veut découvrir les avantages d’un langage fonctionnel. Nous aussi on veut pouvoir caser “extensions de protocole” dans nos phrases pour épater la galerie. La plupart des développeurs iOS présents nous ont d’ailleurs confirmés reconnaître énormément la syntaxe de Swift en voyant du Kotlin.

Cerise sur la gâteau, Kotlin est le choix de notre Saint patron Jake, qui en fait d’ailleurs un plaidoyer très intéressant [4].

Aller, une petite réserve tout de même. Avec l'arrivée des nouveaux compilateurs Jack and Jill confectionnés par Google pour Android, dont une présentation a d'ailleurs été faite par Guardsquare [5], il est pour l'instant nécessaire que les fichiers Kotlin (.kt) soient d'abord transformés par Jill en .jayce, avant que Jack n'en obtienne un .dex. On perdrait alors sensiblement de l'intérêt du compilateur Jack qui est de transformer directement les fichiers .java en .dex, intérêt qui n'est toutefois pour l'instant pas si éloquent que cela si l'on en croit les chiffres annoncés par Guardsquare.

Alors chers clients qui nous lisez, rassurez-vous. Nous n’allons pas casser nos projets professionnels dès aujourd’hui pour passer à Kotlin. Mais beaucoup d’entre nous sommes ressortis suffisamment convaincus pour très vite tester ce langage sur des projets personnels. Avant de tout casser dès la semaine prochaine.

Le talk qui en impose

On savait que les employés de Soundcloud étaient doués [6]. Mais là, chapeau bas. Avec leur talk “Unidirectional data flow architecture”, plus d’un a été mystifié.

À l’origine, une douleur : la très grande difficulté à comprendre les comportements anormaux constatés sur l’écran affichant leur player audio, due au très grand nombre d’événements venant modifier cet écran (les gestures de l’utilisateurs, le flux audio lui même, ...).

Ils ont donc cherché une solution qui permette plus facilement de comprendre et de reproduire un comportement anormal remonté par des utilisateurs.

En surfant sur le renouveau de la vague des objets immuables, ils nous proposent une solution ultra innovante [7] basée sur des vues immuables.

Chaque évènement est traité un à un et déclenche la recréation à l’écran de la hiérarchie des vues dans son ensemble, au lieu de modifier un à un l’état de chaque vue présente à l’écran. Ils font cela en se basant sur l’extension Android de Kotlin, qui permet de déclarer des vues dans le code avec quasiment la même lisibilité que lorsqu’elles sont déclarées dans du XML.

Voir le lien github

Je vous ai déjà parlé de Kotlin ?

L’avantage incroyable de leur approche est que tout ce que l’utilisateur voit à l’écran est présent dans le code, et peut donc être loggé et affiché dans une stacktrace, avec la possibilité de le rejouer à distance.

L’inconvénient évident est que la création de vue reste parmi ce qu’il y a de plus coûteux sur mobile, et c’est la raison pour laquelle on les recycle et réutilise au maximum au lieu de les réinstancier. Mais ce n’est bien sûr qu’un prototype, et non pas le code de leur application en production.

Build

Il a également été question de Gradle, avec des talks assez intéressants, notamment ceux de Novoda et Genymobile. Quelques plugins ont été évoqués afin de vérifier les dernières versions disponibles des dépendances de ses projets [8], de pousser des versions sur le Play Store [9] et de mettre à jour les versions d’Android sur serveur d’intégration [10].

On a pu constater qu’il semble finalement assez facile de déclarer ses classes Groovy dans nos projets (en les plaçant dans un dossier groovy, situé au même niveau hiérarchique que le dossier src/main/java) et d’y faire référence dans le build.gradle. Cela permet de mettre plus de logique que dans son build.gradle, sans avoir pour autant à créer un plugin.

Car en effet, le retour d’expérience d’Eyal Lezmy [11] sur la création du plugin Gradle Genymotion nous a montré que la tâche n’était pas si évidente pour ceux qui veulent publier et rendre disponible leur plugin Android auprès de la communauté. En grande partie à cause de la documentation du plugin Gradle Android absente, pas à jour, ou pire, erronée (30% de la doc contiendrait des données fausses). La seule solution est donc de passer par le debugger, encore plus facilement depuis les tests, puisque l’on est encore dans le projet de son plugin. Et également à cause du plugin Android qui change les noms de ses tâches à chaque nouvelle version.

Quelques bons conseils ont été dispensés afin de rendre l’utilisation des plugins plus intuitive (via l’utilisation des extensions, des nested extension et name parameters). Et enfin, pour donner du feedback aux utilisateurs du plugin, le conseil est d’user et d’abuser des logs, et d’inclure les erreurs dans la documentation.

There is a better way

À Octo, nous sommes dans nos gènes convaincus de l’importance de produire du code de qualité, testé, intégré à des usines de développement [12]. Nous avons participé à répandre nos convictions auprès de la communauté dès le premier opus de la Droidcon Paris, et nous continuons de communiquer à ce sujet, avec cette année la présentation de Louis Davin sur les usines de développement Android dans le Cloud [13]. Alors, il est toujours aussi plaisant de constater l'engouement pour ces talks, sur la qualité de code, sur les stratégies de tests, sur le rappel des règles qui font du code de qualité.

Les conférences de Xebia et Deezer, ainsi que celle de Stan Kocken [14] détaillent très bien les enjeux des tests unitaires et des tests d'interface, et comment les mettre en place. Celle de Big Nerd Ranch explique comment réaliser et tester unitairement son propre plugin Lint, afin d'ajouter des warning jusque dans l'IDE sur les bonnes pratiques de développement.

De son côté, et après nous avoir déjà livré l'année dernière une très bonne présentation sur RxJava [15], Benjamin Augustin de Novoda s'est encore une fois distingué avec son talk parmi les plus convaincants de ces deux jours sur les raisons de s'intéresser aux langages fonctionnels [16], notamment dans le but de rendre son code davantage explicite. Et dans cette même logique, Xavier Gouchet de Deezer nous a montré comment faire les même tours de magie que ceux présents dans la plupart de nos librairies préférées, et ainsi créer nos propres annotations afin de s’éviter l’écriture de code boilerplate pénible et sans valeur [17]. Notons d’ailleurs que Jake avait lui même fait un talk sur ce même sujet [18], mais bien plus complexe et moins abordable que celui-ci. En effet, en utilisant AspectJ [19], il semble assez facile d’arriver à ses fins sans devoir comprendre tous les tenants et les aboutissants du processing d’annotation en Java.

Et l’UX dans tout ça ?

Et oui, c’est bien la grande perdante de cette conférence. À quelques trop rares exceptions près, on aurait vraiment pu se croire dans une conférence Java standard. Seul notre star nationale, Cyril Mottier, avec son intervention sur les techniques de scroll, s’attelle à prêcher cette sensibilité, qui fait pourtant parti intégrante de notre métier de consultant mobile.

Bien sûr nous sommes développeurs Java aujourd’hui, Kotlin ou autre demain. Et nous sommes plus que jamais fanatiques du code de qualité. Mais notre mission va au-delà. Et nous devons travailler en parfaite collaboration avec les designers pour cela. L’intervention de Geoffrey Dorne l’année dernière avait d’ailleurs fait salle pleine. Si l’on continue dans cette veine de conférences 100% tech, on risque de les faire fuir définitivement. Et j’en ai déjà mal à mon Droid.

Code testé, sourire assuré

Liens

[1] Pour ceux qui sont interressés par ce langage, testez ces tuto online [2] Extensions Kotlin pour Android [3] Le talk a déjà été présenté dans d’autres Droidcon, notamment à Berlin [4] Étude sur Kotlin de Jake Wharton [5] Présentation de Guardsquare sur Jack and Jill [6] Fernando Cejas, l’un de leur développeur phare, est un des auteurs les plus influents sur tout ce qui touche à l’architecture des applications Android (Model-View-Presenter,Dagger 2) [7] Projet Soundcloud sur Github [8] gradle-versions-plugin [9] gradle-play-publisher [10] sdk-manager-plugin [11] Slides de la présentation "Gradle Plugins: Take it to the next level" [12] Si vous aussi vous voulez nous jeter des fleurs [13] Article "Forces et faiblesses d’une Usine de Développement Android dans le cloud" [14] Slides de la présentation "Testez unitairement votre code, même votre UI !" [15] Slides de la présentation "RxFy All The Things!" [16] Slides de la présentation "Let's get functionnal" [17] Slides de la présentation "Aspect Oriented Programming" [18] Vidéo de Jake Wharton sur l'utilisation des annotations pour réduire le code boilerplate [19] AspectJ