De retour à l’Android Makers by Droidcon 2023 - Partie 1/2

Lien vers la deuxième partie

Et voilà, après une année d’attente interminable, la practice mobile d’Ippon était de retour à l’évènement Android Français de l’année : Android Makers. C’est ainsi que les 27 et 28 avril 2023, notre équipe d’experts a pu participer à l’ensemble des conférences qui se déroulaient, comme l’année dernière, au Beffroi de Montrouge, en région parisienne.

Petite nouveauté cette année néanmoins : les Android Makers passent sous le giron de Droidcon, célèbre pour ses salons de conférences autour du monde. Dans les faits, pas de grands changements : une organisation rodée, des speakers brillants et la présence nombreuse d’une communauté de passionnés.

La keynote d’ouverture verra d’ailleurs Chet Haase et Romain Guy effectuer un “back to back” pour revenir nous parler d’un sujet assez peu abordé habituellement : Android Graphics. Concrètement, les deux Googlers nous ont offert une rétrospective des choix effectués et des développements faits depuis la première version d’Android sur l’API Graphics. On comprend alors mieux d'où viennent les `Canvas`, `Paint` et autres `RectF` qui s’avèrent très utiles lorsque l’on créer des formes custom ou bien encore faire de la manipulation de `Bitmap`.

Une fois la keynote terminée et un petit déjeuner rapidement englouti, la practice mobile s’est disséminée au gré des curiosités des uns et des autres afin d’aller suivre les différents talks. On vous offre ici une petite sélection personnalisée des conférences les plus marquantes selon la practice.

Les différentes stratégies de monétisation d'une application mobile

Par Romain Bouchaud et Anthony Stéphan-Guilloteau (Les slides de la présentation)

Les développeurs mobiles ont besoin de monétiser les applications, car nous vendons des services via nos applications, et les ventes de services devront nous être redevables de diverses manières. Romain Bouchad et Anthony Stéphan-Guilloteau nous ont expliqué pourquoi monétiser, comment diffuser de la publicité, les moyens de vente de son application et les aspects juridiques à l’Android Makers.

La monétisation de l’application permet le financement de l'évolution de l’application, augmente la visibilité de l’application et le plus important permet de gagner plein d’argent. La diffusion publicitaire contient 4 formats publicitaires :

• Bannière : Publicité qui est fixe en bas ou haut de l’application et reste durant la vie de l’application. Elle apporte peu de revenus, mais n’a pas d’impact sur l’UX.
• Interstitielle : Des pop-up qui vont apparaître et pourront être fermées après un certain temps. Elle apporte beaucoup de revenus, mais un impact assez négatif sur l’UX.
• Native : Publication intégrée nativement à l’application. Elle apporte peu, mais à un impact assez positif sur l’UX.
• Rewarded : Publication qui apparaît pour recomposer l’utilisateur seulement s’il veut. Elle apporte beaucoup, mais un impact très négatif sur l’UX.

Une application mobile devrait avoir plusieurs sponsors publicitaires pour garantir les revenus, même si certains sponsors du jour au lendemain décident de diffuser leurs publicités.

Il existe le système de waterfall. Un système qui privilégiera les annonces des personnes qui payent le plus et ainsi de suite. Il y a aussi le système du bidding. Un système ou la personne qui en propose le plus n'affiche que ses publicités. Mais il est important de savoir qu’il existe des 3 types de problématiques principales que l'on peut rencontrer.

• Saisonnalité : Le problème de mauvais timing, c'est-à-dire qu’on peut avoir des moments où il n’y aurait pas de publicité fournie.
• Réglementation : Les différents problèmes de réglementation à faire avant d’intégrer la publication tel que le RGPD, Gestionnaire de consentement et le PEGI
• Fournisseurs : Les problèmes de coupures de service, factures impayées et mauvaise qualité de publicités fournis.

Mais si vous ne voulez pas faire face à ses différents problèmes, vous pouvez essayer de vendre votre application. L'avantage de vendre votre application est que vous êtes indépendant du fournisseur, mais le service que vous vendez doit être avantageux. Pour vendre son application, il y a 4 différents moyens :

• B2C (en catalogue) : Revenu one-shot (Application achetée en une seule fois) sur les stores comme le play store, Apple store, etc. C’est une vente directe à l’utilisateur et il faut vendre un prix juste
• B2C (achats in-app) : Achats directement dans l’application permettant de déblocage de fonctionnalités. Les revenus sont plus ou moins réguliers.
• B2C (abonnement) : Souscription à un abonnement mensuel ou annuel. C’est un service fort et fidèle qui contribue à avoir des revenus réguliers.
• B2B : Permet de vendre des licences, mais il faut réussir à la vendre plus chère.

Pour maximiser la performance des revenus, nos applications doivent être visibles sur autant de plateformes que possible et créer des services adaptables. Par exemple, si l'application est publiée sur le store Huawei et est bien référencée, l'application touchera une audience plus large et rapportera ainsi plus de revenus. Il dispose également d'autres moyens, tels que le financement participatif (collecte de fonds) et la vente de données (il faut principalement anonymiser les utilisateurs).

Au fur et à mesure que nous monétisons notre application, nous devons tenir compte des aspects juridiques. Tout d'abord, sachez qu'il ne s'agit pas d'une vente de biens, mais d'une vente de services, et qu'il est préférable de consulter un conseiller fiscal. En prenant Google Play comme exemple, 56% des pays du monde et 12% des régions américaines n'ont pas de TVA définie, ce qui signifie que vous devez le faire vous-même. De plus, les factures reçues par Google ne sont pas considérées comme des reçus mensuels. Romain Bouchad et Anthony Stéphan-Guilloteau ont créé un super projet qui convertit les factures reçues par Google en reçus mensuels, voici le lien GitHub.

Sur le plan juridique, vous devez tenir compte de la structure juridique de votre pays. Il existe 3 types de structures juridiques en France :

• Auto Entreprise : Avec le statut TNS (Travailleur Non Salarié), la comptabilité est simplifiée, c'est-à-dire qu'il y a un équilibre entre les risques, responsabilités et les avantages.
• EURL : Dans l'état TNS, les exigences comptables sont élevées, c'est-à-dire que vous pouvez faire plus de profits, mais il y a plus de risques et plus de responsabilités.
• SASU : Le statut d'assimilé salarié a des exigences comptables élevées, c'est-à-dire que la sécurité est beaucoup plus élevée et qu'il a moins de responsabilité, mais le bénéfice est moindre.

La monétisation des applications reste un sujet d'actualité, car dans tous les cas il faut gagner des revenus par la vente de services, mais cela reste un sujet complexe qu'il faut bien comprendre avant de se lancer.

Demystifying the test pyramid

par Xavier F. Gouchet (Les slides de la présentation)

Comme on dit dans le milieu : “Tester c’est douter”. Pourtant, les tests nous sauvent la vie, et ce à plusieurs niveaux. Dans son talk, Xavier F. Gouchet aborde le sujet de la pyramide des tests, en s’appuyant sur la définition de Mike Cohn dans son livre Succeeding with Agile (2009).

La pyramide des tests, kézako ?

On en a souvent entendu parler sans vraiment y mettre un nom dessus, il s’agit de la pyramide qui schématise les tests unitaires, de service (i.e. d’intégration) et d’UI (i.e. end-to-end).

Mais s’agit-il vraiment d’une pyramide ?
Il semblerait qu’un triangle soit plus approprié. Triangle qui peut vite induire en erreur :

Je ne comprends pas pourquoi l’app crash, j’ai pourtant fait plein de TUs !

Voilà le résultat quand on ne se concentre que sur la quantité de tests rédigés.

Et si on complétait ce triangle pour en faire une vraie pyramide ? Avec quatre côtés bien solides, dont chacun répond à une question, et le tout donne une vision d’ensemble sur la stratégie de test :

• Que testons-nous ?
• Pourquoi le testons-nous et que cherchons-nous à fiabiliser ?
• Comment le testons-nous ?
• Quand et où lançons-nous les tests ?

Chaque côté ajoute une dimension supplémentaire, afin de prendre du recul sur la stratégie de test envisagée. Cela permet également d’être plus modulable et de pouvoir s’adapter à n’importe quel type de projet.
Attention cependant à la lecture du code coverage. Comme le montre la photo ci-dessous, avoir 100% des tests qui passent ne signifie pas que le produit est vraiment testé correctement !

Grâce à tous ces outils, il nous est désormais impossible de se louper sur l’utilisation des tests (ou presque). À vous de vérifier que vous connaissez bien votre alphabet !

Practical ADB usage to enhance your life!

par Benjamin Kadel (Slides de la présentation)

L’Android Debug Bridge, ou ADB pour faire court, est l’outil fourni par Google qui permet de communiquer avec un téléphone Android (physique ou émulateur) et son poste de travail. Tous les développeurs Android, sans exception, s’y sont frottés au moins une fois dans leur vie et il n’est pas rare que certains en gardent quelques traumatismes.

Mais l’ADB est un outil très, très, très complet et Benjamin avait à cœur de nous le rappeler en axant son discours sur les “pépites” d’ADB qui permettraient de booster la productivité du développeur et de lui simplifier la vie. Par exemple : ne pas avoir à entrer ses credentials sur un écran, pouvoir éditer les SharedPreferences, ou encore modifier la taille et la résolution de l’émulateur ou du device physique. Ainsi, tout au long de son talk, Benjamin dévoile différentes commandes (ADB mais aussi Bash) permettant de réaliser des opérations qui peuvent s’avérer fastidieuses si elles sont faites à la main.

Un exemple développé dans le talk est l’action de devoir retaper à l’écran nos identifiants de connexion pour passer un écran de login lorsque l’on effectue des tests. Benjamin démontre qu’avec les bonnes commandes, il est possible d’automatiser tout le processus. En effet, il est relativement simple via ADB de découvrir avec précision l’emplacement d’un composant graphique, de cliquer dessus et d’entrer du texte. On peut alors, via un script bash, facilement automatiser le fait de se connecter à un écran lorsque l’application est lancée. Intéressant non ? Et ce n’est qu’un exemple parmi d’autres. Si cela pique votre curiosité, un linktr.ee est disponible ou vous pouvez retrouver notamment ses slides mais aussi quelques liens utiles.

Benjamin est un très bon orateur et cela s’en ressent fortement. Il est dynamique, drôle et possède le sens du rythme quant au déroulement de son discours. Cela donne une présentation captivante à regarder. Et en plus, bonus : on apprend des choses ! Que demander de plus ?

Introduction à l’observabilité sur mobile

Par Kelian Clerc & Valentin Pertuisot

Aujourd’hui le développement d’application mobile requiert de plus en plus de vigilance vis à vis de l’ergonomie, de l’accessibilité, du design ou encore des performances. Les équipes sont donc confrontées à un ensemble de défis et une exigence accrue pour la qualité des développements. L’observabilité permet ainsi de :

• Surveiller leurs applications grâce à des outils afin de réagir rapidement en cas d’erreurs et de problèmes permettant ainsi d’offrir aux utilisateurs une expérience des plus qualitative
• Comprendre s’il s’agit d’une exception, d’un problème récurrent ou même d’anticiper certaines situations
• Reproduire les erreurs grâces aux différentes informations associées (version, vue, chemin utilisateur…)
• Résoudre les problèmes en prenant les décisions adéquates (exemple : réaliser un hotfix est-il nécessaire ou une correction dans la prochaine mise à jour suffira ?)

​Durant leur talk, Kelian et Valentin, ont insisté sur le rôle de l’observabilité, mais aussi sur sa mise en œuvre et surtout sur le fait de la mettre en place rapidement.

Plusieurs outils peuvent être utilisés (Datadog, Firebase Analytics, logs gérés par le back-end puis visualisés via un Dashboard par exemple) mais ils conseillent de commencer par quelque chose de simple et surtout adapté aux besoins du projet.

Ils préconisent également de configurer ces outils au fur et mesure mais de le faire le plus tôt possible afin d’avoir le maximum d’informations s’il survient un problème. Ils ont mis l’accent sur la pertinence des données à remonter pour traiter les erreurs de manière efficace et de ne pas être surchargé d’informations inutiles.

Par exemple, le taux d’échec sur une fonctionnalité donnée peut donner des informations sur la pertinence de celle-ci ou sa compréhension vis à vis des utilisateurs. Ainsi ces métriques peuvent être révélatrices de problèmes techniques ou ergonomiques. Elles peuvent même rassurer sur une correction apportée.

Néanmoins, l’analyse de ces différentes données ne doit pas devenir chronophage d’où l’importance de :

> Choisir les indicateurs les plus pertinents (celles avec un impact important dans un premier temps),

> Se créer une routine d’ajout de logs après chaque développement

> Privilégier les alertes automatiques (réception d’un mail ou d’un message Slack par exemple) afin d’être notifié lors d’une erreur majeure peut faire gagner du temps et de l’énergie. Les seuils d’alertes seront ajustés au fur et à mesure

> Utiliser des outils d’agrégation de données pour visualiser l'amas de données

Une attention particulière doit être portée aux contraintes de la récupération de données utilisateurs telles que la RGPD, l’autorisation obligatoire des utilisateurs ou encore les coûts associés aux outils utilisés.

L’observabilité est avant tout un état d’esprit afin de garder nos applications performantes et appréciées. Il faut à tout prix éviter que ce soit une charge supplémentaire; cela doit devenir une habitude à prendre.

Merci à nos orateurs qui ont su rendre ce talk dynamique et instructif grâce à un support épuré, un discours clair et des exemples concrets.

Off to the races with Android

Par Etienne Caron & François Légaré

Avec la généralisation de la 5G, partout dans le monde, le haut débit amène également une réduction des temps de latence permettant toutes sortes d’applications jusqu’à maintenant inenvisageables.

Afin de le prouver et de communiquer autour de ces capacités techniques, le laboratoire d’innovation de Bell prépare un projet / démonstration en marge du prochain grand Prix de F1 de Montréal.

L’idée de base s’apparente à l’expérience du jeu Mario Kart Live : Home Circuit.

Il s’agit pour les heureux pilotes en herbes sélectionnés de prendre le contrôle d’une voiture télécommandée (basé sur un modèle réduit trouvable sur Amazon pour une somme modique) modifiée et équipée d’un smartphone pliable Android (servant à la fois de modem et de caméra) et ceci depuis n’importe quel point du Canada depuis le réseau 5G.

Ces voitures évolueront sur un circuit construit temporairement sur le site du circuit Gilles Villeneuve à Montréal et verront d’affronter à distance les compétiteurs sélectionnés dans un championnat le temps du week-end.

Après une courte description des modifications apportées suivi d’une démonstration sur scène d'un prototype, l'équipe nous rappelle qu’il ya plusieurs critères qui sont à prendre en compte afin d’offrir la meilleure expérience possible :

• Une latence < 150ms
• Une fréquentation du site > 100k visiteurs
• Une gestion automatisée des concurrents afin d’éviter le « destruction derby ».

Niveau architecture, c’est l’utilisation du Multi-access Edge Computing (ou MEC) qui permet également à la fois de rapprocher les calculs au plus près de la source mais surtout in fine de minimiser l’utilisation de la bande passante. Le résultat est qu’avec l’installation sur le site d’un réseau 5G privé, cela permet d’atteindre moins de 20 ms de latence.

De plus, afin d’éviter l’effet de « destruction Derby », l’utilisation d’une IA dédiée qui scrute la piste, en permanence et en temps réel, permet d’automatiquement détecter les comportements « déviants » des petits bolides. En outre, celle-ci a toute latitude d’attribuer yellow flags et red flags aux apprentis pilotes qui ne respecteraient pas les consignes de course.

Un événement qui risque d’avoir un retentissement important autour du Grand Prix de Montréal et servir de Proof of Concept pour des utilisations plus appliquées en termes de sécurité routière comme ne manquaient pas de le rappeler nos intervenants.

How Wildlife Studios maximizes mobile game performance and discoverability

Par Lucas Klegen

Quelle serait la vie d’un développeur mobile sans outil de monitoring … il serait très certainement dans l’état d’esprit que tout va pour le mieux dans le meilleur des mondes après avoir réussi à déposer son application sur les différents stores existants. Malheureusement, la réalité est souvent toute autre entre problèmes de performances et apparitions de bugs. C’est pour éviter ce genre de situation que les outils de monitoring ont été inventés et sont devenus nos meilleurs amis.

C’est ce que nous présente l’éditeur de jeux mobiles Wildlife Studios avec Embrace, un outil de monitoring qui leur facilite la vie au quotidien.

Après avoir testé plusieurs outils du genre, l’éditeur en est venu à la conclusion que ce dernier leur était indispensable pour garder un bon niveau de performance.

Embrace leur a ainsi permis de pouvoir traiter plusieurs sujets tels que :

• La scalabilité: il n’y a rien de plus compliqué que de prévoir le niveau d’adoption d’une application et donc de choisir l’infrastructure la plus adaptée.
• L’utilisation des ressources: toute entreprise se voit confronter à des problématiques d’allocation de ressources. Ces ressources ne sont pas infinies et nécessitent une bonne gestion ainsi qu’une priorisation des objectifs. Est-il plus judicieux de s’afférer à l’ajout de nouvelles fonctionnalités ou à l’amélioration de l’existant ?
• L’observabilité: les applications mobiles génèrent un important volume de données. Parmi celles-ci, on retrouve notamment les comportements utilisateurs, leur progression dans l’application ou encore les métriques de monétisation. L'agrégation de ces données offre un outil permettant d’améliorer l’expérience utilisateur. Encore faut-il qu’elles soient complètes.
• Le support: l’une des principales problématiques rencontrées dans le monde du développement est le fait de pouvoir anticiper l’arrivée de nouveaux bugs et d’appliquer des correctifs avant que de trop nombreux utilisateurs ne soient impactés.

C’est là qu’intervient Embrace, un outil offrant une remontée de données qui se veut plus fournie que ses homologues.

Embrace a permis, grâce au volume de données important qu’il capture, de répondre à plusieurs problématiques rencontrées par l’éditeur au travers de leurs différentes applications.

Parmi ces problématiques, on retrouve notamment :

• Garder un taux d’ANR (App Not Responsive) en dessous des seuils d’acceptabilité. De manière générale, il est rarement simple d’analyser la cause d’un bug. Dans le cadre de cette présentation, l’éditeur nous a donné l’exemple d’un bug qui arrivait de manière spécifique. Avec toutes les données que leur remonte Embrace, les développeurs ont pu voir que le problème venait d’un petit ensemble de modèles de smartphones lors de l’affichage de publicités. Chaque bug corrigé par les développeurs représente un pas de géant vers un taux d’ANR acceptable pour les différents stores. En effet, plus une application mobile est performante (et donc moins elle rencontre de bugs) et plus elle a de chance d’être mise en avant par les stores. De même, plus un utilisateur peut interagir facilement avec son application et plus il aura tendance à l’adopter.
• Faciliter la résolution de bugs souvent associés à des erreurs génériques. Il arrive régulièrement que des erreurs remontées par des outils de monitoring ne soient pas très parlantes, ce qui ne facilite pas leur correction. Dans ce genre de situation, il est toujours préférable d’avoir à sa disposition un grand nombre de métriques pour se simplifier la tâche. C’est ce que semble apporter Embrace puisque cet outil leur a permis de trouver l’origine d’erreurs telles que l’implémentation d’une librairie au sein d’une de leurs applications. Il leur a même donné comme précision la ligne de code qui provoque cette erreur.
• Remonter des bugs que d’autres outils de monitoring ne capturent pas forcément. Il n’est pas impossible que nos outils de monitoring n’arrivent pas à nous faire remonter certaines données telles que des bugs spécifiques. S’armer d’un outil répondant précisément à ses besoins et à ses spécificités est donc essentiel.
• Alerter les développeurs lorsqu’il y a une forte augmentation du nombre de bugs. Wildlife Studios se montre relativement réactif lorsqu' une nouvelle version d’application est poussée sur les stores. C’est le cas notamment lorsque cette dernière est accompagnée d’une augmentation du nombre de bugs observés. Grâce à des alertes prédéfinies dans leur outil de monitoring, les développeurs ont un moyen de savoir assez rapidement si une mise en production récente est sujette à l’apparition de nouveaux bugs. Cette réactivité est aussi dû au fait qu’Embrace permet une remontée des données en direct, c’est-à-dire avec très peu de délais.

On peut dire que les sujets de la stabilité et des performances d’une application sont primordiaux pour son adoption auprès des utilisateurs cibles. L’utilisation d’outils de monitoring est pour cela indispensable puisque c’est grâce à eux que l’on peut dévoiler des bugs, en trouver la cause et enfin les corriger avant qu’un grand nombre d’utilisateurs ne s’en rendent compte.

Embrace semble être un outil intéressant dans l’écosystème de Wildlife Studios puisque le volume considérable de données qu’il remonte leur permet de travailler sereinement. Reste à voir si cet outil est adapté pour tous types et/ou tailles d’applications.

Quoi qu’il en soit, il est évident que le choix d’un tel outil n’est pas à prendre à la légère puisqu’il joue un rôle essentiel dans l’adoption d’une application que ce soit à court, moyen et long terme.

Bien évidemment, toutes les notions évoquées lors de cette présentation sont transposables de manière générale au développement d’applications mobiles.

Tu es déjà arrivé au bout de l'article ? Ne t'inquiète pas, la deuxième partie est disponible ici.