Les 25 et 26 avril dernier, plusieurs développeurs de BPCE SI étaient présents à Montrouge pour participer au rendez-vous annuel des développeurs Android : Android Makers. Deux jours de conférences, de workshops et de discussion avec des développeurs venus du monde entier pour se tenir au courant des nouveautés, explorer les bonnes pratiques et profiter de retours d’expériences issus d’équipes diverses et variées. Cette année, les nombreuses conférences sur Kotlin Multiplatform et Jetpack Compose donnaient à l’événement un sentiment de réédition de la KotlinConf’ de l’année dernière.
Du côté Kotlin multiplatform, la technologie continue de faire ses preuves et de convaincre de plus en plus d’entreprises de sauter le pas. Aujourd’hui plus que jamais, démarrer une nouvelle app Android soulève obligatoirement la question de la mise en place d’une architecture multiplateforme, même si une version iOS du projet n’est pas encore à l’ordre du jour. La mise en place de modules communs ou spécifiques ne demande pas d’effort supplémentaire lors de l’initialisation du projet, mais elle permet d’éviter un important travail de migration plus tard si le choix se confirme. Le choix des librairies sera lui aussi lourdement influencé si la perspective de décliner le code sur au moins deux plateformes est vue comme une éventualité possible.
L’explosion du nombre de librairies qui supportent Kotlin Multiplatform est un autre indicateur très clair de la montée en puissance de cette approche qui bénéficie toujours des avantages de son postulat de départ : permettre le partage de code entre diverses plateformes (Android, iOS, Java, JS, natif desktop, WASM…) tout en laissant les développeurs libres de choisir l’étendue des sources communes et la quantité de développement spécifique. Aujourd’hui, on peut trouver des projets qui ne partagent qu’un petit module de code purement métier ou de classes de sérialisation JSON pour les plus timides comme des applications presque entièrement codées en Kotlin, de la couche réseau jusqu’à l’interface graphique. Les efforts communs de Jetbrains et Google pour porter certaines librairies Jetpack purement Android à la base (et notamment sa partie Compose) sur d’autres plateformes permettent aujourd’hui d’optimiser énormément la quantité de code partagé. La gestion des ressources, de la navigation, des view models ou même du cycle de vie des écrans font désormais partie de la liste des bibliothèques disponibles aussi bien sur Android qu’iOS, voire plus. Le prochain jalon important, attendu avec impatience par beaucoup, reste cependant la compilation du code Kotlin directement en Swift sur iOS et non plus en Objectif-C, mais le travail reste en cours et aucune date n’est pour le moment annoncé. A l’heure actuelle, c’est encore un des points les plus bloquants pour envisager de basculer nos applications mobiles sur une architecture multiplateforme.
Dans la foulée, Jetpack Compose continue aussi sa progression pour s’imposer comme la nouvelle référence en matière de toolkit graphique. Son intégration directe avec le compilateur Kotlin va faciliter le suivi des versions, mais la multitude de conférences axées sur le débugage et l’optimisation des interfaces construites avec Compose est tout de même révélatrice des problèmes de jeunesse du framework qui persistent encore. Si les premières annonces il y a quelques années semblaient mettre l’accent sur un mécanisme qui évitait les recompositions inutiles, la tendance est à la prudence aujourd’hui. Ces calculs que l’on espérait « automatiques » nécessitent finalement beaucoup d’attention pour bien construire les interfaces. Tous ces conseils visent donc à aider le compilateur à bien identifier quels composants sont liés à quelles données pour éviter les recompositions inutiles et le gaspillage de ressources lors du rendu.
C’est le constat que nous avions fait nous-mêmes lorsque nous avons commencé à décliner notre design system sous Compose : limiter les recompositions n’était pas aussi évident qu’anticiper, et les légères différences de rendu ou de comportements entre les widgets graphiques historiques et les nouveaux étaient problématiques pour conserver une expérience utilisateur cohérente partout dans notre application. Comme pour le multiplateforme, notre conclusion avait été que la mise en place restait plus facile sur un nouveau projet que sur une application existante, mais ces différents retours d’expérience qui confirment nos constatations seront utiles pour poursuivre notre migration petit à petit dans le futur.
Enfin en dehors de ces deux principales thématiques, la question de l’accessibilité et de l’amélioration de l’ergonomie était aussi au cœur des préoccupations pour améliorer l’expérience du plus grand nombre d’utilisateurs. Ce sont des problématiques constamment prises en compte dans la conception et le développement de nouvelles fonctionnalités, qui nous ont permis de rendre nos applications utilisables par le plus grand nombre de clients.
L’utilisation des IA génératives et leur intégration dans les IDE faisaient aussi partie des sujets évoqués, mais principalement comme des outils d’assistance à l’écriture plus que comme des solutions de génération de code fiable : les suggestions proposées peuvent fréquemment faire gagner du temps d’écriture, mais nécessitent obligatoirement la supervision d’un développeur expérimenté pour juger de la pertinence des propositions et éliminer les hallucinations ou les suggestions inspirées par de mauvais patterns. L’expérience se rapproche finalement plus d’une session de pair programming avec un collègue débutant qui tape vite, mais ne sait pas toujours si ce qu’il écrit fait sens ou pas. Là encore, les expérimentations menées chez BPCE SI montrent que nous sommes toujours à l’écoute des avancées qui peuvent permettre d’améliorer le quotidien et la productivité de nos développeurs.