Démarrer un projet Flutter en venant de Xamarin

Chez Cellenza, nous sommes fiers de notre expertise sur les technologies Microsoft, mais nous attachons également une importance particulière à étudier et à tester d’autres stacks techniques. En effet, pour toujours conseiller au mieux nos clients dans leurs projets d’évolutions technologiques, nous nous devons de maîtriser les différences entre chaque plateforme de développement mobile.

En avril 2018, Maxime Eglem nous avait parlé de Flutter dans son article “Arbre décisionnel – quelle technologie pour mon projet mobile ?” où il décrivait cette technologie dite “à la mode”. Depuis, cette dernière a bien évolué : au mois de décembre de la même année, Google avait sorti sa première version stable puis a continué à livrer des releases de manière régulière afin d’améliorer le framework.

Au moment où je vous écris cet article, Flutter fait toujours autant parler de lui. Je vous invite d’ailleurs à découvrir l’article de présentation de Flutter si vous ne maîtrisez pas encore bien cette technologie.

Ce framework n’est plus une technologie en devenir puisqu’elle est utilisée par de grands groupes comme Tencent, The New York Times, BMW, Alibaba ainsi que Google.

Dans cet article, je vous accompagne donc dans le démarrage de votre projet mobile Flutter en répondant à l’ensemble des questions types que vous pourriez vous poser et cela tout en gardant mon point de vue développeur Xamarin.

Mise en place de l’environnement Flutter

Avant de pouvoir utiliser le framework, il va falloir l’installer. Comment installer Flutter ?

La documentation étant bien complète, il vous suffit de vous rendre sur cette dernière et d’effectuer les étapes nécessaires. Bien qu’il puisse avoir des variations selon votre OS, de manière générale les étapes en question sont les suivantes :

• La récupération et l’installation du SDK,
• L’ajout de Flutter dans la variable d’environnement PATH,
• La vérification de la validité de l’environnement.

Nous ne listerons pas les commandes adéquates pour éviter un duplicata de la documentation. Pour le reste, il est bon de savoir qu’un développeur Xamarin, habitué à concevoir des applications mobiles, devrait d’ores et déjà avoir le restant de l’environnement (Xcode, Android’s SDKs, emulator, simulator) à sa disposition.

Enfin, la dernière étape de la mise en place de votre environnement est de choisir l’éditeur de code de votre choix pour créer votre nouveau projet Flutter. En effet, à l’instar de Xamarin avec Visual Studio, Flutter donne la possibilité d’utiliser divers éditeurs de code comme Android Studio, IntelliJ, Visual Studio Code ou Emacs.

Structuration de votre projet Flutter

Pour chaque type de projet sur lesquels nous travaillons, il est toujours important d’avoir une certaine structuration du dossier « root ». Ainsi, cela permet à l’équipe de développement de retrouver facilement certaines entités comme les modèles, les vues, les services et tous autres éléments à modifier. Mais il y a-t-il une structuration type à suivre pour les projets Flutter ?

La structuration type

Par défaut, un projet Flutter contient les dossiers suivants :

android/

ios/

lib/

test/

Comme vous pouvez le constater, nous avons un dossier par plateforme (android et ios), un dossier qui contiendra le code commun (lib) et un dernier dossier dans lequel on retrouvera l’ensemble des tests (test). Du côté de la documentation ou des articles officiels, aucune directive n’est donnée. Il va alors falloir nous tourner vers les développeurs expérimentés sur ce framework pour bénéficier de leurs retours d’expériences sur ce sujet.

De manière générale, on retrouve souvent dans “lib” des dossiers supplémentaires ayant la nomination suivante :

// Dossiers comportant les éléments de l’UI

screens

widgets

theme

assets

fonts

 

// Dossiers comportant les éléments de la logique business

utils

models

services

managers

 

// Dossiers comportant les éléments permettant de gérer la gestion d’état

blocs

data

Il est également conseillé de sortir les widgets uniques d’un écran (screen) et de les placer dans un sous-dossier “unique_widgets” afin de simplifier le code de l’écran en question, mais aussi pour faciliter les futures modifications. En effet, si l’on souhaite supprimer le widget ou le rendre commun entre plusieurs écrans, l’avoir isolé facilitera l’opération. On se retrouve donc avec un dossier “screens”, présenté comme suit :

screens/ 

– – feature_name/ 

– – – – screen_name_one.dart 

– – – – screen_name_two.dart 

– – – – screen_name_three.dart 

– – – – unique_widgets/ 

– – – – – – unique_widget_name_one.dart 

– – other_screen_name.dart 

– – unique_widgets/ 

– – – – unique_widget_name_two.dart 

Vous l’aurez peut-être remarqué dans l’exemple, certains écrans et widgets uniques ont été encapsulés dans un dossier “feature_name”. C’est d’ailleurs une seconde bonne pratique à effectuer, notamment lorsque le projet devient conséquent et que l’on se retrouve avec un trop gros nombre d’écrans.

A partir de ces informations, nous pouvons définir une structuration de projet qui contient tous les points importants :

android/ 

ios/ 

lib/ 

– – assets/ 

– – fonts/ 

– – managers/ 

– – models/ 

– – screens/ 

– – – – feature_name/ 

– – – – – – unique_widgets/ 

– – – – unique_widgets/ 

– – services/ 

– – theme/ 

– – utils/ 

– – widgets/ 

test/ 

Vous trouverez également d’autres façons de faire. En effet, certains développeurs regrouperaient intégralement leurs codes par feature et non par module comme il est appliqué dans l’exemple ci-dessus.

Les Design Patterns de Flutter

Lorsque l’on utilise un nouveau framework, la question que l’on se pose tout naturellement est : quels sont les design patterns existants et lequel choisir ?

Pour répondre à cette question, il est important de comprendre qu’une application Flutter tourne autour d’une notion appelée gestion d’état (state management). Très rapidement, lorsque vous avancerez dans l’utilisation du framework, vous allez avoir besoin de partager l’état de l’application entre plusieurs écrans. C’est ce qu’on appelle la gestion d’état. Ainsi, l’utilisation d’un design pattern n’est pas une obligation puisque nous retrouvons également d’autres solutions qui ne le sont pas. La liste des approches possibles est donc plus qu’exhaustive :

// Major ones

Redux

BLoC

 

// Others

RxDart

MobX

Vanilla

Scoped Model

MVU

MVI

MVC

MVP

MVVM

… (et bien d’autres)

En tant que développeur Xamarin, se retrouver devant autant de choix peut-être un point bloquant. Dans cet article nous n’allons pas tous les présenter ou décrire leur contexte d’utilisation.

Néanmoins, il est conseillé pour une personne débutant un nouveau projet Flutter, de commencer le développement sans maîtriser parfaitement chacune de ces solutions. Elle pourra tout de même se documenter et lorsque le besoin se fera ressentir, alors le choix sera beaucoup plus aisé.

En effet, la communauté se déchirant parfois autour de cette thématique et n’ayant aucune directive claire de la part de Google, il est plus facile dans un premier temps de simplifier les choses  pour les faire évoluer par la suite. Néanmoins, pour ne pas partir les mains vides, je vous conseille tout de même d’utiliser Provider qui est la seule recommandation faite par la documentation et, qui plus est, est complémentaire avec la majorité des éléments cités ci-dessus.

Dans le cas où vous souhaiteriez tout de même faire un choix pour avoir une base de projet prédéfinie, la communauté semble prôner Redux et BLoC. Si ces derniers ne vous satisfont pas sur le long terme, vous pouvez toujours les remplacer par un second en refactorisant votre code.

Injection de dépendances

Chez Cellenza, nous prenons aussi à cœur d’appliquer des principes de craftmanship tels que KISS (Keep It Simple Stupid), YAGNI (You Aren’t Gonna Need It) ou DRY (Don’t Repeat Yourself). Nous vous invitons d’ailleurs à retrouver notre article “Craftman possédez-vous la triforce” dans lequel nous présentons les abysses du craftmanship.

En plus de ces derniers, nous appliquons également le très connu SOLID ! Cet acronyme composé de cinq principes contient l’injection de dépendances qui est un autre point important à mettre en place lors du démarrage d’un projet. Comment implémenter celui-ci dans un projet Flutter ?

A nouveau, on retrouve de nombreuses solutions, mais aucune dite officielle. Une librairie nommée “inject” est belle et bien disponible sur le dépôt Github de Google, mais semble toujours être en preview. De plus, l’entreprise refuse toute affiliation avec ce projet malgré la présence du dépôt et la section “Issues” a été désactivée freinant le support de la librairie en cas de problèmes.

Pour ces raisons, il est plus sage de se tourner sur le store référençant tous les packages Dart et Flutter. Sur ce dernier, on retrouve de nombreux packages permettant d’injecter des dépendances, mais l’un d’entre eux sort du lot : get_it ! En effet, get_it est maintenu par la communauté Flutter garantissant ainsi une certaine stabilité en plus de sa robustesse puisque le package est très connu et a été donc mis à l’épreuve.

Les différents types de tests

En plus d’utiliser des principes de programmation, il est important de tester notre projet.

Comment tester un projet Flutter ?

Flutter offre la possibilité d’effectuer trois types de tests : unitaire, d’intégration (UI) et de widget. A nouveau, la documentation de test sur Flutter étant bien complète, il vous suffit de suivre les directives de cette dernière pour implémenter chacun d’entre eux.

Dans tous les cas, leurs mises en place se résument en trois étapes :

• L’ajout d’une dépendance,
• La création des tests,
• L’exécution de ces derniers.

Les bases pour se lancer sur Flutter

Vous voilà à présent prêt pour commencer votre projet Flutter. Si vous avez des questions sur un élément précis de l’article ou sur le framework en lui-même, n’hésitez pas à nous les poser en commentaire. Notre équipe mobile se fera la joie de vous répondre et d’apporter notre savoir / point de vue !

Bien que cet article effleure à peine Flutter, rassurez-vous, nous revenons prochainement avec une suite d’articles qui viendra compléter ce dernier. Nous vous invitons à nous suivre sur les réseaux sociaux ou à vous inscrire à notre newsletter pour être notifié de leurs publications.

Découvrez la suite de notre série d’article dédiée au mobile, cette fois dédiée au cycle de vie d’un projet agile : Flutter + Azure DevOps = ♥