Les états

Introduction

La gestion des états est un point fondamental. Dans les divers exemples parcourus jusqu’à présent et à venir, deux héritages sont récurrents, StatelessWidget et StatefulWidget. Ils permettent de définir le comportement des classes ou des widgets. La question est de savoir s’ils auront besoin de voir leur état évoluer avec le temps ou non.

Cette gestion des états qui se retrouve dans les StatefulWidget est vraiment pratique, mais présente un point faible indéniable. La partie graphique de l’application est intimement liée à la partie logique. Ce qui rend difficilement maintenable une application. La bonne façon de procéder est de réussir à réduire ce couplage au maximum. Sur ce sujet, qui reste très vaste et sur lequel la position des développeurs reste mitigée, le choix, est ici fait de s’arrêter sur deux méthodes très répandues et reconnues, bien qu’il en existe d’autres. Dans un premier temps, les providers seront abordés. Ils sont aujourd’hui, selon les équipes de Flutter, la voie à privilégier. Toutefois, la communauté reste très attirée par le pattern BLoC. C’est donc un thème qu’il faut aborder aussi.

Bien sûr, ces sujets sont très complexes. Ce chapitre ne pourra...

StatelessWidget

Le StatelessWidget est une classe (un widget) qui sert à créer une interface utilisateur. Comme son nom l’indique, elle n’a pas vocation à voir son état évoluer dans le temps.

Une classe qui implémente StatelessWidget doit impérativement intégrer un widget build :

class MyHomePage extends StatelessWidget { 
 @override 
 Widget build(BuildContext context) { 
   // TODO: implement build 
   return null; 
 } 
} 

Ce build est appelé à plusieurs moments. D’abord, quand le widget est inséré dans l’arbre des widgets, quand son parent subit une modification ou bien quand il est associé à un autre widget InheritedWidget.

Les deux derniers appels, qui peuvent arriver régulièrement, vont forcer le widget à se reconstruire, diminuant ainsi la performance de l’application. Il existe cependant plusieurs points à respecter pour minimiser ce phénomène.

La première méthode consiste, si le contexte le permet, à minimiser le nombre de widgets en son sein. Notamment, si un seul élément doit être placé, il convient d’éviter d’utiliser les Row, Column, Padding et SizedBox. Dans ce cas, il sera préférable de recourir à Align ou à...

StatefulWidget

Le StatefulWidget est, a contrario du StatelessWidget, un widget qui a vocation à voir son état évoluer avec le temps.

Dès lors, sa construction est un peu différente et se réalise par le biais de deux classes. La première, classique, étend StatefulWidget. Elle a un rôle plutôt déclaratif. C’est donc une classe qui va contenir un constructeur et des attributs par exemple. Elle contient aussi, et c’est obligatoire, l’appel à la méthode createState. Cette dernière va retourner une instance d’une classe gérant le State par l’appel à son constructeur. Elle prendra en charge deux choses. Premièrement, elle décrira des widgets, principalement des éléments graphiques. Deuxièmement, elle sera capable de les faire changer et évoluer par le recours à une méthode setState.

Voici un exemple de classe étendant StatefulWidget :

class Accueil extends StatefulWidget { 
 Accueil({Key key, this.title, this.color}) : super(key: key); 
 
 final String title; 
 Color color; 
 
 @override 
 State<StatefulWidget> createState() { 
   return _AccueilState(); 
 } 
} 

Il s’agit d’une construction assez classique. Toutefois, la méthode createState peut être optimisée et il est préférable de la retrouver sous cette syntaxe :

@override 
_AccueilState createState() => _AccueilState(); 

Concernant la classe _AccueilState, elle va devoir prendre en charge la partie graphique ainsi que son évolution potentielle au travers de setState. Pour offrir un autre exemple que celui habituellement donné avec l’application par défaut, une variante est proposée. Cette fois, l’appui sur le FloatingActionButton va modifier aléatoirement la couleur de divers éléments de l’écran.

Cette classe doit étendre State<T>. T correspondant à la classe associée étendant...

Couplage interface et logique

Le cycle de vie des StatefulWidget est complexe mais offre beaucoup de possibilités. En particulier les méthodes setState qui sont extrêmement pratiques comme les diverses démonstrations l’ont prouvé.

En revanche, il reste un problème d’envergure. L’inclusion d’un setState comprenant de la logique applicative au sein même de l’interface graphique rend l’application difficilement maintenable. De plus, un setState étant lié à un contexte (context), il n’est pas possible de faire évoluer plusieurs interfaces en même temps.

De manière générale, en programmation, la bonne pratique consiste à séparer la partie logique de la gestion graphique. Concernant Flutter, il existe de nombreuses méthodes permettant de mettre en place cette séparation. Sans être exhaustif, en voici quelques-unes :

Le choix est donc difficile et le débat n’est pas clos en la matière. Il faut bien être conscient qu’il s’agit là de notions avancées qui mériteraient un ouvrage à elles seules si elles devaient être toutes détaillées.

Toutefois, dans la liste ci-dessus, il y a tout de même deux pratiques qui se détachent : les providers et les BLoC. Les sections suivantes n’entreront pas dans le détail, mais elles permettront d’en comprendre les principes de base.

À cet effet, la démonstration de lancement (le compteur) sera retravaillée avec les deux méthodes. Elle a l’avantage d’être simple et surtout, elle a déjà été manipulée à plusieurs reprises.