Flutter Connection ‘23 : retours sur les talks de la première édition

Si vous suivez l’actualité de l’univers du développement d’applications mobiles, et notamment des applications cross-platform, il y a de fortes chances que vous ayez entendu parler de la première édition de la Flutter Connection, qui s’est déroulée le 02 juin dernier à Paris.
Aujourd’hui je vous propose un petit condensé de cette journée riche en conférences à laquelle j’ai pu assister avec d’autres Kalioppien.ne.s de choc, venu tout droit de Montpellier.

Tout d’abord, l’organisation et l’animation

“The French Flutter Conference” se tenait cette année à la Pan Piper dans le 11ème arrondissement de Paris. Une salle assez agréable que je découvrais, à un peu moins de 30 minutes à pieds de Gare de Lyon, avec une très bonne acoustique qui permettait de bien suivre les talks, une grande salle de réception pour les différentes pauses café et repas bien méritées en compagnie des speakers, et même une petite terrasse pour profiter de quelques rayons de soleil avant de repartir dans la salle obscure.
Et goodies sur le gâteau : un stand avec pleins de cadeaux des sponsors (t-shirts, peluches, stickers, tote-bags, pins, …).

La conférence était portée par La Tech Connection qui organise des événements autour de l’écosystème mobile, comme par exemple la React Native Connection qui se tenait la veille. Ils étaient accompagnés cette année d’Edouard Marquez (co-créateur de la communauté Flutter France, rédacteur de l’iconique et regrettée Flutter Digest et animateur de la chaîne Youtube Dev Café), de Simon Bernardin (lead dev mobile et co-organisateur de Flutter Nantes) et de Guillaume Diallo-Boisgard (Head of Flutter).

Après un accueil des plus chaleureux pour la remise des badges et une première dose de café pour réveiller les moins matinaux (accompagné d’un croissant bien entendu), nous avons eu l’honneur et le privilège d’assister à un démarrage en grandes pompes avec un mot d’accueil de Sundar Pichai (CEO de Google et Alphabet) … ou enfin presque quoi … vantant à juste titre les mérites de Flutter et des croissants comme nourriture officielle pour un Dash (mascotte Flutter) performant.
Ce trait d’humour passé, nos hôtes du jour ont orchestré avec panache les introductions aux talks, les temps de pause pour la préparation et les sessions de questions / réponses pour nous offrir un moment très agréable et avec une réactivité digne de Flutter lors des incidents techniques.

Les talks

Je n’imagine même pas la difficulté à la lecture des sujets lors du CFP quand je vois les noms et les talks annoncés au line-up de cette édition. Nous vous en parlerons de manière plus approfondie dans différents articles dédiés à certains sujets, mais voici déjà un premier tour d’horizon global.

REX Flutter

L’ouverture s’est faite avec un point non technique, mais très informatif, de Marek Kalnik sur l’historique de Flutter et son adoption au sein de son entreprise. Un REx étonnamment non commercial et assez enrichissant.

Rendre votre base de code plus facile à maintenir

Ensuite, alors qu’on aurait pu s’attendre à quelques talks assez basiques sur Flutter, son approche et ses avantages, nous avons finalement démarré directement dans les sujets techniques assez avancés.

Âmes sensibles et en découverte de Flutter, s’abstenir !

Voici venir Rémi Rousselet, notre Flutter frenchy préféré (#cocorico), Flutter software engineer, pour un talk, non pas sur le célèbre package Riverpod, mais sur custom_lint, un package pour définir nos propres règles d’alerte et de formatage de code.
Il fonctionne sur le même principe que Dart Code Metrics par exemple, à la différence qu’il nous permet d’écrire nous-même notre set de règles qui seront utilisées par l’analyzer Dart. Une fois définies, ces règles permettent de mettre en évidence les problèmes de formatage et de définir des suggestions et des quick fixes directement dans votre IDE préféré.
Une excellente découverte que nous ne manquerons pas d’utiliser très prochainement dans nos projets.

Rendre vos applications Flutter accessibles

La matinée s’est ensuite poursuivie avec un sujet que nous évoquons souvent chez Kaliop au travers de webinars, de meetups, de formations internes et d’articles : l’accessibilité du numérique.
Mais cette fois-ci, ce n’était ni Chloé, ni Claudine aux commandes, mais plutôt Akanksha Singh (alias Coder jedi), software engineer, qui nous (re)donnait les bonnes pratiques et les standards pour une meilleure inclusion dans nos applications mobiles. Nous avons donc revu les concepts de contraste, de variations de typographie, de descriptions lors des call to actions, …
Et plus précisément pour Flutter, Akanksha nous a parlé des classes Semantics pour ajouter du contexte à nos widgets, et notamment des MergeSemantics et ExcludeSemantics pour apporter un contrôle plus fin à notre widget tree.
Personnellement, je suis curieux de pouvoir explorer le sujet plus en profondeur.

Le monde des plugins Dart-Only

Pour la suite de cette première moitié de matinée, autant vous dire qu’il fallait être bien concentré. En effet, Renan Araujo a pris la suite pour nous parler du développement de plugins pour Flutter. Mais pas de n’importe lesquels ! Des packages capables de discuter avec les couches natives de nos appareils. Et comme si le sujet n’était pas assez pointu, il nous a présenté tout cela en Dart-Only.

La discussion entre le code Dart de notre application passe normalement par plusieurs couches qui ne communiquent que directement entre elles (codebase ⇔ framework ⇔ engine ⇔ embedder ⇔ runner).
Dans ce talk, Renan nous a montré comment, grâce aux Foreign Function Interface (FFI) et aux bindings JNI, il est capable de développer un package pur Dart qui interagit avec les couches C++ du moteur et/ou les librairies natives du système d’opérations.
Tout un monde d’extensions qui s’ouvre à nous.

Flutter sur le bureau : de bout en bout, de la conception à la distribution

Après une pause café bien méritée pour se remettre de nos noeuds aux neurones, c’est Teresa Wu, VP engineer, qui a pris la suite pour nous rappeler une des premières choses qui font la force et la popularité de Flutter : le multi-plateforme !
Il ne s’agit pas ici de parler que du côté cross-platform des applications mobiles, mais aussi de rappeler que les applications Flutter se portent aussi bien sur le web et le desktop et ce, out-of-the-box.
Pour ce faire, elle nous a présenté les étapes clés pour avoir une configuration correcte sous MacOS, Linux et Windows, ainsi que comment distribuer les artefacts finaux pour chacune de ces plateformes.
J’ai été un peu déçu de ne pas avoir pu discuter de retour d’expérience car le sujet était entièrement théorique. Mais quoiqu’il en soit, c’est une affaire à garder fortement à l’œil.

Dart FFI avec Rust

Le titre parle de lui-même. Muhammed Salih Güler nous ramène dans l’univers des packages et de la communication entre le code Dart et les autres couches plus bas niveau. Mais là encore, le but est d’uniformiser et de simplifier le cross-platform en s’appuyant cette fois-ci sur Rust, langage compilé multi-paradigme bas niveau à haute performance.
En s’appuyant sur sa folie (et quelques bières), il nous a parlé de l’interaction entre FFI et Rust, de l’utilité de ne pas cibler directement l’OS pour plus de portabilité, et des bridges utiles pour notamment sérialiser / désérialiser des objets complexes.

Écrire visuellement des logiques métier complexes avec Flutter et FlutterFlow

Pour conclure cette matinée dans une ambiance décontractée, pleine de fun et d’entrain, nous avons eu le plaisir d’accueillir Pooja Bhaumik, DevRel.
Ce fût l’occasion pour moi de redécouvrir cette plateforme de no-code, ou plutôt devrais-je dire low-code maintenant vu son potentiel.
Le projet existe depuis déjà un moment et je le savais excellent pour mettre en place rapidement une interface utilisateur en Flutter, sans avoir à se frapper de toute la verbosité du widget tree. Mais Pooja nous a amené bien plus loin dans l’usage en intégrant des logiques complexes de validation de champs, un interfaçage avec Firebase, une authentification, …
Lors de cette démonstration, elle a pu mettre en place un Kahoot-like auquel nous avons même pu jouer en fin de session (j’ai même fièrement terminé dans le top 10 et ai pu récupéré un lot #tropfier).
Une présentation très punchy qui va peut-être nous faire revoir un peu l’usage que l’on peut avoir de telles plateformes dans notre productivité.

En route vers Dart 3

À la délicate place du premier talk de l’après-midi, là où tout le monde est sur la digestion, c’est Majid Hajian, Head of DevRel, qui est venu partager son énergie (et ses chaussettes) pour nous faire un rapide condensé de certaines évolutions liées à Dart 3.
Si vous sortez d’une caverne après avoir voulu battre le record du monde d’hibernation, vous avez sans doute vu la Google I/O ou au moins vu passer l’annonce de la sortie de Flutter 3.10 et Dart 3.
Si ce n’était pas le cas, Majid était là pour sauver votre veille. Et en parlant de record, c’était justement l’un des premiers axes de nouveautés : Record et Patterns.

Un Record est un type d’agrégat anonyme et immuable. Vous pouvez le comparer à une collection de taille fixe, hétérogène et typée. Un Pattern quant à lui représente la forme d’un ensemble de valeurs qu’il peut faire correspondre à des valeurs réelles. Je vous encourage fortement à suivre le code lab Google sur le sujet.
Cette combinaison était un parfait moyen pour amener à la destructuration (même de la destructuration nommée) avec différents cas d’usage dans des “switch” complexes.
Déjà séduit par les sealed classes et bien que la syntaxe puisse parfois rendre plus difficile la lecture du code à grand coup de “case” dans des “if” ou de “when” dans des “switch”, je pense que nous allons approfondir un peu l’adoption de ces puissants nouveaux outils après ces nouvelles explications.

Le cycle de vie d’un RenderObject

Alors que l’après-midi redémarrait sur un ton léger de découverte des nouveautés et bien que l’approche soit technique, le grand Craig Labenz, DevRel engineer , est venu nous rappeler que cette conférence avait un certain niveau à conserver sur la journée.
Bien que son talk ne concernait pas vraiment le quotidien direct des développeur.se.s Flutter, Craig nous a plongés dans les méandres du rendu des widgets en Flutter.
Je dis que cela ne nous concerne pas directement car beaucoup de points de cette session sont en réalité gérés par le framework lui-même. Mais il est toujours bon de rappeler ou faire prendre connaissance aux utilisateur.rice.s d’un outil de ce qui se cache sous le capot. Cela permet d’avoir une meilleure compréhension et d’envisager autrement sa façon de coder. Et pour le coup, objectif atteint !
De composants de Layout aux classes UI Paint et Canvas. De Shaders en Pixel Buffer? Ou encore via un excellent parallèle avec les composants Semantics abordés par Akanksha.
Nous avons pu avoir un excellent aperçu de tout le travail fourni par la Flutter team pour optimiser au maximum chaque milliseconde qui peut composer le cycle de rendu et réduire le temps de thread sur la trame (raster thread), auparavant connu sous le nom de thread GPU. Et ce faisant, Craig nous a même démontré ce travail via les comparatifs de performances entre Skia et Impeller, respectivement ancien et nouveau moteur de rendu de Flutter.

Sujets avancés avec les WebViews

Après cette plongée dans les pixels et les millisecondes, c’est Guillaume Bernos, développeur mobile, qui a pris la suite. Et on ne peut pas dire que le niveau soit retombé pour autant. Car par le biais d’un side-project qu’il a pu effectuer (espérons qu’il ne subira pas le même sort que tous mes propres side-projects qui n’ont jamais dépassé le stade du 80% de finalisation), il est monté sur scène pour nous apporter les clés d’une mise à disposition de webview (oui oui c’est encore un cas d’usage qui peut s’avérer très utile) correctement ajustée à une interface et pilotable (dans la limite du raisonnable) depuis sa codebase Flutter.
Du comparatif des librairies existantes sur le marché aux solutions de contournement de problématiques telles que les transitions, les dimensions, l’injection de police d’écriture ou encore le temps de chargement, en passant par des tests de librairies HTML to widgets, Guillaume nous a fait parcourir les étapes clés pour une intégration de webview réussie par le biais des bons réflexes et d’une touche de Javascript.

Attention à l’empreinte de votre application ! 🐾⚡🌱

Les batteries rechargées par une nouvelle injection de caféine, c’est l’équipe de SNCF Connect & Tech qui s’est emparée de la scène. En parlant de tout électrique, si vous vous demandiez combien il faut d’ingénieurs pour changer une ampoule réduire l’empreinte carbone d’une application aussi importante que celle de notre fleuron national, et bien apparemment la réponse est non pas 1, ni 2 mais bien 3 !

Là encore, l’éco-conception dans la conception de produits numériques est un sujet d’actualité qui a une forte importance au sein de Kaliop (Emmanuel Valluche, un de nos experts certifiés co-animera d’ailleurs un webinar le 27 juin à 11h).
Mais revenons-en à nos speakers eco-friendly qui ne sont pas montés sur scène à plusieurs juste pour faire illusion. Nous avons eu droit à un ensemble très complet de techniques, dont certaines en production et d’autres en recette, afin de diminuer l’empreinte carbone non pas uniquement de l’application, mais aussi de toute la chaîne de production, jusqu’à la surconsommation des terminaux finaux.

Il sont revenus sur leurs usages de Greenspector, ecoCode, Fruggr, … et autres outils d’analyse. Ils nous ont parlé tree shaking en Flutter, de chargement différé des plugins, d’optimisation pour les appareils low-end (smartphones vétustes, réseau faible, …) et la rétro compatibilité pour diminuer l’impact des achats en terme de matériel numérique.

En résumé, un panel varié et complet d’axes d’amélioration pour toutes les productions. Et quoi qu’on pense des services de la SNCF, c’est agréable de voir qu’une équipe comme cela se sent concernée par cette problématique d’impact écologique du numérique … et qu’elle ne prend pas ce train en retard #humourdepapa.

Des échecs de réseau au succès du hors ligne : le voyage de Visible App

Sans surprise dans le titre, c’est d’une success story qu’est venu nous parler Dominik Roszkowski, lead mobile engineer.
Cette histoire, est celle de leur application qui permet à des patients le suivi des maladies chroniques ou au long cours. Cette réussite, c’est plus précisément celle de la mise en place de la gestion du mode hors-ligne dans leur application Flutter après avoir essuyé les plâtres d’une première version entièrement dépendante du réseau.
Il est d’abord revenu sur l’architecture de l’application, dépendante d’un serveur Apollo GraphQL pour fonctionner. Puis sur la découverte de nombreux incidents dans les logs du crashlytics implémenté dans leur version, exceptions soulevées en grande partie par des pertes de réseau.

La suite est donc évidente : implémenter une base de données locales pour faire miroir à la base de données serveur et permettre à l’utilisateur d’utiliser l’application, même hors-ligne, de manière transparente.
Pour se faire, Dominik nous a donc parlé de BLoC, SQLite, détection de l’état du réseau, …
Dommage que la solution n’utilisait pas Riverpod, nous aurions pu avoir une grande discussion pour comparer nos solutions 😉

Une introduction au développement de jeux avec Flame

Felix Angelov ayant malheureusement eu un empêchement, c’est donc Lukas Klingsbo, open source engineer, qui a eu la lourde tâche de clôre cette journée très riche en contenu.
Il nous a donc présenté quelques méthodes de Flame, son moteur de jeu. Pour rappel, Flame est le seul moteur sur le marché compatible Flutter pour donner vie à nos petits personnages préférés de pixels. Nous avons pu en savoir plus sur la compatibilité avec les packages de player audio, de forge 2D, … sur la détection de collision, les effets de caméra, …
Je trouve juste dommage que tout ceci n’ait été que théorique et j’aurais apprécié une démo un peu tape à l’œil du potentiel de l’outil, notamment en terme de réalité augmentée.

En conclusion

En raison du retour en train programmé, nous n’avons pas pu participer à l’after party avec tous les speakers et je n’aurai donc pas eu l’occasion de plus faire mon fan boy de toutes ces grandes personnes de la communauté Flutter. Néanmoins, nous sommes repartis avec une motivation renouvelée et beaucoup de nouvelles idées pour nos futurs projets d’applications mobiles Flutter.
Et pour répondre aux propos d’introduction de Greg et Julien, deux des animateurs : s’il ne devait pas y avoir d’autre édition, celle-ci resterait à jamais la meilleure. Mais nous comptons sur vous pour que les prochains volets nous fassent dire que c’était la pire 😉