Nous sommes allés le 25 et 26 avril derniers à Paris pour assister à Android Makers 2022, l'un des plus gros événements mobiles français. Cette année, ce sont plus de 600 participants qui ont pris part à 60 conférences. Etaient présent des speakers de grandes entreprises tech, comme Google (bien évidemment), mais encore Dashlane ou Deezer. Nous sommes venus nombreux pour représenter une partie de la Practice Mobile Ippon (Morgane Decugis, Audrey Lebret, Willy Rouvre, Julian Clemot, Florian Fagniez, Thomas Boutin, Vincent Nadir Hassouna et Yannick Jacqueline) :

Nous profitons de cet article pour vous présenter les sujets que nous avons préférés :

Why Projects Succeed: Lessons Learned from the Android OS par Romain Guy et Chet Haase

Non, Android n’est pas né de Google, et Android n’était initialement pas orienté téléphones… Le projet Android est né en 2003, à l’initiative d’une société éponyme, dans le but de créer un système d’exploitation révolutionnaire pour les appareils photos numériques.
Le virage de la téléphonie tel qu’on le connaît actuellement a été pris 2 ans plus tard suite à différentes levées de fond, dont celle de Google.
La première version d’Android fût annoncée courant 2008 avec le premier terminal dédié, T-Mobile G1.

Les clés du succès ?

• vision : projet open source, facilitant l’intégration des constructeurs de téléphones avec un store d’applications ; ambitieux mais nécessaire pour garantir le succès ;
• good team : une équipe de développeurs pluridisciplinaires, portée par un objectif fort, et adepte des “crunch time” ;
• luck : la chance, et la malchance, sont des composants essentiels d’un projet
• competition : les révolutions apportées par l’iPhone n’ont fait que renforcer Android : il fallait proposer un concurrent au smartphone d’Apple. Les constructeurs historiques avaient besoin d’une solution efficace pour ne pas être dépassés.

Ce talk d’ouverture a repris les concepts du livre Androids: the Team That Built the Android Operating System

Le Twitter de Romain Guy
Le Twitter de Chet Haase

The definitive guide to Android library par Jeroen Mols

Sur Android, la création de bibliothèques n’est pas ce qui est le plus simple. Cela se complique dès le départ. En effet, le générateur de projet d’Android Studio ne contient pas d’exemple de bibliothèque. Pour la créer, il faut d’abord initier un squelette d’application. Il faut ensuite créer un module et enfin sélectionner "Android Library".

Jeroen maintient le SDK de Plaid (https://plaid.com/en-eu/). Pendant la présentation, il nous présente le développement semé d’embûches de son outil.

Entre autres, nous comprenons que le déploiement d’une bibliothèque multi-module est un véritable chemin de croix. La gestion des dépendances transitives est quant à elle un enfer.
Fort heureusement, il nous confie aussi des clés et des stratégies pour s’épargner de longues heures de labeur.

En résumé, Jeroen nous a donné un petit manuel de survie. Un indispensable pour se lancer dans l’aventure de la publication de votre propre bibliothèque Android !

Son Twitter
Les slides de la présentation

Where and how to run UI tests? par Alexey Bykov

Depuis la création des Android Architecture Components, et plus largement depuis la création de Jetpack, développer sur Android est devenu de plus en plus simple.
Créer et maintenir des tests UI, qui sont exécutés sur un émulateur ou un téléphone, a aussi été simplifié. Par contre, de grosses contraintes subsistent.

Parmi elles, Alexey cite Androidx Test Orchestrator. C’est une amélioration significative des tests UI puisque cet outil offre une manière d’avoir de l’isolation entre chaque test.

Test Orchestrator vient par contre avec un coût assez élevé : l’installation de deux apk (test services + orchestrator en tant que tel). Il ne faut pas oublier qu’on exécute déjà deux apk pour nos tests UI : une pour l’application et une pour les tests.

Au-delà de ça, Alexey résume bien pourquoi ce type de test a tendance à être flaky, c’est-à-dire fragile et sujet à des plantages aléatoires. On pensera aux couches additionnelles qui sont traversées : réseau, stockage, accès aux équipements du téléphone…

Il nous donne finalement des solutions concrètes et pragmatiques pour améliorer la robustesse et l’efficacité de ces tests. Par exemple, Marathon est un runner de tests communautaire qui est autrement plus complet que celui de base.

Au global, Alexey nous a montré comment essayer de se réconcilier avec des tests qui sont absolument nécessaires, mais si douloureux à écrire et à maintenir.

Son Twitter
Les slides de la présentation

Untangling Coroutine Testing par Márton Braun

Avec les coroutines, les développeurs Android possèdent des outils puissants pour mieux gérer la concurrence au sein de leurs applications. Mais tester ces coroutines n’est pas forcément une partie de plaisir.
Google, à travers Márton Braun, a profité de la tenue d’Android Makers pour dévoiler une nouvelle version de la librairie kotlinx-coroutines-test. Avec cette version 1.6.0, la librairie apporte de gros changements :

• La méthode runTest permet d’offrir un Scope de test prêt à être utilisé directement
• TestDispatcher arrive avec deux implémentations spécifiques aux tests :
  • StandardTestDispatcher : Ce dispatcher permet de mieux maîtriser l’avancement et le lancement des coroutines au sein du Thread de test. Le développeur doit explicitement demander à avancer dans le temps pour exécuter ses coroutines. L’utilisation de ce dispatcher est recommandée si le code testé exploite au mieux les possibilités de parallélisme des coroutines ;
  • UnconfinedTestDispatcher : Au contraire du StandardTestDispatcher, celui-ci lance automatiquement dans le Thread courant les coroutines lancées au sein du scope. Il en résulte un peu plus de simplicité quant à l’exécution du test mais n’est potentiellement pas fidèle au comportement d’une coroutine en production ;
• La possibilité de remplacer plus facilement le Main Dispatcher au sein des tests, celui-ci n’étant pas disponible de base.

Bien entendu, ce lot de nouveautés engendre un gros travail pour les développeurs, car qui dit nouvelle version majeure dit aussi breaking changes et donc migration potentiellement compliquée.
Enfin, l’avenir nous dira si cette version de la librairie permettra réellement de faciliter le testing des coroutines et surtout d’apporter un standard applicable chez les débutants comme chez les plus confirmés.

Pour aller plus loin, n’hésitez pas à regarder le guide du testing de coroutines et le guide de migration de la lib kotlinx-coroutines-test.

Son Twitter
Les slides de la présentation

Petit guide de mise en place d'une CI pour Android avec Github Actions par Titouan Thibaud

Dans ce talk, Titouan THIBAUD, développeur mobile à Innovorder, nous présente un petit REX sur la mise en place d’une CI mobile avec des Github Actions.

Son équipe avait hérité auparavant d’une CI faite à partir de Google Cloud Build, mais cette première solution n’était pas facilement maintenable et n’avait pas été bien documentée par l’équipe précédente, le choix d’une nouvelle solution de CI s’est donc imposé. D’autres équipes utilisant les Github Actions, il a donc été plus simple pour eux de la mettre en place pour les projets mobiles.

A travers son talk, Titouan nous fait donc une initiation en nous présentant notamment les notions de workflows, de jobs, d’actions, de steps ou de runners. Il nous présente aussi les différentes étapes pour automatiser les tests, pour builder et publier une application Android sur les stores, tout en étant notifié des différentes étapes sur Slack.
Un autre élément important de Github est le Marketplace très bien fourni en Github Actions permettant d’automatiser tout type de tâches.

Au final, même si la prise en main et la mise en place peuvent être plus difficile (car l’ensemble de la configuration se faisant via des fichiers yml), le contrat est rempli car il a pu diviser ses temps de build par 2 par rapport à Google Cloud Build, et diviser le prix de build par 10, tout en améliorant la fiabilité.

Son LinkedIn
Le lien vers son article Medium

Retour d'expérience sur React Native dans Pl@ntNet par Hugo Gresse

Dans ce talk, Hugo Gresse, ingénieur mobile à l’INRIA, nous fait un retour d’expérience sur le framework React Native au travers du développement de l’app mobile Pl@ntNet. Cette application permet notamment d’identifier et de classifier des plantes à travers le monde, sous forme de projet participatif.

Hugo nous présente ainsi les différents avantages de React Native, comme les performances relativement bonnes ou encore la rapide prise en main si nous venons du monde du web. On peut ajouter à cela la possibilité d’utiliser des éléments de React JS comme Redux, Axios ou encore Jest.

Cependant, React Native reste perfectible de par ses différences de rendus entre les plateformes iOS et Android, ce qui oblige le développeur à utiliser des traitements différents. Aussi, beaucoup de fonctionnalités ne sont pas inclues par défaut dans React Native (comme les permissions ou la prise de photo par exemple), et obligent à installer beaucoup de dépendances, entraînant rapidement une dette technique non négligeable, malgré le fait que la communauté soit très importante et propose des mises à jour pour les librairies les plus connues (même s’il reste encore des bugs pour react-native-maps ou pour l’utilisation de la caméra sous Android).

Enfin, un dernier élément en défaveur de React Native est le fait que la fréquence  des mises à jour est faible (environ 4 mineures par an), et chaque mise à jour demande un travail conséquent pour maintenir son application.

Au final, React Native reste un framework intéressant de par sa rapide prise en main, sa rapidité pour développer une app mobile ou encore sa communauté  relativement importante. Cependant, Hugo nous conseille plutôt le framework Flutter pour démarrer de nouveaux projets mobiles cross-platform.

Son Twitter
Les slides de sa présentation

The Adventures of Kotlin And Compose Through the Multiplatform World par Carlos Mota

Est-il possible de réaliser une application native et déclinable sur différentes plateformes à l’aide de Kotlin ?

C’est à travers son talk que Carlos Mota nous emmène à l’aventure pour nous faire découvrir le monde merveilleux de Kotlin et Compose Multiplatform et répondre à cette question.

Dans un premier temps, Carlos nous présente les concepts de Kotlin Multiplatform dont le but est de partager le code métier pour différentes plateformes (en Kotlin) mais laisser au développeur le soin de développer son UI nativement pour chacune d’elles. Il en profitera également pour nous partager les différents outils et frameworks utilisables lors du développement d’une application multiplateforme (réseau, base de données, injection de dépendances …).
Son périple nous emmènera ensuite sur la route de Compose Multiplatform, un framework réactif basé sur Jetpack Compose permettant le partage de code UI pour une application Android, Desktop et Web. C’est par le développement d’un exemple applicatif que notre aventurier va tenter de réaliser une application Android, Desktop, Web et iOS à l’aide d’une seule base de code réalisée en Kotlin.

Si la réalisation de l’application Android à l’aide de compose s’est faite sans problèmes, il s’est cependant confronté à quelques difficultés concernant la version Desktop et Web du framework tandis qu’il a pu constater que la version Compose d’iOS n’en était qu’à ses débuts.

Un talk très intéressant si vous êtes intéressés par le monde du développement multiplateforme et si vous cherchez une alternative à Flutter et React Native.

Son Twitter
Les slides de sa présentation

L’accessibilité c’est pas sorcier par Fanny Demey et Gérard Paligot

Fanny Demey et Gérard Paligot jouent les Jamy et Fred avec un talk très bien amené pour nous faire prendre conscience de l’impact de l’accessibilité, nous montrer les principales erreurs commises ainsi que nous expliquer comment les corriger.

Ce talk permet à chacun de se mettre dans la peau d’un utilisateur  atteint de cécité et de prendre conscience des différents axes d’améliorations possibles dans le code pour offrir une meilleure expérience à ce type d’utilisateur.
Afin de se rendre compte, pour nous “valides”, de la difficulté d’utiliser une application peu accessible, une personne du public s’est portée volontaire, a eu les yeux bandés et a tenté d’utiliser l’application prévue pour ce talk. Le but était de commander 3 paquets de flocons d’avoine.

Plusieurs difficultés ont été mises en lumière :

• L’affichage des images : il est important de mettre une description claire sur chaque image. Si l’image n’est pas indispensable, il faut alors la rendre invisible pour le TalkBack ;
  Exemple pour l’image du paquet de flocons d’avoine : “Paquet Flocon d’avoine - 350g”, la description ne doit ni être trop généraliste (“Image produit”), ni trop détaillée (“Paquet Flocon d’avoine - 350g, ce produit est riche en fibre [...]. nutriscore B, provenance, etc.”) ;
• L’affichage des informations : chaque produit comporte une note sur 5 ainsi que le nombre de commentaires sous cette forme “4,5/5 (42)” mais le TalkBack va lire “quatre virgule cinq cinquième” et “quarante deux” ce qui n’a pas de sens pour un déficient visuel. Il faut donc reprendre et préciser ces 2 informations pour qu’elles soient claires les yeux fermés ;
• Le regroupement d’informations : pour le plaisir des designers, on doit parfois, comme ici, décomposer le prix en plusieurs composants (2€99 -> 2 puis € puis 99 pour obtenir 2€99). Mais à la lecture, on a 3 focus différents ce qui rend le prix illisible. Il faut donc placer le focus sur un élément les regroupant et ajouter un label citant le prix d’une seule traite ;
• L’information après le clic sur un bouton : pour ajouter (ou enlever) un paquet à sa commande, l’utilisateur doit cliquer sur le bouton +. Mais les yeux fermés, comment peut-on savoir si le clic a été pris en compte et que l’on a bien ajouté 1 paquet (et non 4) à notre commande ?! Il faut que le TalkBack puisse ainsi énoncer à l’utilisateur le nombre de paquets commandés après chaque action (ajout ou suppression).

Les points positifs de ce talk :

• Le fait d’avoir mis en lumière l’importance d’utiliser correctement certains éléments présents dans le code pour améliorer l’accessibilité tels que l’attribut contentDescription à renseigner sur certains éléments graphiques d’une application Android ;
• Un talk animé et interactif permettant une meilleure sensibilisation sur le sujet ;
• L’utilisation de Compose et des correctifs intéressants à suivre.
  

Un talk de 45 min très bien construit et instructif à la portée de tous les développeurs !

Le Twitter de Fanny Demey
Le Twitter de Gérard Paligot
La documentation Android sur l’accessibilité

.NET MAUI : Mais c’est quoi ce truc ? par Edouard Marquez

Les solutions cross-platform telles que Flutter ou React Native ont le vent en poupe. Toutefois, la solution proposée par Microsoft, Xamarin, semble sur le déclin. Dans son talk, Edouard Marquez nous a présenté le tout récent framework open source .NET MAUI.
Son nom tient pour : “.NET Multi-platform App UI”. Il permet en théorie de développer en C# et xaml avec une seule base de code pour déployer des applications sur Android, iOS, Windows ainsi que MacOS.

Or, il semble qu’en pratique quelques difficultés subsistent :

• L’utilisation de Visual Studio n’est pas encore supportée sur Mac, il faut donc se contenter de le faire en ligne de commande ;
• Sur Windows, il faut se connecter à un Mac (à distance) pour espérer faire compiler son application MacOS ;
• Sur Mac, on ne peut tout simplement pas lancer l’application côté Windows.

Concernant l’arborescence d’une application, il n’y a qu’un seul projet avec toutes les cibles.

Au niveau du code, tout se fait en C# et en xaml. Il est dommage de ne pas avoir opté pour une solution déclarative pour la partie UI. Ajoutons à cela la présence très utile du hot reload qui nécessite cependant encore quelques améliorations pour être complètement opérationnel (problème de resizing de la vue).

En somme, ce framework s’adresse davantage aux anciens développeurs Xamarin ou ceux familiers avec le .NET/C#. N’étant encore qu’à l’état de release candidate, il n’est pas recommandé de l’utiliser pour des projets d’entreprise. Néanmoins, il est possible d’en tester les limites en projet personnel.

Son Twitter
Les slides de la présentation

Et maintenant ?

Être développeur Android, c’est désormais évoluer dans un écosystème où il fait bon vivre. La promotion d’un langage moderne pour sa plateforme (Kotlin) et la refonte du Kit UI (Jetpack Compose) sont deux témoins de cette volonté d’aller vers l’avant !

Merci aux organisateurs, aux speakers, aux bénévoles et aux sponsors pour cet événement ! Voir et participer à l’émulation de la communauté Android, c’est aussi ce qui nous anime. Les replays des conférences seront disponibles prochainement sur YouTube.

Et pour les aficionados d’iOS, nous vous donnons rendez-vous en septembre au French Kit, l’un des grands rendez-vous de la communauté iOS !