1. Stateless vs Stateful : la dualité fondatrice

Tout est widget en Flutter. La question centrale lors de la création d'un nouveau composant est : a-t-il besoin de garder un état mutable interne ? Si non, StatelessWidget ; si oui, StatefulWidget.

"A widget that does not require mutable state. Stateless widgets are useful when the part of the user interface you are describing does not depend on anything other than the configuration information in the object itself." — flutter.dev — StatelessWidget

1.1 Cycle de vie d'un StatefulWidget

Sept callbacks ponctuent la vie d'un State<T> :

1. createState() — appelée une fois lors de l'insertion dans l'arbre
2. initState() — initialise abonnements, controllers, animations (appel à super.initState() obligatoire)
3. didChangeDependencies() — quand un InheritedWidget parent change
4. build(BuildContext) — appelée à chaque rebuild
5. didUpdateWidget() — quand le parent reconstruit avec nouvelle config
6. deactivate() — retirée temporairement de l'arbre
7. dispose() — destruction définitive : libérer controllers, streams, timers

2. Material 3 — design system Google

Activé par défaut depuis Flutter 3.16 (useMaterial3: true est désormais le défaut), Material 3 apporte le Dynamic Color (couleurs extraites du wallpaper Android 12+), des composants repensés (NavigationBar remplace BottomNavigationBar, Card avec elevation tonale) et un système typographique enrichi.

Widgets indispensables : MaterialApp (root), Scaffold (chassis), AppBar + SliverAppBar, FloatingActionButton, NavigationBar + NavigationDrawer, FilledButton, ElevatedButton, OutlinedButton, SegmentedButton, Card, Chip, DatePicker, SnackBar.

3. Cupertino — design system iOS natif

Le package cupertino reproduit l'UI iOS pixel-perfect. CupertinoApp, CupertinoNavigationBar, CupertinoTabScaffold, CupertinoButton, CupertinoSlider, CupertinoActionSheet. Utilisable conjointement avec Material via la détection Platform.isIOS ou un package comme flutter_platform_widgets.

4. Layout — l'ADN du positionnement Flutter

Le système de layout repose sur une règle simple : constraints go down, sizes go up, parent sets position. Le parent passe des contraintes (min/max width/height), l'enfant choisit sa taille à l'intérieur, le parent le positionne.

• Row / Column — alignement linéaire horizontal/vertical avec mainAxisAlignment et crossAxisAlignment
• Expanded / Flexible — partage l'espace restant selon flex
• Stack — superposition Z avec Positioned
• Wrap — passage à la ligne automatique (chips, tags)
• ConstrainedBox / SizedBox — forçage de contraintes
• LayoutBuilder — réactif à la taille parent (responsive)

5. Slivers — le scroll avancé

Quand ListView ne suffit plus (header collapsible, mix de listes/grilles, parallax), on descend dans CustomScrollView avec des Slivers : SliverAppBar (collapsing avec FlexibleSpaceBar), SliverList, SliverGrid, SliverFillRemaining, SliverPersistentHeader.

class ProductListScreen extends StatelessWidget {
  final List<Product> products;
  const ProductListScreen({super.key, required this.products});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Catalogue')),
      body: ListView.builder(
        itemCount: products.length,
        itemBuilder: (ctx, i) {
          final p = products[i];
          return ListTile(
            leading: Image.network(p.imageUrl, width: 56),
            title: Text(p.name),
            subtitle: Text('\${p.price.toStringAsFixed(2)} EUR'),
            trailing: const Icon(Icons.chevron_right),
            onTap: () => Navigator.pushNamed(ctx, '/p/\${p.id}'),
          );
        },
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () => Navigator.pushNamed(context, '/cart'),
        child: const Icon(Icons.shopping_cart),
      ),
    );
  }
}

6. Custom Paint et RenderObject

Pour des UI vraiment custom (graphiques, jeux, signature pad), CustomPainter donne accès à un Canvas Skia/Impeller : drawPath, drawCircle, drawImage, gradients, transformations. Pour aller plus loin, hériter de RenderObject permet de contrôler layout, paint et hit-testing.

Pour aller plus loin

• Catalogue de widgets — flutter.dev
• Material 3 + Flutter
• Cupertino library reference

Le triptyque Flutter Widget / Element / RenderObject est au cœur de toute optimisation sérieuse. Un Widget est immuable et décrit une configuration. Un Element est le maillon mutable du tree qui maintient l'état et opère le diffing. Le RenderObject est l'objet bas niveau qui réalise le layout, le paint et le hit testing. Quand vous appelez setState, vous reconstruisez les Widgets, mais Flutter ne reconstruit pas forcément les Elements ni les RenderObjects : le framework compare les runtimeType et la key pour décider s'il faut détruire l'Element ou simplement le mettre à jour (update(newWidget)). Cette mécanique explique pourquoi un ListView.builder avec une ValueKey instable peut détruire et recréer mille widgets à chaque scroll, alors qu'une key stable permet le recyclage.

Le cycle de vie d'un RenderObject est précis : performResize calcule la taille selon les contraintes parentes, performLayout positionne les enfants, paint dessine sur le Canvas, hitTest détermine si un événement pointeur le concerne. Chaque RenderObject peut être repaint boundary (rasterisation isolée en cache GPU) ou non. Un RepaintBoundary mal placé alourdit la mémoire vidéo ; bien placé, il évite des repaints inutiles sur des animations limitées à une portion d'écran. La devtools timeline (« Rasterizer Thread ») vous montre où placer ces frontières.

CustomPaint et Canvas low-level

Quand aucun widget existant ne produit le visuel voulu (jauge circulaire personnalisée, graphique radar, signature manuscrite), CustomPaint couplé à un CustomPainter donne accès direct au Canvas Skia/Impeller. Vous y dessinez via canvas.drawPath, canvas.drawCircle, canvas.drawShadow, et vous pouvez appliquer des BlendMode exotiques (multiply, colorBurn) impossibles via les widgets standards. Le contrat clé est shouldRepaint(oldDelegate) : retournez false tant que vos paramètres n'ont pas changé, sinon vous redessinez à chaque frame, même statique. Pour les chemins complexes, précalculez le Path dans initState et stockez-le, plutôt que de le reconstruire à chaque paint().

Slivers et SliverPersistentHeader

Un Sliver est un widget qui produit un morceau de zone scrollable. Les Slivers permettent des effets impossibles avec une simple ListView : header qui se contracte (SliverAppBar), section qui colle en haut (SliverPersistentHeader avec pinned: true), grille intercalée avec liste (SliverGrid puis SliverList). Un SliverPersistentHeaderDelegate personnalisé doit retourner ses minExtent, maxExtent et implémenter shouldRebuild. C'est par cette API que les écrans « profile » iOS-style (photo qui se réduit en scroll) sont construits proprement, sans hack de scroll listener.