Strategie di caching in Flutter: cache locale, dati obsoleti e regole di aggiornamento

Perché il caching è complicato nelle app Flutter

Il caching in un'app mobile significa tenere una copia dei dati vicino (in memoria o sul dispositivo) così la schermata successiva può renderizzare all'istante invece di aspettare la rete. Questi dati possono essere una lista di elementi, il profilo utente o i risultati di una ricerca.

La parte difficile è che i dati in cache sono spesso leggermente sbagliati. Gli utenti lo notano in fretta: un prezzo che non si aggiorna, un contatore di badge che sembra bloccato o una schermata dettagli che mostra informazioni vecchie subito dopo che sono state modificate. Ciò che rende il debug doloroso è il timing. Lo stesso endpoint può sembrare a posto dopo un pull-to-refresh, ma sbagliato dopo un ritorno indietro, il resume dell'app o il cambio account.

C'è un vero compromesso. Se fetchi sempre dati freschi, le schermate sembrano lente e scattose e consumi batteria e dati. Se fai cache aggressiva, l'app sembra veloce ma le persone smettono di fidarsi di quello che vedono.

Un obiettivo semplice aiuta: rendere la freschezza prevedibile. Decidi cosa ogni schermata è autorizzata a mostrare (fresco, leggermente obsoleto o offline), per quanto tempo i dati possono restare prima di essere aggiornati e quali eventi devono invalidarli.

Immagina un flusso comune: un utente apre un ordine e poi torna alla lista ordini. Se la lista proviene dalla cache, potrebbe ancora mostrare lo stato vecchio. Se aggiorni sempre, la lista può sfarfallare e sembrare lenta. Regole chiare come “mostra la cache subito, aggiorna in background e aggiorna entrambe le schermate quando arriva la risposta” rendono l'esperienza coerente durante la navigazione.

Un modo semplice per pensare a cache e freschezza

Una cache non è solo “dati salvati”. È una copia salvata più una regola su quando quella copia è ancora valida. Se memorizzi il payload ma salti la regola, ti ritrovi con due versioni della realtà: una schermata mostra informazioni nuove, un'altra quelle di ieri.

Un modello pratico è mettere ogni elemento in cache in uno di tre stati:

• Fresco: sicuro da mostrare con fiducia.
• Obsoleto ma utilizzabile: mostra ora, aggiorna in background.
• Deve essere aggiornato: non fidarti, fetcha prima di mostrare (o mostra uno stato di caricamento).

Questo inquadramento mantiene l'interfaccia prevedibile perché può rispondere sempre nello stesso modo a un dato stato.

Le regole di freschezza dovrebbero basarsi su segnali che puoi spiegare a un collega. Scelte comuni sono: scadenza temporale (ad es. 5 minuti), cambio di versione (schema o versione app), azione dell'utente (pull to refresh, submit, delete) o un suggerimento dal server (ETag, timestamp last-updated o una risposta esplicita di "cache invalid").

Esempio: una schermata profilo carica subito i dati utente in cache. Se sono stale-ma-utilizzabili, mostra nome e avatar memorizzati e poi aggiorna silenziosamente. Se l'utente ha appena modificato il profilo, quello è un momento di must-refresh. L'app dovrebbe aggiornare la cache immediatamente così ogni schermata resta coerente.

Decidi chi possiede queste regole. Nella maggior parte delle app, il miglior default è: il data layer possiede freschezza e invalidazione, la UI reagisce (mostra cache, mostra caricamento, mostra errore) e il backend fornisce suggerimenti quando può. Questo evita che ogni schermata inventi le proprie regole.

Cosa memorizzare in cache (e cosa no)

Un buon caching parte da una domanda: se questi dati sono un po' vecchi, danneggerà l'utente? Se la risposta è “probabilmente no”, di solito è adatto alla cache locale.

I dati letti spesso e che cambiano lentamente valgono in genere la pena di essere cachati: feed e liste che le persone scorrono spesso, contenuti in stile catalogo (prodotti, articoli, template) e dati di riferimento come categorie o paesi. Impostazioni e preferenze rientrano qui, insieme a informazioni profilo di base come nome e URL avatar.

Il lato rischioso è tutto ciò che riguarda soldi o tempo critico. Saldi, stato di pagamento, disponibilità di stock, slot appuntamenti, ETA di consegna e “ultimo accesso” possono causare problemi reali se sono obsoleti. Puoi comunque cacharli per velocità, ma tratta la cache come un segnaposto temporaneo e forza un refresh nei punti di decisione (ad esempio, subito prima di confermare un ordine).

Lo stato UI derivato è una categoria a sé. Salvare la tab selezionata, filtri, query di ricerca, ordine di ordinamento o posizione di scorrimento può rendere la navigazione fluida. Può anche confondere se scelte vecchie riappaiono inaspettatamente. Una regola semplice funziona bene: conserva lo stato UI in memoria mentre l'utente rimane nel flusso, ma resettalo quando l'utente “ricomincia” intenzionalmente (per esempio tornando alla home).

Evita di cachare dati che creano rischi di sicurezza o privacy: segreti (password, API key), token monouso (OTP, reset password) e dati personali sensibili a meno che non serva veramente l'accesso offline. Non memorizzare mai dettagli completi di carta o qualsiasi cosa che aumenti il rischio di frode.

In un'app di shopping, la cache della lista prodotti è una grande vittoria. La schermata checkout, invece, dovrebbe sempre aggiornare totali e disponibilità subito prima dell'acquisto.

Scegliere il layer di cache locale: memoria, disco, database

La maggior parte delle app Flutter finisce per aver bisogno di una cache locale così le schermate si caricano velocemente e non appaiono vuote mentre la rete si risveglia. La decisione chiave è dove mettere i dati in cache, perché ogni layer ha diversa velocità, limiti di dimensione e comportamento di pulizia.

Una cache in memoria è la più veloce. È ottima per dati appena fetchati e riutilizzati mentre l'app resta aperta, come il profilo utente corrente, gli ultimi risultati di ricerca o un prodotto appena visualizzato. Il compromesso è semplice: scompare quando l'app viene uccisa, quindi non aiuta cold start o uso offline.

Lo storage key-value su disco va bene per piccole voci che vuoi conservare tra riavvii. Pensa a preferenze e blob piccoli: feature flag, “ultima tab selezionata” e piccole risposte JSON che cambiano raramente. Tienilo intenzionalmente piccolo. Quando inizi a mettere liste grandi nello storage key-value, gli aggiornamenti diventano confusi e aumenta facilmente il bloat.

Un database locale è la scelta migliore quando i dati sono più grandi, strutturati o necessitano comportamento offline. Aiuta anche quando servono query (“tutti i messaggi non letti”, “elementi nel carrello”, “ordini dell'ultimo mese”) invece di caricare un grande blob e filtrare in memoria.

Per mantenere il caching prevedibile, scegli uno store primario per ogni tipo di dato ed evita di tenere lo stesso dataset in tre posti.

Una regola rapida:

• Memoria: riuso nella sessione corrente
• Key-value su disco: piccoli, semplici, che cambiano raramente
• Database: grandi, strutturati, offline-friendly

Pianifica anche le dimensioni. Decidi cosa significa “troppo grande”, per quanto tempo tieni le voci e come le pulisci. Per esempio: limita i risultati di ricerca cache agli ultimi 20 query e rimuovi regolarmente record più vecchi di 30 giorni così la cache non cresce silenziosamente all'infinito.

Regole di refresh per dati obsoleti che gli utenti possono accettare

Le regole di refresh dovrebbero essere abbastanza semplici da poterle spiegare in una frase per schermata. È qui che il caching sensato ripaga: gli utenti ottengono schermate veloci e l'app resta affidabile.

La regola più semplice è TTL (time to live). Salva i dati con un timestamp e trattali come freschi per, diciamo, 5 minuti. Dopo diventano obsoleti. TTL funziona bene per dati “carini da avere” come un feed, categorie o raccomandazioni.

Un affinamento utile è dividere il TTL in soft TTL e hard TTL.

Con un soft TTL mostri subito la cache, poi aggiorni in background e aggiornando l'interfaccia se è cambiato. Con un hard TTL smetti di mostrare i dati vecchi una volta scaduti. Blocchi con un loader o mostri uno stato “offline/ritenta”. L'hard TTL si adatta ai casi in cui sbagliare è peggio che essere lenti, come saldi, stato ordini o permessi.

Se il tuo backend lo supporta, preferisci “aggiorna solo se cambiato” usando ETag, updatedAt o un campo version. L'app può chiedere “è cambiato?” e saltare il download del payload completo quando non c'è nulla di nuovo.

Un default user-friendly per molte schermate è stale-while-revalidate: mostra ora, aggiorna silenziosamente e ridisegna solo se il risultato differisce. Offre velocità senza flicker casuale.

La freschezza per schermata spesso diventa così:

• Home feed: soft TTL (1–5 minuti), refresh in background all'apertura
• Profilo: soft TTL (15–60 minuti), refresh dopo modifiche
• Messaggi: hard TTL o TTL molto corto (0–10 secondi), refresh al resume
• Checkout/ordine: hard TTL, conferma sempre col server
• Impostazioni/listati statici: TTL lungo (giorni), refresh all'aggiornamento dell'app

Scegli le regole basandoti sul costo di essere in errore, non solo sul costo del fetch.

Quando invalidare la cache (trigger che contano)

L'invalidazione della cache comincia con una domanda: quale evento rende i dati in cache meno affidabili del costo di rifetcharli? Se scegli un piccolo insieme di trigger e ti attieni a essi, il comportamento resta prevedibile e l'interfaccia appare stabile.

I trigger che contano di più nelle app reali:

• Azioni utente: pull-to-refresh, toccare Retry dopo un errore o tornare su una schermata dove l'utente si aspetta il “più recente” (es. inbox).
• Lifecycle: avvio app (warm the cache, poi refresh) e resume dallo sfondo (refresh solo se più vecchio del TTL).
• Identità: login, logout, cambio account. Tratta questo come un confine netto: cancella le cache legate all'utente e annulla le richieste in corso legate al vecchio utente.
• Azioni di scrittura (CRUD): dopo create, update o delete, aggiorna la cache immediatamente così le schermate restano coerenti. Rifetcha solo se il server applica regole extra (ordinamento, permessi, campi calcolati).
• Sicurezza: upgrade dell'app, cambio di schema locale, feature flag che cambiano. Aumenta la versione della cache e pulisci o migra.

Esempio: un utente modifica la foto del profilo, poi torna indietro. Se ti basi solo su refresh temporali, la schermata precedente potrebbe mostrare l'immagine vecchia fino al prossimo fetch. Tratta la modifica come trigger: aggiorna l'oggetto profilo in cache subito e marcane la freschezza con un nuovo timestamp.

Mantieni le regole di invalidazione piccole ed esplicite. Se non riesci a indicare l'evento esatto che invalida una voce di cache, finirai per rinfrescare troppo spesso (UI lenta e scattosa) o troppo poco (schermate obsolete).

Passo dopo passo: implementare un flusso di caching prevedibile

Inizia elencando le schermate chiave e i dati di cui ogni schermata ha bisogno. Non pensare in endpoint. Pensa in oggetti visibili dall'utente: profilo, carrello, lista ordini, dettaglio catalogo, conteggio non letti.

Poi scegli una source of truth per ogni tipo di dato. In Flutter, di solito è un repository che nasconde da dove arrivano i dati (memoria, disco, rete). Le schermate non dovrebbero decidere quando colpire la rete. Dovrebbero chiedere il dato al repository e reagire allo stato restituito.

Un flusso pratico:

• Mappa le schermate ai dati richiesti (e se sono user-scoped o condivisi).
• Instrada tutte le letture e scritture attraverso un repository per tipo di dato.
• Salva i dati con metadata: savedAt timestamp, versione schema/app e ownerUserId.
• Definisci comportamento UI per quattro stati: fresh, stale, loading, error.
• Aggiungi due percorsi di refresh: manuale (pull to refresh) e background (refresh silenzioso quando stale).

I metadata rendono le regole applicabili. Se ownerUserId cambia (logout/login), puoi eliminare o ignorare le righe cache vecchie immediatamente invece di mostrare i dati del precedente utente per mezzo secondo.

Per il comportamento UI, decidi in anticipo cosa significa “stale”. Una regola comune: mostra subito i dati obsoleti così la schermata non è vuota, avvia un refresh in background e aggiorna quando arrivano dati nuovi. Se il refresh fallisce, tieni visibili i dati obsoleti e mostra un piccolo errore chiaro.

Poi fissa le regole con alcuni test noiosi:

• TTL: i dati diventano stale dopo X minuti.
• Logout: la cache per ownerUserId viene cancellata o isolata.
• Update: la scrittura locale aggiorna la cache immediatamente, poi sincronizza.
• Version bump: la cache vecchia viene ignorata dopo un cambio di versione/schema.
• Errore: i dati obsoleti restano visibili quando il refresh fallisce.

Questa è la differenza tra “abbiamo caching” e “la nostra app si comporta allo stesso modo ogni volta”.

Mantenere le schermate coerenti durante la navigazione

Niente rompe la fiducia più del vedere un valore nella lista, aprire i dettagli, modificarlo e tornare indietro vedendo il valore vecchio. La coerenza tra schermate nasce dal fatto che ogni schermata legga dalla stessa fonte.

Una regola solida è: fetcha una volta, salva una volta, rendi molte volte. Le schermate non dovrebbero chiamare lo stesso endpoint indipendentemente e tenere copie private. Metti i dati in cache in uno store condiviso (il tuo layer di state management) e lascia che sia la lista che il dettaglio ad osservare gli stessi dati.

Crea una source of truth

Tieni un unico luogo che possiede il valore corrente e la freschezza. Le schermate possono richiedere un refresh, ma non devono gestire timer, retry e parsing singolarmente.

Abitudini pratiche che prevengono “due versioni della realtà”:

• Condividi lo stato tra le rotte (uno store/provider per feature, non per widget).
• De-duplicare le richieste in corso così due schermate non fetchano lo stesso dato due volte.
• Alla navigazione indietro, rileggi dallo store invece di riesumare lo stato del widget.
• Dopo le modifiche, aggiorna lo store immediatamente così tutte le schermate riflettono il cambiamento.

Mostra cosa sta succedendo

Anche con buone regole, gli utenti vedranno a volte dati obsoleti (offline, rete lenta, app in background). Rendilo evidente con segnali piccoli e calmi: un timestamp “Aggiornato ora”, un indicatore sottile “Refreshing…” o un badge “Offline”.

Per le modifiche, gli aggiornamenti ottimistici spesso funzionano meglio. Esempio: l'utente cambia il prezzo di un prodotto nella schermata dettaglio. Aggiorna subito lo store condiviso così la lista mostra il nuovo prezzo al ritorno. Se il salvataggio fallisce, torna indietro al valore precedente e mostra un errore breve.

Errori comuni di caching e come evitarli

La maggior parte dei fallimenti di caching è banale: la cache funziona, ma nessuno sa dire quando usarla, quando scade e chi la possiede.

La prima trappola è cachare senza metadata. Se salvi solo il payload, non puoi sapere se è vecchio, quale versione dell'app lo ha prodotto o a quale utente appartiene. Salva almeno savedAt, un semplice numero di versione e userId. Questa abitudine previene molti bug tipo “perché questa schermata è sbagliata?”.

Un altro problema comune è avere cache multiple per lo stesso dato senza un owner. Una schermata lista tiene una lista in memoria, un repository scrive su disco e una schermata dettagli fetcha e salva altrove. Scegli una source of truth (spesso il repository) e fai sì che tutte le schermate leggano attraverso essa.

I cambi account sono un frequente colpo basso. Se qualcuno effettua logout o cambia account, cancella tabelle e chiavi user-scoped. Altrimenti potresti mostrare per un attimo foto profilo o ordini del precedente utente, che sembra una violazione della privacy.

Fix pratici che coprono i problemi sopra:

• Memorizza le voci di cache con savedAt, version e userId, non solo JSON.
• Definisci un owner per dataset (per esempio ProfileRepository possiede il profilo).
• Usa la regola “mostra la cache ora, aggiorna in background” per la maggior parte delle schermate.
• Rate-limita i refresh (ad es. un refresh di rete ogni X minuti per endpoint).
• Mostra gli errori di refresh (banner piccolo o retry) e imposta un tempo massimo di staleness.

Esempio: la tua lista prodotti carica istantaneamente dalla cache, poi aggiorna silenziosamente. Se il refresh fallisce, continua a mostrare i dati cached ma indica chiaramente che potrebbero essere obsoleti e offri Retry. Non bloccare la UI sul refresh quando i dati in cache vanno bene.

Checklist rapida prima del rilascio

Prima della release, trasforma il caching da “sembra a posto” in regole testabili. Gli utenti dovrebbero vedere dati sensati anche dopo aver navigato avanti e indietro, essere offline o aver effettuato l'accesso con un account diverso.

Definire freschezza e comportamento di refresh

Per ogni schermata, decidi per quanto tempo i dati sono considerati freschi. Possono essere minuti per dati veloci (messaggi, saldi) o ore per dati lenti (impostazioni, categorie prodotto). Poi conferma cosa succede quando non lo sono: refresh in background, refresh all'apertura o pull-to-refresh manuale.

Bloccare invalidazione e metadata della cache

Per ogni tipo di dato, decidi quali eventi devono bypassare o cancellare la cache. Trigger comuni includono logout, modifica dell'item, cambio account e aggiornamenti dell'app che cambiano la forma dei dati.

Assicurati che ogni voce in cache salvi accanto al payload un piccolo set di metadata:

• savedAt
• userId
• version (schema/app)
• source (opzionale: network vs local)

Mantieni chiara la proprietà: usa un repository per tipo di dato (es. ProductsRepository), non uno per widget. I widget dovrebbero chiedere dati, non decidere le regole di cache.

Decidi e testa anche il comportamento offline. Conferma cosa mostrano le schermate dalla cache, quali azioni sono disabilitate e quale copy visualizzi (“Mostrando dati salvati”, più un controllo di refresh visibile). Il refresh manuale dovrebbe esistere su ogni schermata supportata da cache ed essere facile da trovare.

Esempio: un'app catalogo coerente

Immagina una semplice app shop con tre schermate: catalogo prodotti (lista), dettaglio prodotto e tab Preferiti. Gli utenti scorrono il catalogo, aprono un prodotto e toccano l'icona a cuore per aggiungerlo ai preferiti. L'obiettivo è dare sensazione di velocità anche su reti lente, senza mostrare mismatch confusi.

Metti in cache localmente ciò che aiuta il rendering istantaneo: pagine catalogo (ID, titolo, prezzo, thumbnail URL, flag favorito), dettagli prodotto (descrizione, specifiche, disponibilità, lastUpdated), metadata delle immagini (URL, dimensioni, cache key) e la lista preferiti dell'utente (insieme di product ID, opzionalmente con timestamp).

Quando l'utente apre il catalogo, mostra subito i risultati dalla cache e poi riconvalida in background. Se arrivano dati freschi, aggiorna solo ciò che è cambiato mantenendo stabile la posizione di scroll.

Per il toggle preferito, trattalo come un'azione “deve essere consistente”. Aggiorna subito il set locale dei preferiti (update ottimistico), poi aggiorna le righe prodotto in cache e i dettagli prodotto per quell'ID. Se la chiamata di rete fallisce, fai il rollback e mostra un piccolo messaggio.

Per mantenere coerenza nella navigazione, guida badge della lista e icona cuore in dettaglio dalla stessa source of truth (la tua cache locale o store), non dallo stato privato delle schermate. Il cuore nella lista si aggiorna appena torni dai dettagli, il dettaglio riflette cambi fatti dalla lista e il conteggio nella tab Preferiti corrisponde ovunque senza aspettare un refetch.

Aggiungi regole di refresh semplici: la cache del catalogo scade rapidamente (minuti), i dettagli prodotto un po' più tardi e i preferiti non scadono mai ma si riconciliano sempre dopo login/logout.

Prossimi passi: documentare le regole e mantenerle semplici

Il caching smette di essere misterioso quando il team può puntare a una pagina di regole e accordarsi su cosa accade. L'obiettivo non è la perfezione, ma un comportamento prevedibile che resti lo stesso tra le release.

Scrivi una piccola tabella per schermata e tienila breve: nome schermata e dato principale, posizione della cache e chiave, regola di freschezza (TTL, basata su eventi o manuale), trigger di invalidazione e cosa vede l'utente durante il refresh.

Aggiungi logging leggero mentre affini. Registra hit e miss della cache e perché è avvenuto un refresh (TTL scaduto, pull-to-refresh, app resumed, mutazione completata). Quando qualcuno segnala “questa lista sembra sbagliata”, quei log rendono il bug risolvibile.

Inizia con TTL semplici, poi affina basandoti su ciò che notano gli utenti. Un feed di notizie può accettare 5–10 minuti di staleness, mentre una schermata di stato ordine potrebbe richiedere refresh al resume e dopo qualsiasi azione di checkout.

Se stai costruendo un'app Flutter rapidamente, può essere utile delineare il data layer e le regole di cache prima di implementare nulla. Per i team che usano Koder.ai (koder.ai), la planning mode è un buon posto per scrivere prima quelle regole per schermata, poi costruire per soddisfarle.

Quando affini il comportamento di refresh, proteggi le schermate stabili mentre sperimenti. Snapshot e rollback possono farti risparmiare tempo quando una nuova regola introduce flicker, stati vuoti o conteggi incoerenti durante la navigazione.