Et nous y voilà, les adeptes Android de la Practice Mobile qui ont répondu présents à l'édition 2025 d'Android Makers qui s'est déroulée le 10 & 11 avril derniers.
Et puisqu'on garde la même recette, voici un petit florilège des quelques talks qui ont retenu notre attention.

Une seconde partie arrivera bientôt ;-)

Using the Android Context and Manifest to unveil the Android System  

par Ioannis Anifantakis

Dans cette conférence, Ioannis, venu spécialement de Grèce, vient éclairer notre lanterne sur le sujet du Context en Android, souvent vu comme un élément mystérieux et pourtant indispensable au fonctionnement de notre application. Ioannis cherche aussi à clarifier le fonctionnement et l’importance du bien connu AndroidManifest.xml. L'objectif de ce talk était de fournir une compréhension conceptuelle, en évitant les détails trop techniques.

Il commence alors par expliquer le processus d'installation d'une application. Sans entrer dans les détails, sur l’OS Android, chaque app reçoit un identifiant utilisateur Linux unique et s'exécute dans sa propre instance isolée. Cette isolation, bien que sécurisante, crée une contrainte : les applications ne peuvent pas construire leurs propres composants et doivent s'en remettre au système Android. Mais alors une question se pose ? Comment une application fait-elle pour communiquer avec le système Android, et vice-versa ?

Face à ce défi, notre conférencier a introduit le duo Context-Manifest. Le Context permet à l'application de communiquer avec le système, tandis que le Manifest (AndroidManifest.xml) sert de "registre" où sont déclarés les informations de package, les permissions requises et les quatre types de composants : Activity, Service, Content Provider et Broadcast Receiver. Ainsi, le Manifest sert à notifier le système Android de l’existence dans l’app l’un de ces composants et donc recevoir les communications venues de l’OS. À l’inverse, le Context, classe abstraite, sert de pont de communication avec Android, pour effectuer telle ou telle action.

Ioannis a poursuivi avec les Intents, mécanisme permettant de demander au système de lancer des composants. Qu'ils soient explicites ou implicites, ces Intents utilisent le Context comme intermédiaire principal et permettent d’activer ou non certains composants. Il présente ensuite une classification des composants Android : lorsque certains héritent du Context (Activity, Service, Application), d'autres ne le font pas (Content Provider, Broadcast Receiver). Les premiers suivent le cycle de vie Android, les seconds utilisent simplement le Context pour leurs opérations.

En rentrant un peu plus dans le détail sur la notion de Context, Il détaille alors la définition officielle de Google et en explique chaque partie : 

• Une interface d'information sur l'environnement d'une application (thème, orientation, préférences)
• Une classe abstraite dont l'implémentation est fournie par le système (les instances concrètes sont les Activités, Services, Application)
• Un moyen d'accéder aux ressources spécifiques de l'application (gérées par le système)
• Un outil pour effectuer des opérations au niveau de l'application (lancement d'Activités, diffusion d'événements) en s'appuyant sur le Manifest

Le Context possède alors trois grands rôles : 

• Rôle passif : comme une fenêtre pour accéder à une ressource.
• Rôle actif : pour lancer un composant ou un événement.
• Rôle de liaison : pour maintenir une connexion ouverte (comme avec une base de données).

L'analogie d'un tableau de commutation a été utilisée pour visualiser le Context, reliant les composants de l'application au framework Android via le Manifest (la "prise") et le Context (le "câble"). L'évolution vers l'architecture Single Activity Architecture et l'utilisation de Jetpack Compose ont également été abordées, soulignant que même si la structure change, le Context reste fondamental. Bien que son accès puisse être moins direct (via LocalContext dans Compose), il n’en reste pas moins extrêmement important. Le cycle de vie des Composables dans Compose est géré séparément de celui de l'Activité, mais ils interagissent via le LocalLifecycleOwner.

Ioannis termine sa présentation en insistant sur le fait que le Context est ce qui transforme un ensemble de librairies en une véritable application Android. C'est l'intermédiaire indispensable pour interagir avec le système d'exploitation. Ce talk nous permet de mieux comprendre comment le Context est la “glue” de notre application et nous fait réfléchir sur notre usage de celui-ci. Si vous voulez en savoir plus et faire un deep dive un peu plus technique, n’hésitez pas à consulter son article sur son site.

UX & Accessibilité cognitive : et si vous simplifiez vraiment l’expérience utilisateur ?

par Marie Benoit

Parmi les 12 millions de personnes en situation de handicap en France, 80% ont des handicaps invisibles.
Parmi les handicaps invisibles, on trouve les handicaps psychiques (ex : burn out), mentaux (ex : trisomie 21) et cognitifs (ex : TDAH)
Les fonctions cognitives atteintes peuvent être : la mémoire, le langage, le raisonnement, l’apprentissage, l’intelligence, la résolution de problèmes, la prise de décision, la perception et l’attention.
Les 5 principes fondamentaux : la clarté visuelle, la simplicité linguistique, la prévisibilité, l’adaptabilité et la multimodalité

Exemple de mauvais élève : Leclerc Drive

• L’écran propose une recherche alors que l’utilisateur est finalement renvoyé vers la création de compte

Exemple de bon élève : Super U

• L’écran propose de créer un compte et renvoie bien vers ce sujet
• Les étapes de la création de compte sont clairement indiquées et découpées 
• Les consignes sont claires

Les points d’attention sur le design sont : la surcharge cognitives, la hiérarchisation de l’info, faire simple et lisible, la gestion du clavier, la prévisibilité et constance ainsi que des labels qui font du sens.

Les outils et ressources à notre disposition : il ne faut pas compter sur les simulateurs … trouver des personnes en situation de handicap et former les équipes

Il faut faire de l'accessibilité un processus continu, l’intégrer dès la phase UX/UI, mais aussi dans le Definition Of Done. La création d'un rôle “d’accessibility master”, de collaborer avec des experts en accessibilité et d’avoir des retours utilisateurs sont également des points importants.

Grâce à son expérience auprès de personnes ayant des besoins spécifiques cognitifs, Marie Benoit a sû mettre en avant un type de handicape invisible, pas toujours facile à prendre en compte lorsqu'on y est pas directement confronté, et qui ne sont pas directement identifiés dans les critères d’accessibilité.

Comment développer une approche Frontend de l'éco-conception : le Soft Disabling

par Vincent Offroy

Contexte

Vincent est développeur Android chez Leboncoin, depuis plusieurs années. L’application est activement maintenue : plus de 30 développeurs mettent en production chaque semaine leur travail.
Cette plateforme de petites annonces est le deuxième site français après Amazon. Un français sur 2 la visite tous les mois. En conséquence, le serveurs traitent un énorme trafic entrant : de l’ordre de 20 millions de requêtes par mois rien que pour l’affichage des dernières annonces.
C’est sur cette fonctionnalité qui est au cœur du talk de Vincent. En effet, les six dernières annonces sont affichées sur la page d’accueil de l’application. Il est impossible de mettre en cache les appels back correspondant par souci de fraîcheur des données. Vincent et ses collègues se sont alors demandés comment optimiser l’envoi de requêtes pour cette fonctionnalité, sans pour autant la supprimer.

Sobriété fonctionnelle vs rentabilité business

C’est une bonne pratique de mesurer via de l’analytics l’usage des fonctionnalités d’un produit. Par exemple, dans le cas où elles sont peu utilisées, cela permet d’envisager leur suppression. Garder un nombre restreint d’usages dans son produit aide à la maintenance et simplifie son utilisation. Malheureusement, il y a toujours des utilisateurs niche qui en dépendent. C’est cette opposition sobriété vs rentabilité qui complique la suppression, conduisant naturellement au statu quo.

En analysant les affichages des dernières annonces, Vincent a observé que 98% d’entre eux n’étaient pas suivis par une interaction utilisateur. En d’autres termes, 98% des appels au serveur étaient gaspillés.

Le soft disabling consiste à désactiver une fonctionnalité lorsqu’un utilisateur n’interagit pas de manière répétée avec elle, tout en lui laissant la possibilité de la réactivé.

Implémentation 

Côté implémentation, le principe était simple : 

• Incrémenter un compteur à chaque fois qu’un affichage n’est pas suivi d’interaction
• Le réinitialiser s’il y en a une
• Au bout d’un certain seuil désactiver la fonctionnalité. Un composant toggle la remplace, expliquant pourquoi la fonctionnalité est cachée. À l’activation du toggle les annonces sont à nouveaux affichées et le compteur est remis à zéro. Une bottom sheet accessible via un lien dans le composant donne une explication plus complète sur le pourquoi de la désactivation.

L’enjeu suivant était de déterminer la valeur de seuil à affecter : 

• un seuil trop bas conduirait à des désactivations plus rapides et à une meilleure économie de requêtes
• l’inverse conduirait à potentiellement aucune désactivation, et donc aucune économie

En se basant sur de l’analyse comportemental d’utilisateurs, Vincent et son équipe ont créé plusieurs groupes d’A/B testing, et suite à une phase pilote ils ont généralisé un seuil de 30.

Résultat

Là où auparavant les appels sur android représentaient 55% du trafic total de leboncoin (en comptant web et iOS), le soft disabling a fait baisser le pourcentage à seulement 18% !

Aucun impact sur le business n’a été observé, et certains utilisateurs ont même plébiscité le changement, qui crée une expérience personnalisée.

L’ensemble de l’analyse, développement et généralisation a pris 4 mois. Vincent a mis en avant que la plus grosse difficulté a été de convaincre les parties prenantes. Pari réussi grâce à la pertinence des chiffres avancés et de l’approche choisie pour tester les hypothèses.

Conclusion

Un super talk, avec des décisions produits motivées par des métriques, pour rendre l’application beaucoup plus responsable !

Changer les bugs en or : le guide du développeur vers l’amélioration continue

par ​​Dennis Bordet

L’objectif est d’étudier nos problèmes et nos bugs pour en tirer des apprentissages et ainsi améliorer la qualité de nos applications.

Étape 0 : Le debugging

Avant toute analyse, il faut identifier et reproduire le bug. Il faut également trouver une première correction ou un workaround. Sans cela, on ne peut pas tirer d'apprentissage utile.

👉 Ressource utile : https://debug.guide/

Étape 1 : Le contexte

Le première étape est de décrire précisément le problème, c’est-à-dire l’écart entre le comportement observé et celui attendu (encore mieux avec une vidéo du bug).

• Identifier une ligne de code précise : si je ne la trouve pas, c’est que je n’ai pas encore bien compris le bug.
• En déduire le commit ou la Pull Request : on récupère le contexte complet du changement fait au code.
• Et avec la PR, on peut retrouver la demande fonctionnelle (si elle est liée à un ticket).

L’objectif est de comprendre l’intention du développeur et la demande de développement au moment où le bug est introduit afin d’avoir les informations pertinentes pour se remettre facilement dans le sujet. Cela permet :

1. D’identifier plus facilement les causes du bug.
2. De faciliter le partage des futurs apprentissages.
3. De faciliter la demande d’aide en cas de blocage.

Étape 2 : Les hypothèses de causes de l’introduction du bug

Points clefs :

• Se mettre dans une optique d’apprentissage plutôt que de justification : on fait des erreurs mais on veut apprendre de ses erreurs car c’est peut être nous qui avons introduit le bug donc il faut savoir rester humble.
• Ne pas rejeter la faute : cela freine l'amélioration.
• Chercher les causes dans le 4M

Les causes classiques :

• Les mauvais gestes de développement : le refactoring, mauvaise utilisation de bibliothèques, …
• Une mauvaise architecture : non-respect des principes SOLID, KISS, DRY, 5S.
• Le mauvais découpage d’une US : c’est une cause de détection tardive car le bug va être plus dur à détecter.
• Une mauvaise traduction du fonctionnel.
• Une mauvaise implémentation ou utilisation des Design Pattern.
• Une mauvaise structure de donnée : choix d’une structure incohérente avec le besoin.

Étape 3 : Les hypothèses de non détection ou de détection tardive

Trouver des causes de détection tardive c’est la même chose que trouver les causes d’introduction du bug. 

Mais il faut se demander pourquoi le bug n’a pas été trouvé dans les phases précédentes (ex : si on trouve un bug en prod, il faut chercher à comprendre pourquoi il n’a pas été détecté en phase de recette, de relecture de MR, etc)

Car plus un bug est détecté tard, plus il est coûteux à corriger.

Étape 4 : Les actions

Point clefs :

• Choisir la bonne action : si on a trouvé plusieurs actions à réaliser après l’étude du bug, on veut choisir l’action liée à la cause principale, on ne veut pas traiter les symptômes.
• Ne pas alourdir les processus : sinon on ne va jamais faire l’action.
• Modifier le système de travail pour rendre les actions pérennes.

Actions typiques :

• Identifier les autres occurrences du bug.
• Empêcher la réintroduction.
• Permettre une détection plus rapide.

Étape 5 : Les apprentissages

• Une meilleure connaissance de la codebase : on va mieux comprendre le fonctionnement et les dysfonctionnements de l’app
• Une meilleure connaissance des outils de travail: car en cherchant des solutions on va faire de la veille techno (IDE, CI)
• Identification des points faibles : on fini par identifier des root causes et des pain points de l’équipe
• Calculer des KPI précis et tacler des problèmes à une plus grande échelle en nous donnant des indices précieux : permet de piloter un plan d’amélioration qualité.

👉 Qu’est-ce qu’on fait de ces apprentissages ? On les partage à l’équipe et aux autres équipes !