Preparare un’app sul campo alle interruzioni di rete
Definisca cosa salvare offline e come gestire gli interventi modificati quando l’app torna connessa.
Definisca il lavoro consentito offline
Per un inserimento offline, l’app deve distinguere la registrazione locale dalla trasmissione riuscita all’ufficio. Decida per ogni compito se lettura, bozza o chiusura definitiva siano consentite senza rete. Per restare utile nelle interruzioni, un'app non deve permettere ogni scrittura offline.
La documentazione Android distingue strategie di scrittura e affronta i conflitti alla riconnessione. Conta il significato di business degli stati mostrati: una bozza locale non è ancora un salvataggio confermato sul server.
Esempio: conservare la nota e chiarire l'annullamento
Lo scenario è interamente inventato. Il dispositivo conosce l'intervento AU-64 alla versione v7. Lo specialista inserisce offline una nota di completamento. Nel frattempo la pianificazione annulla l'intervento sul server, creando v8. Nell'esempio, un chiarimento autorizzato può consentire di aggiungere la nota senza revocare l'annullamento.
Situazione | Stato locale | Comportamento atteso |
|---|---|---|
Inserire una nota offline | Bozza sul dispositivo | Mostrare «Salvato solo su questo dispositivo»; non annunciare un completamento riuscito. |
Chiudere e riaprire l'app | Bozza non inviata | Nel test di riapertura previsto, la bozza è disponibile e modificabile. |
Torna la connessione | Bozza basata su uno stato precedente | Verificare lo stato modificato del server, mostrare il conflitto e conservare la nota; non sovrascrivere automaticamente l'annullamento. |
Chiarimento autorizzato e salvataggio server confermato | Nota acquisita come informazione aggiuntiva | Mostrare l'acquisizione; l'intervento resta annullato. |
È un elenco di risultati attesi, non un resoconto di test eseguiti. Un'icona di rete o l'invio di una richiesta non basta per l'ultimo stato. Serve la conferma che il server abbia realmente salvato la modifica prevista.
Verifichi tutto il percorso di ritorno
Conservi la versione nota per la riconciliazione. Un orario del dispositivo più recente non decide da solo quale modifica sia corretta per l'attività. Definisca la regola di conflitto e il ruolo autorizzato a risolvere i casi aperti. Eviti anche che un nuovo tentativo crei la stessa nota più volte.
Verifichi sul server i permessi attuali al nuovo invio. OWASP richiede di controllare i permessi a ogni richiesta. Un accesso precedente non autorizza automaticamente ogni modifica successiva. Mostri chiaramente l'assenza di accesso o un salvataggio rifiutato.
Concordi anche regole di accesso locale e comportamento alla disconnessione dell'account, al cambio di dispositivo o alla cancellazione dei dati dell'app. Includa interruzione, riapertura, conflitto e nuovo tentativo nella prova. Si distingue così il lavoro preparato da quello acquisito definitivamente.
Fonti
Scritto da
- Katharina WeberRedattrice per software e tecnologiaKatharina Weber cura per ASES gli articoli sullo sviluppo software. Scrive delle questioni che le aziende affrontano nella scelta del software, nello sviluppo di nuove applicazioni e nella modernizzazione dei sistemi esistenti.
Continuate a leggere
Tutti gli articoli
Sviluppo software con ASES
Software su misura, app web e mobile