Navigator : qu'est-ce que c'est, gestion des écrans dans Flutter

Qu'est-ce que Navigator dans Flutter

Navigator est un widget qui gère une pile d'objets Route, implémentant la navigation entre écrans dans une application Flutter. Chaque appel à push place un nouveau Route au sommet de la pile, pop retire le Route supérieur et revient à l'écran précédent. MaterialApp crée automatiquement un Navigator pour toute l'application, le rendant accessible via Navigator.of(context).

Contrairement à StatefulWidget, où le remplacement de contenu se fait via setState à l'intérieur d'un seul widget, Navigator opère avec des écrans entiers qui ont leur propre cycle de vie. Chaque Route dans la pile est un état isolé avec son propre BuildContext, ce qui évite les fuites mémoire et simplifie la gestion des dépendances. Lorsque pop est appelé, le Route inutilisé est détruit, libérant des ressources.

Selon le Guide de navigation Flutter (2026), Navigator a évolué d'une API impérative (Navigator 1.0) vers une API déclarative (Navigator 2.0). Navigator 1.0 utilise les méthodes push/pop directement, ce qui est pratique pour les scénarios simples. Navigator 2.0 (Router) convient aux applications avec des liens profonds, une navigation adaptative et un routage web.

Comment Navigator fonctionne sous le capot

En interne, Navigator utilise Overlay — un widget spécial qui affiche les Routes les uns par-dessus les autres. Chaque Route crée sa propre position dans l'Overlay avec un z-index correspondant à sa profondeur dans la pile. Cela explique pourquoi lors de l'appel de push, le nouvel écran s'anime par-dessus le précédent, et lors de l'appel de pop, l'écran précédent est déjà prêt à s'afficher : il n'a pas été détruit mais est resté dans l'Overlay sous le nouvel écran.

Pour les animations de transition, Navigator utilise PageTransitionsTheme, qui peut être remplacé dans ThemeData. Les animations spécifiques à la plateforme sont définies via CupertinoPageRoute pour iOS (glissement depuis la droite) et MaterialPageRoute pour Android (glissement depuis le bas). Navigator sélectionne automatiquement l'animation correcte lors de l'utilisation de PlatformRoute.

Méthodes de Navigator : push, pop et pushReplacement

Navigator fournit un ensemble de méthodes pour gérer la pile de Routes. Chaque méthode résout une tâche de navigation spécifique — d'une simple transition au remplacement complet de l'historique des écrans. Passons en revue les principales méthodes avec des exemples d'utilisation.

Push et Pop : opérations de base

La méthode push prend un Route et retourne un Future avec le résultat passé lors de pop. Cela permet de recevoir des données de l'écran vers lequel on a navigué. Par exemple, un écran de sélection de date peut retourner un DateTime via Navigator.pop(context, selectedDate). La méthode pop sans argument retourne null, avec un argument — transmet la valeur à l'écran appelant.

PushReplacement : remplacement d'écran

pushReplacement remplace le Route actuel par un nouveau, supprimant le route actuel de la pile. C'est essentiel pour les scénarios où l'utilisateur ne doit pas pouvoir revenir à l'écran précédent. Un exemple typique — l'écran de connexion : après une connexion réussie, l'écran actuel est remplacé par l'écran principal, et le bouton Retour ne revient pas au formulaire de connexion.

Routes nommées et onGenerateRoute

Navigator prend en charge la navigation par routes nommées via la méthode pushNamed. Au lieu de créer un Route directement, le développeur spécifie un identifiant de chaîne, et Navigator crée automatiquement le Route en fonction de la configuration dans MaterialApp. Cela simplifie le code et centralise la définition des routes en un seul endroit.

Les routes nommées sont définies via la propriété routes dans MaterialApp, où chaque clé est une chaîne de chemin et la valeur est une fonction retournant un Widget. Pour les routes dynamiques (avec paramètres), on utilise onGenerateRoute — un callback qui reçoit RouteSettings et retourne un Route. Cela permet de passer des arguments via le paramètre arguments et d'implémenter une navigation profonde.

Selon le Flutter Cookbook (2026), le passage d'arguments via pushNamed se fait avec le paramètre arguments: Object?. L'écran récepteur extrait les arguments via ModalRoute.of(context)!.settings.arguments, offrant un transfert de données typé sans variables globales ni InheritedWidget.

Gestion des routes inconnues

La propriété onUnknownRoute dans MaterialApp gère les cas où pushNamed est appelé avec une route inexistante. Cela est utile pour afficher un écran 404 ou rediriger vers la page d'accueil. En combinaison avec onGenerateRoute, il assure une couverture complète de tous les scénarios de navigation possibles.

Navigator 2.0 et navigation déclarative avec Router

Navigator 2.0 (également connu sous le nom d'API Router) est une approche déclarative de la navigation introduite dans Flutter 2.0. Contrairement au Navigator 1.0 impératif, où le développeur appelle push/pop, Router gère la navigation via l'état, synchronisant automatiquement l'URL du navigateur avec l'écran actuel. Ceci est particulièrement important pour les applications web et les versions desktop.

L'architecture de Navigator 2.0 se compose de trois composants clés : RouteInformationParser analyse l'URL en une configuration de route, RouterDelegate transforme la configuration en une liste de Routes, et BackButtonDispatcher gère le bouton Retour du système. Cette architecture rend la navigation complètement prévisible et testable.

Pour simplifier le travail avec Navigator 2.0, il existe des packages wrapper : go_router (recommandé par Google), auto_route et beamer. go_router fournit un DSL déclaratif pour définir des routes avec prise en charge de la navigation imbriquée, des redirections et des liens profonds sans implémenter manuellement RouterDelegate. Selon pub.dev (2026), go_router est utilisé dans 35% des nouveaux projets Flutter qui préfèrent une approche déclarative.

Exemple de navigation dans une application Flutter

Considérons un exemple de Navigator avec des routes nommées et le passage de données entre écrans. Le code montre un écran de liste de produits, la transition vers un écran de détail et le retour avec un résultat.

// Route configuration in MaterialApp
MaterialApp(
  initialRoute: '/',
  onGenerateRoute: (RouteSettings settings) {
    if (settings.name == '/') {
      return MaterialPageRoute(
        builder: (context) => const ProductListPage(),
      );
    }
    if (settings.name == '/product') {
      final productId = settings.arguments as String;
      return MaterialPageRoute(
        builder: (context) => ProductDetailPage(productId: productId),
      );
    }
    return MaterialPageRoute(
      builder: (context) => const NotFoundPage(),
    );
  },
)

// Navigation with data passing
final result = await Navigator.pushNamed(
  context,
  '/product',
  arguments: 'product_42',
);

// Getting data on the receiving screen
final args = ModalRoute.of(context)!.settings.arguments as String;

// Replace screen after login
Navigator.pushReplacementNamed(context, '/home');

// Clear stack to main screen
Navigator.pushNamedAndRemoveUntil(
  context,
  '/home',
  (route) => false,
);

Dans l'exemple, Navigator.pushNamed transmet l'ID du produit à l'écran de détail. Lors du retour via Navigator.pop(context, updatedProduct), l'écran appelant reçoit les données mises à jour dans la variable result. pushReplacementNamed remplace l'écran actuel après l'autorisation, et pushNamedAndRemoveUntil avec la condition (route) => false vide complètement la pile, empêchant la navigation de retour vers les écrans précédents.