On a parlé du dicton “Jamais deux sans trois” il y a quelques semaines dans notre article sur Android Makers 2024, et bien ici nous pouvons le réutiliser pour vous parler de la troisième édition du salon Mobilis in Mobile, qui s’est déroulée une nouvelle fois à Nantes (toujours au Médiacampus), et auquel certain(e)s de nos expert(e)s ont assisté le 18 juin dernier. Après l’édition 2023, voici un nouveau florilège des quelques talks qui ont retenu leur attention.

Partagez vos composants UI pour Android et iOS et visualisez-les sur une simple page WEB !

Jonathan Lagneaux - Consultant / Formateur mobile au sein de Zenika

« Imaginez qu’on puisse créer une seule et même librairie native de composants pour Android et iOS. Imaginez aussi que cette librairie puisse être documentée et partagée de manière simple et rapide. Imaginez enfin que cette librairie puisse être visualisée par toute personne ayant accès à un navigateur Web »
C’est avec cette accroche que Jonathan Lagneaux nous emmène dans l’univers de Kotlin Multiplatform (KMP) et plus précisément de Compose Multiplatform (CP).
Avant d’entrer dans les détails de CP, Jonathan nous rappelle quelques fondamentaux :

Kotlin Multiplatform est un framework conçu pour permettre aux développeurs d'écrire du code commun une fois et de pouvoir l’utiliser de façon native sur plusieurs plateformes (Web, Desktop et Mobile) réduisant ainsi le temps d’écriture et de maintenance tout en conservant la flexibilité et les avantages de la programmation native.
L’un des mécanismes clés de KMP est notamment celui des déclarations expect/actual, qui permet d'accéder à des API spécifiques à chaque plateforme tout en développant une logique commune. Ce mécanisme facilite le partage de code entre les différentes plateformes tout en permettant des implémentations spécifiques pour chacune d’entre elles.

Vous l’aurez compris, KMP permet de partager une logique commune et de permettre une mutualisation d'un même code commun tout en laissant au développeur le soin d’intégrer pour chaque plateforme une UI qui lui est propre. 

A l'issue de cette présentation de KMP, Jonathan fait un focus sur la partie mobile. Dans le cadre de la création d’un design system, c’est la responsabilité de chaque plateforme d’implémenter ses composants selon une spécification. Pour un même bouton, nous avons deux implémentations : une iOS et une Android. Et s’il était possible d’aussi mutualiser ce code UI et de l’utiliser sur les deux plateformes ? 

Il a alors pour projet de créer des composants à l’aide de Compose Multiplatform et de les présenter dans une application qu’il sera possible de lancer sous iOS ou Android. Il crée alors un ensemble de composants et de pages dans son dossier common où le point d’entrée de son projet est « App ».

Côté common nous avons ainsi :

L’appel de ce code commun est ensuite simplement réalisé de la façon suivante sur les deux plateformes :
Côté Android : 

Et côté iOS (respectivement iosMain et iosApp)

Et voilà ! Jonathan dispose à présent de deux applications (une Android et une iOS) permettant d’afficher des pages présentant les composants de son design system et ceci grâce à du code mutualisé. Cependant quelque chose l’embête, si quelqu’un souhaite consulter la librairie et les composants qu’elle contient, il doit obligatoirement passer par l’installation de l’application Android ou iOS. Et pourquoi pas la mettre à disposition sur le web ?

Pour cela, il va s’appuyer sur Kotlin/Wasm, qui lui permet de compiler son code Kotlin en WebAssembly (Wasm) et de pouvoir exécuter ce code dans un navigateur Web.Pour faire fonctionner celà au sein de son projet, il ajoute alors une target supplémentaire au sein de son build.gradle.kts (en plus de celle existant pour Android et d’iOS)

Ainsi qu’un nouveau package (wasmJsMain) contenant une nouvelle classe pouvant lancer ce code sur la nouvelle cible.

Il n’y a plus qu'à lancer la tâche Gradle :composeApp:wasmJsBrowserDevelopmentRun pour observer le résultat

En quelques lignes, en plus d’une application Android et iOS, nous disposons maintenant d’une application Web. Nos composants peuvent ainsi être partagés facilement sans qu’une installation sur un appareil mobile soit nécessaire.

Point d’attention cependant, même si Kotlin Multiplatform est maintenant stable, ce n’est pas du tout le cas de Compose Multiplatform qui est encore en Bêta voir même en Alpha en fonction de la cible et des fonctionnalités souhaitées.
De plus, un œil attentif l’aura remarqué, mais Jonathan pointe du doigt que les fonctionnalités liées au Web sont encore au stade expérimental et que son affichage se fait notamment via un Canvas qui va poser problème pour des questions notamment d'accessibilité. 

Merci encore à Jonathan pour ce talk sur Kotlin et Compose Multiplatform, de notre côté nous avons hâte de voir ce que JetBrains prévoit pour l’avenir. Conscients qu’il n’est pas possible d’expliciter chaque détail technique dans cet article, si vous souhaitez en savoir plus sur le projet de Jonathan, n’hésitez pas à consulter son GitHub.

Un Regard sur visionOS & Vision Pro: Pourquoi c’est à Nouveau le 9 Janvier 2007

Manu “StuFF” Carrasco Molina - Développeur iOS au sein de Quartett mobile

Lors de sa récente présentation, Manu Carrasco Molina a comparé l'impact potentiel du Vision Pro d'Apple à celui de l'iPhone, dévoilé le 9 janvier 2007. Vision Pro, avec son nouveau système d'exploitation visionOS, promet de révolutionner notre interaction avec le contenu numérique grâce à des avancées matérielles et logicielles majeures.

Pourquoi utiliser Vision Pro ?

Vision Pro se distingue par une panoplie de fonctionnalités de pointe conçues pour enrichir l'expérience utilisateur. Il dispose de multiples caméras et capteurs, garantissant une capture précise des données environnementales et de l'utilisateur. La technologie audio spatiale offre un son immersif, tandis que les deux écrans micro OLED haute résolution assurent une clarté visuelle exceptionnelle. Un occulteur de lumière périphérique améliore la concentration en éliminant les distractions, et la double bande en boucle assure un ajustement confortable pour diverses tailles de tête. Cependant, l'appareil n'est pas idéal pour les porteurs de lunettes.

Avec une autonomie de deux heures, Vision Pro est conçu pour des sessions d'utilisation modérées. La couronne numérique, semblable à celle de l'Apple Watch, permet une navigation intuitive.

Matériel innovant

Le matériel du Vision Pro est à la pointe de la technologie :

• Capteurs TrueDepth : Quatre capteurs améliorent la perception de la profondeur.
• Système de caméras complet : Six caméras assurent une couverture visuelle complète.
• Caméras de suivi oculaire : Quatre caméras (deux par œil) offrent un suivi précis des mouvements des yeux grâce à la technologie infrarouge.
• Puissance élevée : L’équivalent de la puissance d’un iMac dans chaque œil !
• Fonction EyeSight : Affiche les yeux de l'utilisateur sur un écran externe, permettant aux autres de savoir où se porte son attention.
• Microphones : Six microphones pour une capture audio améliorée.
• Puces doubles : Une puce M2 pour la vision et les graphiques et une puce R1 pour les autres fonctions.

Un écosystème logiciel adaptatif

L’écosystème logiciel de Vision Pro est conçu pour s’intégrer parfaitement avec les produits Apple existants tout en introduisant de nouveaux paradigmes :

• La plupart des applications iOS fonctionneront bien, qu'elles soient en mode paysage ou portrait.
• Les versions plus anciennes d’iOS peuvent rencontrer des problèmes de compatibilité.
• Vision Pro abandonne certains concepts traditionnels tels que UIDeviceOrientation et UIScreen.
• UITabBar a été adapté pour ne pas avoir de leading ou de trailing.
• Les applications nécessitant le support de l'Apple Pencil ne sont pas compatibles.

Outils et débogage

Le développement sur visionOS présente quelques défis et nécessite des outils spécifiques :

• Simulateur VisionOS : Permet de tester les applications.
• RealityComposer : Pour exporter des modèles AR 3D.
• Parallax Previewer : Permet de prévisualiser une icône en 3D.
• Sidecar : Permet d'afficher Xcode sur le Vision Pro.

Pour le débogage, quelques conseils :

• Le simulateur peut afficher un schéma où les différentes interfaces se présentent dans un environnement 3D.
• Il est recommandé de ne pas placer des éléments directement devant nous dans le simulateur.
• Lors des tests sur Mac, le pointeur de la souris représente le regard, et le clic représente le pincement de doigt.

Immersion et astuces

Vision Pro propose deux types d’espaces immersifs :

• Shared Space : Un espace où toutes les fenêtres d’application sont disposables.
• Immersive Space : Un espace fictif affiché par visionOS, généralement des paysages magnifiques.

Pour optimiser l'utilisation de Vision Pro :

• Les icônes des applications ont trois couches de 1024x1024, permettant une personnalisation accrue.
• La navigation se fait par la vision, les mains et la voix, avec des gestes tels que le pincement, la rotation et l'utilisation du bout des doigts.
• Un clavier virtuel est disponible, mais grâce aux caméras, un véritable clavier Bluetooth peut également être connecté.
• La Magic Mouse n’est pas supportée, et il n'est pas possible d'utiliser une manette pour le gaming.
• Le colorScheme par défaut des applications iOS sur Vision Pro est sombre, tandis que celui des applications visionOS est clair.
• Les fenêtres normales en UIKit ou SwiftUI fonctionnent bien, et la fonctionnalité HelloWorld explique comment charger un objet 3D via SwiftUI.

En somme, Vision Pro et visionOS annoncent une nouvelle ère d’interaction technologique, redéfinissant les normes et ouvrant la voie à de nombreuses possibilités.

REX: Flutter VS Dette technique

Fabien Dhermy - Développeur mobile (iOS, Android, Flutter) chez Mobiapps

La dette technique est un phénomène omniprésent dans le développement logiciel, souvent sous-estimée, mais qui peut rapidement transformer des projets prometteurs en véritables casse-têtes. Fabien Dhermy, développeur mobile chez La Poste, a partagé son retour d'expérience, illustrant comment son équipe a navigué à travers les défis techniques pour maintenir et améliorer une application vieillissante.

L'histoire commence il y a un an et demi, lorsque Fabien rejoint le pôle mobilité de La Poste pour travailler sur une application de portail de services. Créée en 2018 à partir d'un Proof of Concept (PoC), l'application a évolué pour devenir un socle pour d'autres applications, intégrant des fonctionnalités telles que la réservation de salles, la restauration et le parking. Cependant, après six ans de croissance continue, l'application est devenue difficile à maintenir en raison de l'absence de gestion de l'état définie, de l'utilisation inadéquate de certaines bibliothèques comme built_value, et d'une mauvaise gestion des composants, avec un seul cubit pour toutes les fonctionnalités.

À son arrivée, Fabien a trouvé une application fonctionnelle mais encombrée par une dette technique importante. Il a entrepris une analyse approfondie pour identifier les principaux problèmes et a mis en place une phase de réduction de cette dette. Parmi les actions clés, on compte le choix et la refactorisation du state management, la mise à jour des versions de Flutter, le passage de built_value à freezed, et l'adoption de Dio avec des intercepteurs pour améliorer les appels réseau.

L'un des défis majeurs était la migration vers nullsafety, une tâche ardue mais nécessaire pour assurer la robustesse de l'application. Le projet, structuré en monorepo avec Melos, contenait initialement trois applications avec deux architectures et trois state management différents (Provider, Cubit, Bloc). Ce nombre est passé à cinq applications avec une nouvelle architecture, créant une complexité supplémentaire. Pour simplifier, l'équipe a choisi de se concentrer sur une seule architecture (clean architecture) et un seul state management (Cubit).

Fabien a souligné plusieurs erreurs commises et les leçons qu'il en a tirées. Parmi les erreurs, la négligence des tests s'est avérée particulièrement coûteuse. Pour y remédier, il recommande de fédérer et transmettre les connaissances entre les équipes, de pratiquer la relecture de code et le pair programming, et de maintenir une documentation rigoureuse, notamment sur Confluence.

L'importance des tests a été réitérée, non seulement pour les tests fonctionnels et automatisés, mais également pour les tests unitaires, souvent négligés. L'équipe de Fabien a également appris à réduire la dette technique de manière continue, plutôt que de la laisser s'accumuler.

Le talk de Fabien Dhermy a offert une perspective précieuse sur la manière de gérer la dette technique dans un projet en cours. Son expérience chez La Poste montre que, bien que la réduction de la dette technique soit un processus long et complexe, il est essentiel pour maintenir la santé d'un projet logiciel. En adoptant des bonnes pratiques comme la documentation, les tests rigoureux, et en faisant des choix techniques éclairés, les équipes peuvent transformer des projets compliqués en systèmes robustes et maintenables.

 Accélérez vos patchs mobiles en prod avec Shorebird & Flutter

Adrien Body - Sncf Connect And Tech

Avez-vous déjà été dans une situation délicate où vous deviez déployer un correctif urgent sur un environnement spécifique ? Avez-vous craint que ce correctif essentiel pour le bien-être de vos utilisateurs ne soit pas installé par tout le monde en raison de retards imprévus, tels que la validation des stores, les processus de déploiement, ou les mises à jour de l’application par les utilisateurs ? Pour vous permettre de déployer ces correctifs en toute sérénité, Adrien Body nous présente un outil innovant qui élimine le stress lié à ces situations !

A travers ce talk, Adrien nous montre comment améliorer la qualité de notre code en production sans les contraintes habituelles grâce à Shorebird. Cet outil permet de contourner les longs processus de validation des stores et l'attente des mises à jour par les utilisateurs.

Shorebird propose le "code push", ou mise à jour Over-The-Air (OTA), permettant d'envoyer des morceaux de code directement aux utilisateurs sans passer par les stores. Cela inclut des patches Dart pour Android et iOS, tout en étant open source. Shorebird fonctionne comme un fork de Flutter qui utilise un client Rust pour vérifier la disponibilité de patches sur un serveur. Lors du démarrage, l'application charge un bundle Dart personnalisé si un patch est disponible, sinon elle utilise le bundle de base.

Une question importante est la conformité aux directives des stores. Pour respecter les ces dernières, notamment celles d'Apple, le code doit être interprété. Dart n'est pas habituellement un langage interprété en production (il utilise JIT en debug et AOT en production). Shorebird utilise un interpréteur de Dart qui produit une version interprétable du code compilé. Bien que plus lent, seules les parties modifiées sont interprétées, minimisant ainsi l'impact sur les performances.

Shorebird permet de créer des versions avec des anciennes versions de Flutter (à partir de la 3.10.0 pour Android et de la 3.22.2 pour iOS). Une fois intégré, il permet de créer des releases locales envoyées aux serveurs de Shorebird. Chaque version peut être patchée et doit être compatible avec les versions disponibles sur les stores. Shorebird propose également des patches en “staging” pour validation avant le déploiement.

Shorebird, c’est aussi : 

• Un wrapper autour de Flutter, permettant l'utilisation de commandes Flutter habituelles. 
• Une interface permet de gérer les patches avec une double validation pour plus de sécurité. Un token peut être récupéré pour intégrer Shorebird dans votre CI (par exemple, GitHub, Circle CI).

Shorebird propose plusieurs méthodes pour notifier les utilisateurs des patches :

• Manuel : Implémentation de votre propre logique de téléchargement des patches, par exemple, en fonction de la version ou de l'utilisateur.
• Notifications : Combiné avec le mode manuel, permet de cibler des appareils spécifiques pour les mises à jour.

Lors du premier démarrage, aucun patch n'est appliqué. Au deuxième démarrage, si un patch est disponible, il est installé.

Il est crucial de ne pas mélanger Shorebird avec le mécanisme de mise à jour forcée des stores, car cela peut entraîner des mises à jour plus lourdes et une expérience utilisateur incohérente. Shorebird est conçu pour des mises à jour fréquentes et légères, avec une taille d'environ 6 Mo pour une application complète d’après les mesures d’Adrien.

Quant au pricing, il est basé sur le nombre de patches et d'utilisateurs, ce qui peut s'avérer coûteux pour les applications à grande échelle. 

Par ailleurs, quelques limitations sont à noter  :

• Impossible de patcher du code natif ou des ressources, uniquement du code Dart
• Signature des patches pour plus de sécurité
• Pas de déploiement progressif (peut être géré manuellement)
• Pas de déploiement on-premise (prévu dans la roadmap)
  

En résumé, Shorebird offre une solution efficace pour les mises à jour OTA, tout en respectant les directives des stores et en minimisant les perturbations pour les utilisateurs. Merci à notre speaker pour cette présentation d’un outil qui servira à beaucoup d’entre nous, j’en suis sûre !

Conclusion

La même ville, le même lieu, de nouvelles conférences, une organisation et une équipe toujours au top, des conférences de qualité, ces mêmes ingrédients qui font de cette édition une nouvelle réussite !A l’année prochaine ? ;-)