Vai al contenuto
Ospivia StudioITEN

Ospivia Studio · 10 / 09 / 2026

Web app offline: quali dati salvare e come gestire i conflitti

Prima di chiedere una web app offline, descrivi il lavoro che si interrompe quando manca la connessione. Consultare una scheda già caricata, preparare una bozza e confermare un’operazione condivisa richiedono comportamenti diversi. Il preventivo deve distinguere questi casi.

Scegli cosa deve continuare senza connessione

Immaginiamo un magazzino inventato in cui una persona conta le scatole usando un telefono. Nei corridoi senza rete deve leggere l’elenco preparato e annotare quantità; la conferma definitiva avviene quando i dati raggiungono il sistema condiviso. Per questo primo caso possiamo escludere nuove anagrafiche e caricamenti di foto.

Le applicazioni web possono predisporre risorse e dati per l’uso offline. L’installazione come PWA non realizza automaticamente quel comportamento: va sviluppato e verificato. Chiedi quali informazioni devono essere scaricate prima di entrare nell’area senza copertura e come viene indicata la loro data di aggiornamento.

Rendi distinguibili bozza, attesa e conferma

Una quantità annotata sul telefono non è ancora disponibile ai colleghi. La persona deve riconoscere questa differenza. Nell’esempio proponiamo tre esiti:

EsitoChe cosa significa per chi lavora
Salvato sul dispositivoIl conteggio è registrato localmente; gli altri non lo hanno ricevuto.
Da verificareInvio o conflitto richiedono un controllo; evitare una seconda registrazione.
ConfermatoIl sistema condiviso ha accettato l’operazione secondo le regole concordate.

Scrivi la regola del conflitto prima del codice

Alle 10:05 una persona conta dodici scatole senza rete. Alle 10:12 un collega registra dieci scatole nel sistema online. Quando il primo telefono si collega, usare semplicemente l’ultimo invio potrebbe sostituire un dato più recente con un’osservazione precedente.

Per questo scenario possiamo conservare entrambe le osservazioni, con autore e momento del conteggio, e chiedere al responsabile una riconciliazione. La quantità condivisa cambia solo dopo la decisione prevista. È una scelta di processo, non una regola universale: concorda quali operazioni possono convivere e quali devono fermarsi in attesa di controllo.

Prevedi il recupero quando si riapre l’app

MDN documenta limiti ai tentativi e alla durata delle operazioni in background. Inoltre, Background Sync non è disponibile in tutti i browser diffusi. Non basare il flusso esclusivamente sull’invio automatico mentre l’app è chiusa.

Chiedi una lista delle operazioni pendenti e un recupero visibile alla riapertura. Nel nostro esempio, un tentativo ripetuto deve riferirsi allo stesso conteggio, senza crearne uno nuovo. Se la sessione è scaduta, l’interfaccia deve spiegare come autenticarsi e riprendere il lavoro rimasto in attesa.

Decidi quali dati possono restare sul telefono

La memorizzazione nel browser ha limiti di spazio e condizioni di conservazione; i dati locali possono essere rimossi, anche dall’utente. Chiedi quindi come vengono riconosciuti gli errori di salvataggio. Se il dato non è stato registrato, il messaggio non deve presentarlo come conservato.

Per un dispositivo condiviso, definisci cosa vede l’utente successivo e come si gestiscono le operazioni pendenti prima del cambio account. Chiarisci anche l’effetto della cancellazione dei dati del browser: una registrazione rimasta soltanto sul dispositivo non equivale a una copia recuperabile dal server.

Collauda il risultato sui dispositivi concordati

Indica nel brief browser, dispositivi e attività da svolgere senza rete. Per ogni prova, controlla anche il conteggio finale nel sistema condiviso. Prima di chiedere lo sviluppo, prepara questa sequenza con dati inventati:

  • Aprire l’elenco preparato con la rete già assente.
  • Registrare un conteggio, chiudere e riaprire l’app.
  • Interrompere l’invio e riprovare senza creare duplicati.
  • Sincronizzare due osservazioni incompatibili e risolverle con la regola scelta.
  • Gestire spazio insufficiente o sessione scaduta senza una falsa conferma.

Esplora un esempio

ServiceBot è una demo sintetica utile per discutere stati ed esiti. Non implementa il magazzino di questo esempio e non viene presentato come prova di sincronizzazione offline.

Esplora gli stati di una richiesta ↗

Prepara il brief del tuo progetto

Un modello di testo riutilizzabile: obiettivi, utenti, funzioni, materiali e criteri di accettazione. Scaricalo senza registrazione e compilalo con il tuo team.

Scarica il brief di progetto (.txt) ↓

Riferimenti tecnici

Pubblicato da Ospivia Studio, preparato con supporto AI e verificato rispetto alle fonti tecniche collegate. Gli esempi sono illustrativi e non rappresentano risultati di clienti.