Android Makers 2 : la conférence qu’il ne fallait pas manquer en France
Le lundi 23 et mardi 24 avril avait lieu la seconde édition de la conférence Android Makers à Paris. Une conférence qui a mis les petits plats dans les grands pour s’imposer comme la conférence Android à ne pas manquer en France. Je vais résumer dans cet article les sujets qui m’ont intéressés et que je vais mettre en place dans mes applications.
Android Architecture Components
Ce n’est pas une nouveauté : Lifecycle, LiveData, ViewModels, Room et Paging ont été annoncé à la Google I/O 2017.
Je cite ces 3 particulièrement car de mon point de vue ils améliorent grandement chacun à leur façon, et plus encore ensemble, la maintenabilité de l’application et le principe de la “separation of concerns”.
ViewModel : améliore la gestion de la configuration sur Android (changement d’orientation, langue, clavier…), est lié au lifecycle de notre Activity/Fragment et remplace le Presenter dans le modèle MVP
LiveData : Les habitués de RxJava connaissent bien le principe, ce composant permet d’observer les changements d’un objet dans le but de récupérer chaque nouvelle version. Très pratique lorsque l’on a un flux continu de données.
LifeCycle : Enfin une méthode efficace pour récupérer l’état du cycle de vie de notre Activity ou Fragment. On va pouvoir savoir de façon fiable lorsque notre activité est visible “Started”. On peut d’ailleurs très simplement en implémentant le LifeCycleOwner récupérer un cycle de vie sur n’importe quel objet (comme une View)
Il existe un tas de patterns pour l’architecture de son application comme MVP ou MVVM selon la taille des équipes et le niveau d’abstraction souhaité pour la maintenabilité et les tests. Chez 2 App à Z nous travaillons avec beaucoup de startups pour lancer leurs produits sur mobile et ensuite nous les aidons à recruter en interne pour la suite de leur développement. Il est donc très important que leur future équipe mobile puisse continuer le travail sur l’application rapidement et sereinement avec les pratiques répandus dans la communauté.
Une architecture simple et conseillée par Google est pour moi la bonne solution, ainsi les prochains développeurs seront déjà familiers avec la structure de l’application et auront accès à tout un tas de ressources si ce n’est pas le cas. Pour le moment j’utilise une architecture MVP avec Dagger 2 donc ViewModel avec Lifeycle et LiveData vient tout chambouler pour le meilleur !
Je trouve la documentation officielle assez fournie pour permettre de commencer leur intégration. https://developer.android.com/topic/libraries/architecture/adding-components.html
Kotlin Coroutines
Si vous n’utilisez pas encore Kotlin, n’attendez plus ! Intégrer Kotlin dans vos applications et apprenez en plus sur une fonctionnalité qui va vous changer la vie : les Couroutines ! J’ai commencé à les utiliser en décembre 2017 et je ne pourrai plus revenir en arrière.
Lorsque vous souhaitez effectuer des actions en dehors du Thread principal, très souvent pour des accès réseaux ou disque, vous avez une seule solution sur Android : utiliser un autre thread.
Pour cela on peut utiliser une AsyncTask, un Executor, des futures, RxJava ou manipuler l’objet Thread directement. Chaque solution a ses avantages et inconvénients mais aucune n’est vraiment simple à utiliser ou en tout cas lisible au premier coup d’oeil.
Une Coroutine est très simple à utiliser, lisible, performante et annulable. Son seul inconvénient aujourd’hui c’est que son interface est toujours sous le statut “expérimental” mais elle est totalement stable et utilisable en production et le risque de devoir modifier quelques méthodes en vaut totalement la chandelle.
Le guide officiel est une bonne lecture mais je vous conseille quand même de regarder avant la présentation officielle par JetBrains et les slides de Erik Hellman à Android Makers.
Button : Et si on l’implémentait correctement ?
Oui je parle bien du widget pour les boutons sur Android. Tout le monde l’utilise mais est-ce qu’on l’utilise correctement ?
Si vous modifiez le background de votre bouton directement en java, si vous n’utilisez pas ColorStateList ou un drawable (avec des insets si possible) pour le background alors cette présentation est faite pour vous !
Android Studio Layout Editor
S’il y’a bien un outil que je n’ai jamais aimé avec Android c’est l’éditeur d’interface. Ce petit onglet “Design” qui permet de créer son interface à la souris. Lent, bugs à répétition, preview non disponible, Views Customs non gérés, position non respectée… tellement de défauts à mes yeux que pendant des années j’ai utilisé directement l’éditeur XML (avec la preview sur le côté) et j’ai toujours été globalement satisfait.
Et puis sont annoncées les Constraint Layout à la Google I/O 2016 où il est fortement conseillé à l’époque, limite obligatoire, de passer sur l’éditeur pour les utiliser. Autant dire que cela ne m’avait pas motivé à essayer à l’époque, et quand je m’y suis finalement mis, ça ne fonctionnait pas correctement, je mettais tellement de temps à créer mon interface que j’ai très vite abandonné.
Mais lorsque Constraint Layout a atteint la version 1.0.2 en Mars 2017 la situation avait changé et l’éditeur est devenu plus ou moins utilisable (à 70% je dirai). De plus beaucoup de tutoriels étaient disponibles et ont facilité la compréhension de ce nouveau composant qui n’a strictement rien à voir avec tout ce que l’on a connu jusqu’ici, oui même RelativeLayout. Aujourd’hui je l’utilise sur mes applications et c’est un bonheur, d’ailleurs la lisibilité en XML a été grandement améliorée ce qui permet d’aller très vite sur des actions pas forcément simple avec l’éditeur (pourcentage d’une guideline, créer une chaîne groupée etc.)
C’est pourquoi je vous conseille la lecture des slides de Vadim Caen et Jerome Gaillard, 2 Googlers à Londres, qui présentent l’éditeur dans un cas réel et complexe.
Ainsi que la présentation par Nicolas Roard et John Hoford de la version 2 de Constraint Layout dont on aura plus d’informations à la Google I/O. Parmi les nouveautés déjà annoncées nous avons la création de Helper (comme les guidelines ou barriers mais entièrement personnalisable) et la gestion des états de notre layout (ConstraintLayoutStates), plein de belles choses en perspective !
Traitement d’image avec RenderScript
Disponible depuis Honeycomb, RenderScript est une librairie très puissante roposée par Google pour le traitement d’images. Si vous avez un designer qui aime le blur vous l’avez déjà très certainement utilisé.
Mais si vous souhaitez aller encore plus loin, notamment pour ajouter des filtres, améliorer la colorimétrie, redimensionner l’image etc. alors je vous invite à regarder cette excellente présentation de Quentin Menini.
RenderScript gère automatiquement la parallélisation et l’utilisation du GPU ou CPU. Il faut écrire son script en C mais les interfaces sont automatiquement générées par RenderScript pour l’utiliser en Java. De plus comme cette librairie utilise le NDK la gestion de la RAM est grandement améliorée ce qui permet d’éviter les fameuses OutOfMemoryError.
Android Vitals
Si vous regardez un peu votre application sur le Play Store vous avez probablement noté qu’une nouvelle section Android Vitals est apparue (avec l’excellent nouveau design) regroupant les ANR et plantages.
Ainsi nous avons maintenant des informations sur l’utilisation de la batterie (wakelocks et réseau) et l’affichage de l’interface : nous aurons des alertes en cas de dépassement des 16ms (60 fps) et des erreurs pour tout affichage qui dure plus de 700ms (correspondant très souvent à un blocage de l’interface).
Pour tester ce comportement, il est toujours conseillé d’utiliser StrictMode pour les builds de développement sur nos applications pour vérifier que nous ne faisons pas de traitement sur le stockage dans le thread principal. Un simple “getSharedPreferences(context)” est déjà une violation puisque cet appel va lire le XML des préférences stocké dans la mémoire disque du téléphone.
Android Vitals est amené à évoluer au cours des prochains mois mais ce n’est pas le seul outil que vous devriez utiliser, par exemple la taille de l’APK n’est pas prise en compte par cet outil mais vous pouvez l’analyser avec Android Studio (Build -> Analyze APK).
Pensez aussi au temps de démarrage de votre application, même si vous affichez un SplashScreen l’utilisateur n’est pas plus patient que vous. La méthode reportFullyDrawn() de la classe Activity est très utile pour vérifier à quel moment votre application est prête.
PNG ? JPEG ? WEBP ? Non Vector Drawable !
J’utilise encore les PNG dans mes applications pour les icônes pour un tout un tas de mauvaises raisons : veille application, designer qui fournit que les png, gestion de versions Pre-Lollipop…
Je dis mauvaises raisons car il est aujourd’hui très simple de passer sur Vector Drawable, alors oui il faut travailler avec votre designer sur ce sujet mais de toute façon vous devriez être en communication constante avec lui et l’aider pour l’export en SVG s’il n’a pas l’habitude (notamment parce qu’il travaille plutôt avec iOS).
En fait le seul vrai problème que l’on rencontre aujourd’hui c’est que certaines propriétés des SVG comme even-odd ne sont pas gérés sur Android, en tout cas sur des versions 21 à 24. Heureusement il existe des outils comme Shape Shifter et SVG to VectorDrawable Converter pour nous aider.
Bien évidemment beaucoup d’autres sujets ont été évoqués lors de cette conférence, je vous conseille tout particulièrement The State of Representing State, Kotlinify your Gradle ainsi que How Android Rendering Works to Provide Pixels on the Screen Faster than You Can Read this Sentence
Je vous invite à regarder les vidéos sur le compte Android Makers (disponible courant Mai) https://www.youtube.com/channel/UCkatLlah5weIpN23LqMgdT
En attendant les vidéos, la plupart des slides des conférences ont été regroupés ici : https://twitter.com/i/moments/988431696843493376
Et maintenant ? Google I/O 2018
La prochaine conférence Android Makers aura lieu au mois d’avril 2019 mais d’ici là on ne manquera pas de regarder les différentes conférences prévues comme la DroidCon London, Berlin, New York… et surtout la Google I/O qui commence ce 8 mai.
Nous savons déjà que l’on aura plus d’informations sur la version 2 de ConstraintLayout, j’espère aussi des annonces concernant Material Design 2, de nouvelles librairies pour nos interfaces, une meilleure intégration de la support lib avec Kotlin et comme toujours de belles surprises avec l’AR, la VR et Android Studio !
