API et réseau

Jusqu'ici, toutes nos données étaient écrites dans le code. Une application réelle interroge un serveur, et ce simple changement introduit une difficulté d'une autre nature : le réseau est lent et faillible. Une requête prend entre trente millisecondes et trente secondes. Elle peut échouer parce que le téléphone est dans un tunnel, parce que le serveur redémarre, parce que le certificat a expiré, ou parce que l'utilisateur a fermé l'écran entre-temps.

L'interface Flutter s'exécute sur un fil unique. Tout ce qui bloque ce fil bloque l'affichage : plus d'animation, plus de défilement, plus de réaction au toucher. Après quelques secondes, le système d'exploitation propose de fermer l'application. Cela signifie qu'un appel réseau ne peut jamais être synchrone, et que le code doit gérer explicitement trois états au lieu d'un seul : chargement, succès, échec. Le troisième est celui que l'on oublie, et c'est celui qui vaut les mauvaises notes sur les magasins.

Cette leçon monte une couche réseau complète et honnête : un modèle de données sérialisable, un service isolé, la conversion des erreurs en messages compréhensibles, et l'affichage des trois états. Nous commencerons volontairement par la version qui gèle l'application, parce que comprendre pourquoi elle gèle vaut mieux que réciter async.