"stato permanente" vs. "stato corrente"

Question

Tentativo di decidere (per la mia applicazione) cosa salvare in onPause() e cosa risparmiare in onSaveInstanceState(), ho combinato l'intero SO per suggerimenti e linee guida chiare.

Se ho capito bene, onSaveInstanceState() è meglio per salvare le modifiche "runtime" o "stato attuale" (qualunque cosa significhi), mentre onPause() è meglio per il salvataggio "stato permanente" (qualunque cosa significhi).

Ho ancora difficoltà a decidere cosa nella mia applicazione costituisce "stato permanente" rispetto a "stato corrente". Ad esempio, mentre le preferenze dell'utente sono chiaramente persistenti, è necessario salvarle in onPause() quando vengono sempre salvate automaticamente dall'infrastruttura utente Android quando l'utente le modifica?

I membri di classe dati devono essere salvati in onSaveInstanceState()? Devo farlo per ogni classe nella mia applicazione?

Sono confuso.

Puoi portare esempi del mondo reale di cosa deve essere salvato in onPause() e cosa deve essere salvato in onSaveInstanceState()? Except per modifiche alla configurazione del dispositivo, ovvero.

-

Alcune nuove intuizioni, dopo la mia domanda è stato risposto:

• onSaveInstanceState di Bundle è not written to anything, e non è in alcun modo persistente.
• I dati di Bundle di onSaveInstanceState saranno solo held in memory finché l'applicazione non viene chiusa.

Answer 1

Non è necessario memorizzare le preferenze utente in onPause perché, come dici tu, il framework lo fa per te.

Per distinguere tra dati persistenti e informazioni di stato, pensare a un'applicazione di editor di testo.

dati persistenti

Diciamo che l'utente ha digitato un paio di parole e poi esce l'applicazione. L'utente non ci ha detto esplicitamente di salvare quei dati in un file, ma sarebbe sicuramente bello archiviarli per quando torneranno. Si tratta di dati persistenti e si desidera archiviarli in onPause().

dati relativi allo stato

Allo stesso modo, supponiamo di avere 2 schede e una variabile che tiene traccia di scheda, che è attualmente selezionato. Si tratta di dati di stato archiviati in onSaveInstanceState().

Gray Matter

Infine immaginate di avere una classe in l'editor che tiene traccia del numero di caratteri e il numero di linee nell'editor. Si tratta di dati di stato, è possibile archiviarli in onSaveInstanceState() oppure è possibile buttarli via e ricalcolarli semplicemente quando si riavvia. Se lo si butta via potrebbe dipendere da quanto tempo occorre per calcolare, ad esempio se si può impedire una richiesta di rete memorizzando i dati, farlo.

Ulteriori pensieri

giocando con la vostra applicazione dovrebbe essere ovvio se c'è un settore in cui non siete riusciti a scoiattolo i dati subito. Assicurati di fare cose come premere il tasto home e chiudere l'app dal gestore dispositivi. Ciò ti consentirà di colpire i casi d'angolo in cui la tua app viene chiusa anziché sospesa.

Se lo stato dell'interfaccia utente è coerente tra gli eventi del ciclo di vita e i dati dell'utente rimangono, buon lavoro.

Modifica sulla base di commento

Penso che ci sono 2 pezzi di criteri qui per determinare quando/cosa salvare.

Il primo è piuttosto soggettivo. Vuoi salvare i dati? Non c'è davvero nulla che ti costringa a salvare lo stato o i dati. Il salvataggio di queste informazioni renderà l'esperienza utente migliore? Se stai scrivendo un'e-mail e stai provando a copiare/incollare il testo da un'altra app, perdere l'e-mail mezza tipata ogni volta che l'app viene chiusa sarebbe frustrante.

Il secondo pezzo, che determina cosa salvare dipende dalla possibilità di ricostruire lo stato dell'interfaccia utente in base ai dati che si hanno. Ad esempio, se hai salvato i dati di testo, ciò significa che l'utente stava modificando il testo. Così ora sappiamo di passare alla scheda di modifica del testo e inserire il testo salvato.

In generale, se si desidera che l'utente ritorni nello stesso posto in cui si era interrotto, è necessario riflettere sui dati di stato necessari per tornare a quel punto. Immaginate una versione incontaminata carico della vostra applicazione

• quali dati ha bisogno di cambiare per trasformarla in l'ultimo stato l'utente sega?
• quali dati è necessario memorizzare per tornare qui?

Questo è davvero il modo in cui funziona Android, la tua attività viene distrutta e ricreata e il tuo compito è di rimettere in moto i pezzi (se scegli di farlo).

Answer 2

Ecco la risposta. Puoi salvare lo stato in tre modi diversi.

1) Applicazione per sottoclassi (non una buona idea). 2) SharedPreferences (valido per dati semplici, rapidi e affidabili) 3) Database SQLite (più complesso, anche affidabile).

Ora per rispondere alla tua domanda. Non ci sono davvero garanzie con Android. In qualsiasi momento può e può distruggere la tua applicazione senza chiamare alcuna funzione particolare prima di farlo. Quindi, se ci sono dati che è vitale per salvare, la risposta è salvarlo non appena lo si ottiene. Di solito non c'è molto vantaggio nel salvare qualcosa più tardi, se sai che avrai bisogno di qualcosa salvalo immediatamente.

onSaveInstanceState() è solo per il salvataggio di variabili temporanee relative al layout o alle modifiche di orientamento.

In sintesi persistente stato/dati (che dovrebbe sopravvivere a un incidente), dovrebbe essere salvato ASAP, non aspettare per onPause(), perché non ci sono garanzie. Questa è la realtà.

Answer 3

Il caso che ho è un gioco, in cui voglio salvare i dati persistenti su un server di giochi.

Poiché ciò potrebbe richiedere un po ', non trovo una buona cosa provare e salvare in , ma piuttosto in onStop.

Secondo i test che ho fatto, onStop sembrano essere in grado di eseguire in background mentre blocchi, atleast questo è il caso quando si preme a casa (testato con un semplice per 1-10m loop in e onStop) . Qualcuno può confermare questa teoria del blocco?

onStop NEEDS Honeycomb up (api11+), perché prima che la versione è possibile ottenere ucciso prima onClose si chiama.

Vedere here e cercare killable nella tabella - Se la realtà corrisponde alla documentazione è un'altra domanda :).