La gestione dello stato è il punto in cui molte app Flutter iniziano a degradare.
All’inizio tutto funziona:
- qualche
setState - un paio di variabili locali
- UI che si aggiorna correttamente
Poi l’app cresce.
Arrivano:
- API
- loading multipli
- errori
- flussi complessi
- più schermate che condividono dati
Ed è lì che diventa chiaro un fatto fondamentale:
Lo stato non è un dettaglio di implementazione.
È una decisione architetturale.
Con la Lezione 7 del corso Flutter affrontiamo questo tema in modo strutturato, pratico e orientato alla produzione.
📺 Video Lezione 7 (YouTube)
👉 (inserisci qui il link YouTube della Lezione 7)
📁 Slide e appunti della lezione
https://drive.google.com/file/d/1huzk8B2SWdNyV6rA5_2e7c3le39GO1vR/view?usp=sharing
Cos’è lo stato in una app Flutter
In termini pratici, lo stato è qualsiasi dato che può cambiare nel tempo e che influisce sulla UI.
Esempi:
- dati caricati da una API
- stato di loading
- errori
- input dell’utente
- autenticazione
- selezioni, filtri, toggle
Il problema non è avere stato.
Il problema è dove vive e chi lo controlla.
Il primo errore: stato nella UI
Molte app iniziano così:
class MyPage extends StatefulWidget {
@override
State<MyPage> createState() => _MyPageState();
}
class _MyPageState extends State<MyPage> {
bool isLoading = false;
String? error;
}
All’inizio sembra corretto.
Poi iniziano i problemi:
- lo stato è duplicato in più widget
- la logica cresce dentro la UI
- diventa difficile testare
- ogni modifica rompe qualcos’altro
La UI finisce per decidere, invece di mostrare.
Principio chiave: separazione delle responsabilità
Un principio fondamentale che introduciamo nella Lezione 7 è questo:
- la UI osserva
- la logica decide
- lo stato vive fuori dalla UI
Questo principio è alla base di:
- MVVM
- Riverpod
- architetture scalabili
Provider, Riverpod e ChangeNotifier: chiarire i ruoli
In Flutter esistono diversi strumenti che spesso vengono confusi.
Provider
È stato uno dei primi approcci diffusi per:
- dependency injection
- state management
Funziona, ma ha limiti strutturali (dipendenza dal BuildContext, difficoltà di test).
Riverpod
Riverpod nasce per risolvere questi limiti.
Non è “solo” uno state manager.
È:
- dependency injection
- gestione dello stato
- lifecycle controllato
Senza dipendere dal contesto UI.
ChangeNotifier
ChangeNotifier non è sbagliato.
È uno strumento semplice per gestire stato mutabile,
ma va usato nel posto giusto.
Come funziona Riverpod (modello mentale)
Nella lezione introduciamo i concetti chiave:
ref.read(provider); // leggi una volta
ref.watch(provider); // osservi e ricostruisci la UI
ref.listen(provider); // reagisci ai cambiamenti
ref.select(...); // osservi solo una parte
La differenza non è sintattica.
È comportamentale.
Capire quando usare ciascuno di questi metodi
evita:
- rebuild inutili
- side effect
- accoppiamenti sbagliati
Riverpod + ChangeNotifier: usarli insieme (bene)
Uno dei punti centrali della Lezione 7 è mostrare come combinare:
- Riverpod per fornire dipendenze
- ChangeNotifier per gestire stato mutabile
Esempio concettuale:
final counterProvider =
ChangeNotifierProvider((ref) => CounterViewModel());
Dove:
- Riverpod gestisce il lifecycle
- il ViewModel incapsula la logica
- la UI osserva senza conoscere i dettagli
Questo approccio:
- resta semplice
- scala bene
- si integra perfettamente con MVVM
State management in MVVM
Nel pattern MVVM:
- View → mostra dati
- ViewModel → gestisce stato e logica
- Service/Repository → dati esterni
La Lezione 7 mostra come:
- collegare View e ViewModel
- evitare logica nella UI
- mantenere il controllo del flusso
Questo passaggio è cruciale per:
- testabilità
- manutenibilità
- evoluzione del progetto
Errori comuni nello state management Flutter
Durante la lezione vengono analizzati errori reali, molto frequenti:
- stato duplicato in più provider
- provider globali senza motivo
- UI che conosce dettagli di business
- ViewModel che dipendono dalla UI
Riconoscere questi errori prima
fa risparmiare ore (o giorni) di refactor.
Dove mettere i provider nel progetto
Una domanda tipica è:
“in che cartella metto i provider?”
La risposta corretta è:
dipende dalla responsabilità, non dalla moda.
La lezione mostra come:
- organizzare i provider per feature
- mantenere il progetto leggibile
- prepararlo alle lezioni successive
Il corso Flutter gratuito
La Lezione 7 fa parte di un corso Flutter che stiamo pubblicando gratuitamente su YouTube.
Caratteristiche:
- registrazioni reali di un corso live
- una lezione a settimana
- approccio da produzione
- niente scorciatoie
📺 Video completo della lezione 7 del corso Flutter gratuito
Conclusione
Lo state management non è una scelta “di stile”.
È una decisione strutturale.
La Lezione 7 fornisce:
- un modello mentale corretto
- strumenti pratici
- basi solide per crescere
Se Flutter è uno strumento di lavoro per te,
questa lezione non è opzionale.
