Android Makers by Droidcon 2024 - Partie 1 : same, same but different

On connaît tous le dicton “Jamais deux sans trois”... Et bien côté practice Mobile, nous en sommes adeptes puisque nous revoilà une troisième année consécutive pour cette édition d’Android Makers by Droidcon 2024.

Si l’on devait jouer au jeu des sept différences, on pourrait se dire que rien n’a changé : toujours au Beffroi de Montrouge, avec des speakers.euses accomplis et des sujets très variés, une keynote d’ouverture avec le célèbre duo Chet Haase et Romain Guy… Enfin, non ! Cette année, Romain Guy se retrouve seul pour un talk de clôture (et pour ceux qui n’ont pas suivi, l’explication se trouve ici).

Toutefois, pour ne pas déroger à nos bonnes habitudes, nous vous avons concocté un petit panel récapitulatif des conférences les plus marquantes !

Un second article sera publié la semaine prochaine donc... stay tuned !

Rebranding de l’extrême : 3 mois pour tout changer !

Julie Gléonnec, Jean-Baptiste Vincey - Développeur.se mobiles pour Deezer - Les slides

Représentant Deezer, Julie Gléonnec & Jean-Baptiste Vincey nous ont proposé un talk pour nous montrer les coulisses d’un rebranding en 3 mois !
Pourquoi ce rebranding en 3 mois ? Deezer a souhaité faire de ce 7 novembre 2023 une date clé. Le lancement de cette nouvelle version de l’application est lié à une volonté de l’entreprise de se repositionner sur le marché, de rajeunir la marque et de renforcer son identité.

• J-127 (3/07)

Deezer est une application qui a environ 15 ans, il est donc nécessaire d’avoir un aperçu de l'étendue du travail à faire. Afin de l’évaluer, l’équipe a eu l’idée amusante de tout rebrander en … Barbie (couleur rose, font Comic Sans MS, icon unique) ! Afin de pouvoir identifier ce qui est en dur et ce qui ne l'est pas.

Les actions mises en place ont été de remettre de la cohérence et d’ajouter de la contextualité dans les couleurs (passage de 20 à + de 150).

• J-83 (10/08)

Il est maintenant venu le temps de l'idéation, des POC (Proof Of Concept) pour étudier la faisabilité de certains composants proposés avec un nouveau design.
La stratégie, dans un premier temps, pour limiter les risques, est de modifier la nature du composant mais sans en changer le style. Il sera appliqué dans un second temps.

• J-69 (31/08)

Préparation du pre-mortem : il faut savoir que les designs ne seront disponibles que demain et aucune bêta n’est possible. Les 4 points d’attention remontés et leurs solutions sont :
- Le changement de scope/priorité : manager par priorité;
- Des designs trop ambitieux : proposer des alternatives plus simples techniquement, pas besoin de pixel perfect;
- Les rushs de dernière minute : rien de prévu sur le dernier sprint afin de traiter les bugs remontés et/ou donner un petit coup de polish;
- Des assets pas prêts : réaliser des livraisons par bloc avec les icons les plus représentées en priorité.

• J-71 (1/09)

Les maquettes, enfin ! Il faut maintenant identifier les composants clés, du plus petit au plus grand. Exemple : les couleurs/fonts/icons, puis les boutons, puis le header, pour finir par des écrans complets.

La méthode de travail doit être elle aussi adaptée, avec le passage en Scrum Of Scrum. Un représentant par stack va alors assister aux réunions et ainsi laisser les développeurs tout leur temps pour être focalisés sur leurs développements.

Les 3 équipes (design, produit et technique) vont ainsi travailler ensemble afin d’aligner les priorités. Elles auront plus de flexibilité, et l’équipe technique plus d'autonomie.

Pour tester l'application rapidement, l’équipe est passée en Merge First, avec une publication quotidienne sur Firebase, et surtout disponible pour tous les collaborateurs.

Afin de faire cohabiter du Compose et du XML, les composants ont été encapsulés pour faciliter la migration.

• Jour J (7/11) et après

Le Jour J, c’est le lancement, en plus de l’application, il y a également le contenu éditorial, mais aussi les campagnes de pub.

La prise de risque de cette mise en production est réduite grâce aux outils de monitoring (Vitals, Crashlytics).

En bref :

• Rebranding = Design System
• Anticiper le pré-mortem
• Anticiper les modifications/améliorations techniques
• Prioriser ce qui a un maximum d’impact
• Adapter les processus (SoS, autonomie de développeurs)
• Livraisons continues en interne
• Utiliser des outils de monitoring

What if ADB does not have to be that complicated ?

Alessandro Mautone, Développeur mobile pour Canyon

Si je vous dis ADB (Android Debug Bridge), le terme doit vous être familier. Si l’on résume, il s’agit d’un CLI qui permet de communiquer avec le device connecté. Mais connaissez-vous les commandes qui pourraient vous être utiles ?

Alessandro nous propose de passer rapidement sur des commandes de bases qui permettent respectivement de lancer l’app, supprimer les données de l’application ou encore le fait de cliquer sur l’écran.

$ adb shell am start -n com.package.name/com.package.name.ActivityName
$ adb shell pm clear <application_id>
$ adb shellinput tap <x> <y>

Il mentionne également quelques commandes plus complexes en passant par uiautomator2. C’est un framework fourni par Android permettant d’exécuter des tests fonctionnels d’interface utilisateur de façon automatisée. Couplé à ADB, il nous permet, entre autres, de cliquer sur un élément en fonction du texte ou de son ID comme ici :

$ adb -s emulator-5554 shell uiautomator dump
$ adb -s emulator-5554 pull /sdcard/window_dump.xml ./
$ adb -s emulator-5554 shell input tap $(perl -ne 'printf "%d %d", ($1+$3)/2, ($2+$4)/2 if /text="Continue as a guest" [^>]*bounds="\\[(\\d+),(\\d+)\\]\\[(\\d+),(\\d+)\\]"/' ./window_dump.xml

On se rend vite compte qu’elles peuvent être complexes et intrinsèquement difficiles à retenir. Mais pas de panique, Alessandro a la solution : SimpleAdb. C’est un outil développé par ses soins en Python qui permet de nous affranchir de la mémorisation d’un grand nombre de commandes comme celles-ci.

En effet, grâce à son interface simpliste, on peut facilement enchaîner les commandes avec la possibilité de réutiliser les scripts générés. Et en plus, il est Open-Source alors n’hésitez pas à y apporter votre touche !

Composable dans les Vues : L’interopérabilité et la Confrontation des Cycles de vies

Mohammed Boukadir et Pierre-Emmanuel Altieri de chez BackMarket nous on partagé leur expérience et leur expertise sur la migration de leur Design System sur Compose dans un projet de plus de 200 modules (rien que ça) en mettant en lumière certains problèmes rencontrés et les solutions trouvées.

La méthode Scooby-Doo :

Voilà le nom qu’ils ont donné à la méthode qu’ils ont choisi d’utiliser pour leur migration. Cette méthode consiste à remplacer les implémentations des Android View par des Composables. Permettant ainsi une adoption progressive de Compose tout en préservant la compatibilité avec les vues existantes. L'un des défis majeurs mentionnés était donc celui de l’interopérabilité, c'est-à-dire rendre compatible des vues qui ne l'étaient pas initialement.

L'arrivée des problèmes :

Grâce à leurs outils de monitoring leur équipe a pu constater l’arrivée de certains problèmes comme :

• Des alertes “freezing frame” de Datadog.
• Des erreurs “out of memory error” de Crashlytics
• De mauvaises performances au scroll.

Pour déterminer l’origine de ces problèmes, divers outils ont été utilisés comme :

• Le GPU profiler
• Le CPU profiler pour trouver les “janky frame”
• Perfetto qui permet d'analyser les requêtes et les traces
  
  

On a donc pu voir que certains de leur Composables qui devaient seulement se “Recomposer” ne le faisaient pas mais en plus qu’ils se “Composaient” encore et encore.

Comprendre et résoudre :

Pour comprendre et résoudre ces problèmes, les présentateurs ont exploré le concept de ComposeView, qui est donc une View qui peut contenir des éléments Composables en utilisant la méthode setContent( ) pour fournir le composant à la vue. C’est donc une sorte de pont entre Compose et le monde traditionnel des vues Android. On a donc pu voir que l’origine des problèmes était donc liée aux cycles de vie des Composable et des ComposeView qui avaient lieu dans les RecyclerView et qui provoque la “Composition” des éléments à la place de leur “Recomposition”.

La notion de ViewCompositionStrategy a aussi été élaborée pour nous montrer les différentes façons qu’a ComposeView de disposer de ces Composables en fonction de la stratégie choisi parmis:

• ViewCompositionStrategy.Default
• ViewCompositionStrategy.DisposeOnDetachedFromWindow
• ViewCompositionStrategy.DisposeOnDetachedFromWindowOrReleasedFromPool
• ViewCompositionStrategy.DisposeOnLifecycleDestroyed
• ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed

Conclusion:

• Faire du monitoring c’est important pour détecter au plus tôt et au plus vite les problèmes rencontrés dans nos applications
• Remplacer les NestedRecyclerView directement par des listes Compose
• Éviter de supprimer les ComposeView depuis les ViewHolder
• Utiliser la bonne ViewCompositionStrategy

Boosting Compose UI from Sluggish to Snappy

Akshay Chordiya - Développeur mobile pour Tinder / Tasha Ramesh - Développeuse Mobile Pour Tinder

Akshay et Tasha nous ont présenté l’application Janky Tinder, une version de Tinder pour les chats. Cette application rencontrait des problèmes de lag au niveau de l’interface utilisateur (UI), en particulier lors des opérations de swipe et de drag des cartes.

Tout d’abord, Akshay et Tasha, ont utilisé la bibilothèque Jetpack Benchmark pour identifier et mieux comprendre les problèmes de frames rencontrés dans l’application.

> Petit tip: L’attribut semantics a besoin d’être seulement ajouté au Modifier du plus haut niveau (ex: Scaffold).

Pour mesurer les frames, FrameTimingMetric est la mesure utilisée.

Le benchmark permet de générer un fichier JSON et ce fichier contient des données sur les performances de l'application. En examinant la valeur de la variable frameOverrunMs dans ce fichier, il est possible de déterminer si les performances de l'application sont bonnes ou non.

• La valeur négative ou zéro veut dire que les performances sont bonnes.
• La valeur positive veut dire que les performances ne sont pas bonnes.

Dans le cas de l'application, la valeur positive de cette variable indiquait des problèmes de performance à résoudre.

Akshay et Tasha ont également utilisé Perfetto, un outil externe de profilage de performances qui permet de visualiser les événements système et d'application sous forme de timeline. Avec cet outil on peut comparer les timelines attendues et actuelles, mais également zoomer sur les composants pour plus de détails.

Suite à l’identification des problèmes, Akshay et Tasha essayent de les résoudre, et pour les résoudre ils se sont appuyés sur le compose performance book.

> Petit disclaimer: Le livre n’existe pas malheureusement 😢.

Ils ont rencontré des problèmes avec les Modifiers, les States et les Listes.
Après avoir identifié les problèmes de performance dans l’application, Akshay et Tasha ont utilisé le Layout Inspector pour analyser les recompositions. Bien qu'ils aient constaté que les attributs du composant étaient présents dans le Modifier, ils n'ont rien trouvé de particulièrement surprenant ou alarmant. Cependant, ils ont remarqué que le nombre de recompositions augmentait de manière inquiétante, ce qui indiquait un problème de performance à résoudre. En consultant “le livre”, celui-ci indique que la solution est les Modifier lambda. Pour mieux comprendre pourquoi les Modifier lambda résolvent ce problème, Akshay et Tasha nous ont expliqué comment les re/compositions fonctionne avec le schéma suivant :

Le problème rencontré est que lorsque l'on passe une valeur dans un attribut du modifier, celui-ci étant immutable, il déclenche une nouvelle composition dès que la variable change. Cela entraîne un cycle de composition complet. A l'inverse, l'utilisation de modifiers lambda permet de retarder ce comportement et de reprendre à partir de l'étape de layout.

En consultant le Layout Inspector, Akshay et Tasha ont constaté que le nombre de recompositions pour la carte était correct. Cependant, ils ont également remarqué que la fenêtre entière était recomposée, alors que seule la carte aurait dû l'être. Le problème rencontré était que la fenêtre avait un State contenant des informations sur celle-ci, telles que le chat, l'index de la page, etc.

Cependant, la recomposition de la fenêtre était déclenchée pour tous les changements effectués sur le State de celle-ci. En cherchant une solution dans le fameux livre, Akshay et Tasha ont découvert que l'utilisation de derivedStateOf permettait de créer un nouvel State, de sorte que le changement de fenêtre soit indépendant du reste.

Pour résoudre le dernier problème rencontré, Akshay et Tasha ont constaté des recompositions sur un composant qui prenait une liste en paramètre. Cette fois-ci, ils n'avaient pas de solution immédiate en tête, ils ont donc décidé de lancer la commande ./gradlew assembleRelease -PenableComposeCompilerReports=true --rerun-tasks et ajoutant le code suivant dans leur build.gradle. Cette commande a généré un fichier contenant des informations détaillées sur leurs composants, telles que la façon dont le compilateur les voit.

Les résultats générés par la commande ont révélé que List est un unstable Param. Cependant, en consultant à nouveau le livre, Akshay et Tasha ont trouvé une solution à ce problème. Il était recommandé d'utiliser des collections immutables.

Cette présentation a permis de comprendre que les étapes pour optimiser nos composants sont toujours les mêmes.

En suivant ces étapes et en utilisant les outils appropriés, il est possible d'identifier les problèmes de performance et de trouver des solutions pour améliorer l'expérience utilisateur globale de nos applications.

En suivant les étapes d'optimisation et en utilisant les outils appropriés, il est possible de générer et de comparer facilement les résultats avant et après les changements. Cela permet à tous les membres de l'équipe de visualiser les améliorations apportées et de constater les différences en termes de performances de l'application. En refaisant la première étape après les changements, il est possible de mesurer l'impact des optimisations et de s'assurer que les performances de l'application ont été améliorées de manière significative.

Comment transformer son téléphone en terminal de paiement

Alfred Bourély - CTO & co-founder @Yavin

Comment lire une CB avec son Android ? Comment fonctionnent les réseaux de paiement Visa et Mastercard ? En quoi un terminal de paiement Android diffère d'un smartphone Android ?

Avec l’ensemble des fonctionnalités embarquées dans l’ensemble des smartphones, il pourrait paraître tentant de se dire qu’il est relativement aisé de pouvoir utiliser n’importe quelle plateforme pour pouvoir lire une carte à puce…  et la vérité est que c’est tout à fait facile…
Une simple recherche sur Github vous permettra de trouver nombres de manières de faire.
Prosaïquement, la puce NFC du terminal de paiement (ou dans notre exemple de la plupart des smartphones) va pouvoir émettre un minimum d’énergie électrique permettant d’activer sur la puce de la carte un micro-programme très peu gourmand qui valide le paiement.
Bien évidemment ce n’est pas là que se situe la difficulté mais dans la chaîne de paiement qu’il faut mettre en place avec le réseau bancaire (européen en ce qui nous concerne) par l’intermédiaire du réseau EMV (Eurocard, Mastercard, Visa) dont le fonctionnement est naturellement hautement sécurisé (encryption) et dépendant de certifications et sécurités tant hardwares que softwares.
D’autre part, sur les TPE, il existe une clé (hautement) sécurisée permettant l’encryption et l’accès au réseau bancaire qui se détruit à la moindre tentative d’intrusion qu’elle soit logique ou physique (même une chute accidentelle peut la provoquer).

En quoi un téléphone va-t-il différer d’un TPE :

• Par définition, un téléphone n’a pas la possibilité de lire la carte (physiquement que ce soit la puce ou la bande magnétique) donc le code PIN “Online” devient obligatoire. Il s’agit d’une nouveauté en Europe qui nécessite toutefois une validation de la banque émettrice sécurisée par encapsulations successives.
• La sécurité du device est déportée sur le logiciel de paiement (pas de root possible, mode développeur désactivé, pas d’ADB (Android), encapsulations afin d’éviter d’avoir des logiciels tiers ou espions capables de “sniffer” les échanges et interactions.
• Même si les puces NFC sont globalement de bonne qualité, il peut exister des disparités entre les constructeurs générant des résultats variables ce qui n’est évidemment pas acceptable.

C’est bien tout ça mais à quoi ça sert ? La certification du hardware n’est plus nécessaire :

• Le service de paiement par carte est accessible à tous dans un cadre principalement professionnel, car à titre privé des solutions existent déjà (PayPal, Lydia, PayLib, Lyf ou Apple/Google Pay par exemple).
• Le coût du hardware baisse drastiquement (et la qualité augmente).
• De nouveaux types de terminaux apparaissent (caisse sans TPE, borne sans PinPad).
• Plusieurs types d’intégration possibles sur les téléphones (de l’APK basique au SDK complet qui nécessitera en revanche des certifications bancaires)

La seconde partie de l'article arrive bientôt ! ;-)