Place ! je m’incruste !
Cet article fait partie d’une série sur les solutions mobiles:
En guise d’introduction, voici le résumé sur Flutter, la solution open-source cross-plateforme mobile de Google, de l’article précédent:
Flutter est codé en Dart, un langage peu répandu ce qui constitue un frein en termes de recrutement et de développement d’une communauté. Il possède cependant un catalogue de composants graphiques plus conséquent que React Native, et est développé par Google, ce qui rassure sur sa viabilité.
Contrairement aux solutions précédentes, Flutter n’utilise pas des “conversions” de code en natif mais crée son propre moteur de rendu/interaction, ce qui le rend plus indépendant aux changements des changements de plateformes.
Depuis cette article, Flutter est arrivé en version de production 1.3.8 !
Mais ne vous inquiétez pas, cette description reste valide.
A la fin de l’article, vous saurez:
- son périmètre d’action,
- les avantages et désavantages,
- son fonctionnement.
Encore un …
Flutter est donc une solution cross-plateforme mobile:
1 code = 1 app Android + 1 app iOS
Attention !
le design est unique entre les plateformes: c’est du Material Design. Si vous voulez utiliser le style iOS, vous devrez utiliser des widgets (composants) spécifiques à la plateforme mais vous perdrez en mutualisation …
Pour le moment, la liste des plateformes supportées est courte (Android, iOS) mais Flutter veut à terme générer aussi des sites webs (/PWA)
A noter que Dart est un langage web donc vous pouvez déjà mutualiser une partie du code logique avec votre site web (pour le moment 40% avec l’application opensource inKino).
J’apprends des erreurs des autres
Flutter a analysé les erreurs de ses concurrents et a pris le meilleur de chacun:
- de Xamarian.Forms: la simplicité de l’app pour créer/prototyper le plus rapidement possible,
- de React Native: la facilité du développement avec l’archi type Redux et le “Tout Component”,
- de React Native (2): l’intégration dans une application existante (cf Alibaba Xianyu)
- de Ionic: la technique de la coque native pour les fonctionnalités natives avec le reste géré par leur boîte noire
Ses objectifs avoués sont:
- Productivité: moins de code, moins de classe, du hot reloading pour du dev en live
- Beauté: des animations performantes pour se démarquer des autres.
- Simplicité: des éléments de base (texte, image, liste) mais pas de notion complexe (prefetching, databinding, …)
Il ne souhaite pas remplacer les applications natives mais répondre au besoin d’avoir une application multiplateforme rapidement (prototypage, application simple). Nous sommes à la limite de ce que propose les PWA (Progressive Web App) mais avec l’accès aux fonctionnalités spécifiques natives en plus.
Un point intéressant à retenir est la volonté d’être facilement intégrable dans une application native existante (“Add to App”) et vice-versa (“Platform Views”).
Vous pourrez ainsi mutualiser certains écrans non vitaux d’une application native en Flutter ou injecter des composants natifs dans une application Flutter un peu à la manière d’une iframe.(l’exemple donné est la carte google maps native)
Diviser pour mieux régner
Dans ce contexte, Flutter fragmente encore un peu plus l’écosystème Actuellement, chaque solution est pertinente pour un cas spécifique (du Xamarin dans un contexte Microsoft, Ionic si vous possédez des développeurs Web, …).
Mais en regroupant pas mal de concepts qui font mouche, Flutter va en faire douter plus d’un et nous verrons des abandons de projets. (React Native peut-être ?)
Les pros et les cons
Les +
- c’est du Google: de la qualité.
- une communauté jeune mais dynamique (cf apps open source disponible)
- une bonne documentation et déjà de nombreux tutoriels
- intégration de Flutter dans une application existante (cf Alibaba XianYu app — vente d’occasion — pour la page itemDetails et itemPosts)
- intégration de composant natif dans Flutter (iFrame style avec “Add to app”)
Les -
- Dart, un nouveau langage à apprendre
- une technologie pas encore mature et qui continue d’évoluer
- peu de plugin pour le moment
Une coque qui renferme tout un univers
Si vous avez lu l’article précédent sur Ionic, vous pouvez faire certains parallèles:
- une coque native qui appelle un composant principal (moteur C++ pour flutter, webview pour Ionic)
- un contenu spécifique à cette “boîte noire” (du code Dart pour Flutter, un site web pour Ionic)
- un pont entre les deux pour les besoins spécifiques (pont pour Flutter, pont javascript pour Ionic)
Mais la grosse différence (outre le langage, le type de coque, …) est que Flutter développe son propre moteur (C++) alors qu’Ionic est dépendant du navigateur encapsulé fourni par la plateforme.
State machine et Widget tree
Concernant l’architecture, cela s’oriente beaucoup vers une machine à états (comme React/Native) puisque les applications sont censées être simples.
Une action de votre part n’attendra pas une réponse directe mais déclenchera une série d’événements qui fera évoluer l’état de votre app et donc l’affichage. L’avantage de ce flux unidirectionnel est de permettre la gestion des événements: pile d’actions dépilable (undo/redo), 1 seul sens Action — Reaction — Mise à Jour, ….
D’ailleurs, la librairie Flutter Redux vous permet justement d’organiser tout cela avec les bons outils.
Si vous le souhaitez, vous pouvez quand même faire du MVC, MVI, MVP …
Côté interfaces graphiques, on reste dans cet esprit de machine à état: votre classe sera une très longue liste de widgets (= composants), sous la forme d’un arbre. Chacun aura un état pour savoir si il doit être mis à jour ou pas (et donc optimiser les rafraîchissement des écrans):
- StatelessWidget: son contenu, ses valeurs ne sont pas modifiés
- StatefullWidget: un texte qui est mis à jour à la suite d’un clic
Dart, le langage web
Dart est un langage web maison Google.
Ce choix peut sembler bizarre: pourquoi ne pas choisir Kotlin ?
Mais il est logique (langage maison, performance, modernité) et aussi lié au fait que certains des ingénieurs Flutter ont travaillé sur le fameux moteur web javascript V8 embarqué par Chrome (mais aussi utilisé par node.js …)
Cela permettra peut-être de lancer ce langage encore peu répandu (23eme sur Tiobe). Malheureusement, cela aura un impact sur l’adoption de Flutter et le recrutement.
Par conséquent, il est préférable de former un développeur mobile grâce à la bonne documentation (apps, tutoriel, …) que d’en chercher un !
Je le rejoins ?
Oui si:
- votre besoin est simple ou orienté vers des animations 2d sympa
- vous avez des développeurs mobile motivés pour se former
- vous souhaitez (bientôt) mutualiser une partie de votre app
En résumé,
avec Flutter, Google ne cherche pas à révolutionner le dév mobile mais plutôt à se positionner sur le marché des solutions hybride mobiles (pour des apps simples et multiplateformes)
Flutter est qualitatif et répond à vos besoins simples (prototypes, multiplateforme, app formulaires, …). Malheureusement, le choix du langage Dart risque d’être un frein à son adoption.
Si vous souhaitez vous faire une idée de la complexité des apps Flutter existantes, c’est par là: https://itsallwidgets.com/
Epilogue
Avant de nous quitter, comme pour les articles précédents, je vous propose de regarder ensemble une application open source Flutter inKino.
inKino est une application d’information sur des salles de cinémas finlandais: sélection d’un cinéma, liste des films présents, films à venir, …
L’application a un design simple (+Archi Redux) mais elle permet de démontrer la mutualisation à 100% entre Android et iOS et à 40% avec le site web (PWA).
Et les sources sont disponibles donc si vous êtes un peu techos, n’hésitez pas à y jeter un coup d’oeil !
Ressources de l’article
Les classiques
Flutter: https://flutter.io/
Showcase: https://flutter.io/showcase
Liste complète de showcases: https://itsallwidgets.com/
Dart: https://www.dartlang.org/
Pour aller plus loin
Awesome Flutter: https://github.com/Solido/awesome-flutter
Apprendre Flutter: https://flutter.io/docs/cookbook
Apprendre par l’exemple: https://flutterbyexample.com
