Du 3 au 5 juillet 2024 s’est tenue la 2ème édition de la FlutterCon europe. Cette conférence a lieu à Berlin, au même moment et dans le même bâtiment que la DroidCon. 

L’événement a rassemblé plus de 2000 participants sur 3 jours, avec 4 tracks de talks permettant à une centaine de speakers de présenter 90 sujets.

Les conférences sont toutes en anglais puisque les speakers et participants viennent de toute l’Europe, voire d’autres continents.

Ces trois jours ont été l’occasion pour moi d’apprendre et découvrir de nombreuses choses. Je les ai présentées lors d’un meetup Flutter à Nantes dont la vidéo est disponible sur Youtube (les slides sont ici). 

Je vais maintenant essayer de résumer tout cela dans cet article.

La navigation avec go_router_builder

Pour gérer la navigation sur une application Flutter, plusieurs librairies existent : Navigator (une version light de navigation), go_router, auto_route… Etant habituée à utiliser go_router, j’ai été surprise d’apprendre que go_router_builder existait. Cette librairie a été présentée au cours de 2 présentations, un format “quicky” présenté par Matej Rešetár de Leancode et un talk plus long par Max Weber, qui ont permis de découvrir cet outil.

Son principe est assez simple : go_router_builder se branche au dessus de go_router (il faut donc importer les 2 dépendances dans le projet). Il est ensuite utilisé pour générer le code nécessaire au routing de l’application, grâce à diverses annotations. L’illustration suivante présente le code de routing d’une application, avec et sans go_router_builder.

Il évite ainsi du code redondant, notamment lors de passage d’arguments à des routes, et apporte une écriture simplifiée pour gérer les changements de route. Cependant, comme tout outil de génération de code, il nécessite une phase d’apprentissage légèrement plus longue puisqu’il faut apprendre à maîtriser ses annotations pour pouvoir s’en servir. 

Comment gérer les fichiers générés ? Les conseils d’Anna Leushchenko

Comme vu précédemment, un projet Flutter peut rapidement contenir plusieurs fichiers de code généré, comme c’est le cas pour de nombreuses technologies. Le fait de ne pas analyser ces fichiers est assez courant, puisque les erreurs de lint relevées sur du code généré ne pourront par définition pas être corrigées, à moins de mettre à jour la librairie en charge de la génération du code. Cependant, Anna – experte Dart et Flutter chez Google – avait quelques conseils à prodiguer qui peuvent malgré tout surprendre. 

J’ai par exemple été étonnée par sa suggestion de committer ces fichiers générés. Cela apporte de nombreux avantages, comme un gain de temps lors changements de branches dans le projet : plutôt que de récupérer toutes les dépendances ET générer le code associé, il n’y aura alors besoin que de récupérer les dépendances. Grâce à cela on gagne donc du temps du côté des développeurs, mais également sur la CI qui ne devra plus générer ces fichiers pour exécuter ses différentes vérifications, puisqu’ils font déjà partie intégrante du code.

Néanmoins cette pratique peut aussi amener son lot de complications, comme par exemple des conflits sur ces fichiers générés ou des décalages entre le fichier d’origine et le code généré, puisqu’il faudra penser à lancer manuellement la génération de code lors de chaque modification sur un fichier qui comporte du code à générer.

Anna nous a également conseillé de fixer les versions des dépendances dans nos applications et librairies, afin d’éviter d’avoir des décalages selon l’environnement de développement, à cause d’une dépendance qui ne serait pas résolue de la même manière. Ce fameux effet du “je ne comprends pas pourquoi ça ne fonctionne pas chez toi : ça fonctionne bien chez moi pourtant !”. Elle conseille donc d’avoir un fichier de dépendances qui ressemble à cela (sans “^ » devant les numéros de version).

Dans la même thématique, elle a rejoint les conseils fournis par l’équipe Flutter : committer les fichiers pubspec.lock des applications, et non des librairies, là encore pour maîtriser au mieux les versions des dépendances utilisées dans le projet.

Comment faire pour que mon application soit agréable visuellement ?

D’après Maxime Rougieux et Thomas Coumeau, développeurs Flutter chez Theodo apps, un bon MVP (Minimal Viable Product) doit comprendre :

• 70% de fonctionnalités métier : c’est le coeur de l’application
• 20% d’UX (User Expérience) : l’application doit être agréable à utiliser, les parcours clairs et simples pour les utilisateurs
• 10% “d’effet waouh” : ce sont tous les petits effets visuels qui font le petit plus de l’application, comme les animations notamment 

Ces chiffres représentent un MVP idéal. La pratique est souvent différente puisqu’il faut prendre en compte le budget du projet, le temps qui peut être passé… Ils ont plutôt représenté la réalité avec ce schéma :

On y retrouve : 

• Un besoin de fonctionnalités métier : nécessaires au fonctionnement de l’application, d’un point de vue business
• Une petite part d’expérience : l’application doit être fonctionnelle
• Une grande contrainte portée par ce qui peut être fait dans le temps imparti, qui dépend de la taille de l’équipe et du budget alloué au projet

Cet “effet waouh” a complètement disparu de ce schéma, alors que certaines animations peuvent être implémentées facilement. Cela peut prendre peu de temps aux équipes et apporter une expérience satisfaisante lors de l’utilisation de l’application.

Lors de leur présentation, Maxime et Thomas nous ont parlé de différents widget Flutter permettant de faire des animations simples comme : 

• l’AnimatedContainer, utilisé pour faire des petites animations sur un widget en modifiant sa taille ou sa couleur dynamiquement (pour plus d’infos n’hésitez pas à consulter la documentation Flutter : https://api.flutter.dev/flutter/widgets/AnimatedContainer-class.html)
• le Hero, qui là encore est assez simple à mettre en place et a également l’avantage d’être positif en terme d’accessibilité puisqu’au lieu d’avoir un widget qui disparait et réapparait à un autre endroit, il va se déplacer vers sa nouvelle position sur la page ce qui permet d’être un peu moins perdu lors d’un changement de contexte. Là encore la documentation Flutter sur le sujet est très complète : https://docs.flutter.dev/ui/animations/hero-animations

Les nouveautés graphiques apportées par Flutter 3.24 

En terme d’animation, Flutter 3.24 arrive également avec de nombreux changements. Cette version est sortie début août 2024, vous la connaissez donc peut-être déjà, mais elle n’était pas encore sortie début juillet. La FlutterCon a donc été l’occasion pour l’équipe de Material de présenter ses nouveautés. 

Les principaux ajouts en terme de graphisme concernent : 

• des modifications apportées sur les ColorScheme, permettant de mieux créer et gérer les palettes de couleurs utilisées dans l’application
• les Button builders, qui permettent d’appliquer de nouveaux effets de style sur le boutons selon leur état (pressed, hover, disabled…). Tout est embarqué au niveau du ButtonStyle, comme détaillé dans la doc : https://api.flutter.dev/flutter/material/ButtonStyle-class.html  
• le CarouselView, nouveau composant intégré dans la librairie, permettant de créer des carrousels en Flutter. Jusqu’à maintenant il n’existait pas de support de la communauté sur ce sujet, il vient donc élargir le panel de composants supportés par Flutter

Quelques sujets en vrac

Les trois jours de conférences ont été très dense, il me semble impossible de résumer tout ce que j’y ai vu dans un article (ou alors il va vite devenir indigeste). Voici donc quelques recommandations de sujets que j’ai trouvés particulièrement intéressants, si vous souhaitez les approfondir : 

• Lucas Goldner de Youtrust nous a parlé de la restauration d’état lorsqu’on quitte une application (cela concerne uniquement le cas où elle passe en background dans le téléphone, pas quand elle est complètement fermée) dans son talk “Saving data before the app getting killed! Easy state restoration with Flutter”
• Nous avons appris comment Bruno Reginato, Csongor Vogel et Lucas Britto, 3 développeurs de Delivery Hero (l’équivalent de Uber Eats aux Emirats Arabes Unis) ont migré leurs apps natives en Flutter grâce à leur sujet “Migrating 2+ Million daily users to Flutter with 50+ Engineers”
• Parce qu’il n’y a pas eu que des présentations sérieuses, Moritz Theis et Payam Zahedi de Snapp nous ont présenté leur distributeur de M&M’s codé en Flutter. Ils ont embarqué Flutter sur un raspberry pi, branché à une tablette sur laquelle on peut jouer à un jeu pour déclencher l’ouverture des distributeurs de bonbons. Ils détaillent leurs travaux dans le talk “M&Ms your way: build a fun, Flutter-Powered candy dispenser on Raspberry Pi 5”
• Enfin, Roaa Khaddam de Widgetbook nous a montré comment faire de l’art en Flutter… et honnêtement c’était bluffant ! Elle crée des visuels magnifiques via des applications Flutter. Son talk ne peut pas être résumé par des mots mais plutôt par des images, et pour cela il faut aller voir “Code meets art: Flutter for creative coding”

Tous les talks que j’ai cités précédemment, et beaucoup d’autres, sont disponibles sur le site de la droidcon.

Conclusion

Je reviens ravie de cette expérience à Berlin. Je tiens à remercier les organisateurs de la FlutterCon et DroidCon pour leur travail et leur investissement pour rendre ces 3 jours si mémorables. Merci également à Zenika de m’avoir permis d’y assister.