Hey 👋
Moi c’est Vanessa et je suis l’autrice de la newsletter FLutterFlow n°1 en France.
Mon intention est de rendre la création d’application mobile possible en t’expliquant tout ce que je sais. Car le dev mobile j’adore ça mais ce que j’aime surtout c’est de le rendre simple (sinon on s’arrache un peu les cheveux parfois souvent).
Au programme de cette édition :
😎 L’actualité de FlutterFlow
💬 Ne pas se faire couper
🤩 L’actu FlutterFlow
Mieux travailler avec FlutterFlow
On peut désormais modifier la couleur de fond du builder, c’est vraiment très pratique pour concevoir les composants surtout s’ils sont transparents. A lieu de devoir définir un background inutile, on peut laisser le fond transparent. On évite de dupliquer du code et une maintenance plus lourde.
Des animations aux petits oignons
Une amélioration significative dans la création d’animation avec la possibilité de donner des valeurs dynamiques aux propriétés d’une animation comme la durée, le délai et les positions de l’élément.
Amélioration de la gestion des branches
Pour les bénéficiaires du plan Team, on peut maintenant modifier le nom des branches après la création. Même si cette évolution n’est pas incroyable en soit, elle montre l’envie d’améliorer le travail de collaboration par l’équipe FlutterFlow.
Un postionnenment de plus en plus clair dans l’écosystème
La conférence donnée par Leigha Reid à la Flutter Connection est disponible sur Youtube (ici, en anglais).
Une interview complète de Leigha est disponible sur la chaine Youtune FlutterFLowFab.
En résumé, elle est directrice produit et elle a présenté le fonctionnement de la génération de code par FlutterFlow. Sujet qui a grandement intéressé le public de dev présent. Mon ressenti est que les développeurs et développeuses sont de plus en plus intéressé.es pour intégrer FlutterFlow dans leurs stack technique. Plutôt une bonne nouvelle pour les dev nocode qui se spécialisent en FlutterFlow et les CEO qui craignent de ne pas pouvoir faire évoluer leur projet vers FlutterFlow.
Il y a quelques mois, j’aurais dit que c’était encore difficle de trouver un dev Flutter qui veuille bien reprendre un développement FlutterFlow. Assurément, cela change.
L’autre point très intéressant de la conférence est l’auto définition de Flutterflow comme un environnement de développement visuel plus qu’un outil low code.
Wahou ! Bon ça en jette dit comme ça mais qu’est-ce que ça veut dire concrètement ?
Je résume rapidement :
les outils low code ont un haut niveau d’abstraction parce qu’ils gèrent beaucoup de choses pour nous comme la gestion d’état ou la reconstruction des composants et des pages
Haut niveau ? Bas niveau ?
Le code de haut niveau est abstrait et proche du langage humain, facilitant la programmation, tandis que le code de bas niveau est détaillé et proche du langage machine, offrant un contrôle précis sur le matériel.
le problème, c’est que cela fonctionne comme une boite noire : on ne sait pas comment ça fonctionne et on ne peut pas y toucher.
Résultat : on sacrifice la qualité ou la finesse de fonctionnalités, voire les deux.
Pour se démarquer, FlutterFlow crée sa propre catégorie : le développement visuel.
Le rôle de FlutterFlow est d’ajouter une “légère” abstraction sur Flutteren permettant de créer les use case facilement tout en donnant la possibilité de plus de contrôle.
C’est moi ici qui met des guillemets à “légère” 🧐.
La question qui a été posée lors de la conférence est : d’accord mais quelle est la cible ?
Bien comme FutterFlow l’avait annoncé dans sa roadmap 2024 : E-V-E-R-Y-B-O-D-Y !
Littéralement. Sauf que tout le monde va pouvoir utiliser l’outil à différents niveaux.
Et différents stades d’avancement aussi.
Ce que tu dois savoir sur les textes
J’ai fait pas mal audits ces derniers temps et dans tous les audits, il y a une erreur sur les textes qui revient quasiment à chaque fois.
Avant de continuer, je vais commencer pas un warning : c’est normal !
Il s’agit pas de distribuer des bons et mauvais points. C’est complètement normal d’avoir des erreurs, des oublis, des ratés. Plus vous allez gagner en experience et mieux vous allez les anticiper mais :
ça ne sert à rien de se flageller, il faut juste apprendre, re-ajuster et avancer
vous n’obtiendrez jamais le zéro bugs.
Je vois souvent des ‘je vous garantis 0 bugs’, ‘mes estimations sont garanties à la minutes près” sur Linkedin.
Spoiler ! Ca n’existe pas. Si vous en êtes là, c’est que vous n’avez pas encore commencer à apprendre.
Je n’ai jamais vu ça et quand je parle avec des dev, que ce soit en code ou no code, ce sont toujours les mêmes problématiques. On avait pas prévu ça, finalement c’était plus compliqué, on a pas eu le temps.
Et ça ne changera pas. Parce que développer, c’est résoudre des problèmes. Chaque jour. Si vous n’aimez pas ça. Vous n’êtes pas au bon endroit.
Fin du warning.
Bon, on s’occupe des textes maintenant.
Les textes, c’est un sujet majeur parce que c’est globalement ce qu’il y a le plus dans les applications. Et de fait, on les délaisse un peu.
L’erreur la plus courante : les textes coupé avec un bel overflow.
Pour anticiper, il faut les traiter comment s’il était long très, long. Systématiquement, sans se poser de question.
Avec la nouvelle fonctionnalité du UI display builder, c’est très simple de tester ce cas d’affichage même dans le cas d’un texte issue d’une donnée.
Pour éviter qu’un texte ne dépasse de l’écran (ou de son contenant) et soit coupé, on peut lui définir 2 propriétés.
AutoSize
MaxLines
Ou les 2 combiné
Globalement, on réserve l’autosize dans le cas d’un affichage unique et non pour des éléments d’une liste. Le rendu ne serait pas très joli.
Dans tous les cas, ces deux propriétés ne seront prises en compte que si l’expansion du texte est gérée.
Le texte est alors encapsulé dans un Widget Expanded, qui lui permet de délimiter le retour.
Cela va devenir un automatisme pour chaque texte.
À bientôt
Vanessa
P.S. : Tu peux me partager ta problématique du moment avec FlutterFlow en répondant à cet email. Je pourrais traiter ta question dans une prochaine édition.