Lo stato del frammento può essere influenzato da varie operazioni di sistema Android. Per assicurarsi che lo stato dell'utente venga salvato, il framework Android automaticamente salva e ripristina i frammenti e il back stack. Pertanto, devi avere per garantire che anche tutti i dati del frammento vengano salvati e ripristinati.
La tabella seguente illustra le operazioni che causano la perdita del frammento stato, nonché se i vari tipi di stato persistono attraverso quelle modifiche. I tipi di stato menzionati nella tabella sono i seguenti:
- Variabili: variabili locali nel frammento.
- Stato visualizzazione: tutti i dati di proprietà di una o più viste nel frammento.
- SavedState: dati inerenti a questa istanza del frammento che devono essere salvati
a
onSaveInstanceState()
. - NonConfig: dati estratti da un'origine esterna, ad esempio un server o un server locale repository o dati creati dall'utente che vengono inviati a un server dopo il commit.
Spesso le variabili vengono trattate come SavedState, ma i valori la seguente tabella fa una distinzione tra i due per dimostrare l'effetto delle varie operazioni su ciascuno.
Funzionamento | Variabili | Visualizza stato | Stato salvato | Non-configurazione |
---|---|---|---|---|
Aggiunto allo stack posteriore | ✓ | ✓ | x | ✓ |
Modifica della configurazione | x | ✓ | ✓ | ✓ |
Morte/ricreazione da parte di processi | x | ✓ | ✓ | ✓* |
Rimosso non aggiunto al back stack | x | x | x | x |
Host completato | x | x | x | x |
* Lo stato NonConfig può essere conservato fino al termine del processo utilizzando Modulo Stato salvato per ViewModel.
Tabella 1: varie operazioni distruttive dei frammenti ed effetti che hanno in tipi di stato diversi.
Esaminiamo un esempio specifico. Consideriamo una schermata che generi un
stringa casuale, la visualizza in un TextView
e offre un'opzione per modificare
la stringa prima di inviarla a un amico:
![generatore di testo casuale che dimostra varie
tipi di stato](https://developer.android.com/static/images/guide/fragments/text-generator-app.png?authuser=8&hl=it)
Per questo esempio, supponiamo che una volta che l'utente preme il pulsante di modifica,
l'app mostra una visualizzazione EditText
in cui l'utente può modificare il messaggio. Se
l'utente fa clic su ANNULLA, la visualizzazione EditText
deve essere cancellata
visibilità impostata su View.GONE
. Tale
una schermata potrebbe richiedere la gestione di quattro dati per garantire
esperienza utente:
Dati | Tipo | Tipo di stato | Descrizione |
---|---|---|---|
seed |
Long |
Non-configurazione | Seme usato per generare casualmente una nuova buona azione. Generata quando
Creazione di ViewModel . |
randomGoodDeed |
String |
SavedState + Variabile | Generato quando il frammento viene creato per la prima volta.
randomGoodDeed viene salvato per garantire che gli utenti visualizzino
la stessa buona azione casuale anche dopo la morte
attività ricreative. |
isEditing |
Boolean |
SavedState + Variabile | Flag booleano impostato su true quando l'utente inizia la modifica.
isEditing viene salvato per garantire che la parte di modifica di
la schermata rimane visibile quando il frammento viene ricreato. |
Testo modificato | Editable |
Visualizza stato (di proprietà di EditText ) |
Il testo modificato nella visualizzazione EditText .
La visualizzazione EditText salva questo testo per garantire che l'utente
le modifiche in corso non andranno perse. |
Tabella 2: indica che deve essere gestita l'app per la generazione di testo casuale.
Le seguenti sezioni descrivono come gestire correttamente lo stato dei dati attraverso operazioni distruttive.
Visualizza stato
Le viste sono responsabili della gestione del proprio stato. Ad esempio, quando
visualizza accetta input utente, è responsabilità della vista salvare e ripristinare
quell'input per gestire le modifiche alla configurazione. Tutti i framework Android forniti
viste hanno una propria implementazione di onSaveInstanceState()
onRestoreInstanceState()
, quindi non devi gestire lo stato di visualizzazione all'interno
il tuo frammento.
Ad esempio, nello scenario precedente, la stringa modificata si trova in una
EditText
Un EditText
sa
il valore del testo visualizzato, oltre ad altri dettagli, come
l'inizio e la fine di qualsiasi testo selezionato.
Una vista necessita di un ID per mantenere il proprio stato. Questo ID deve essere univoco all'interno e la sua gerarchia di visualizzazione. Le viste senza un ID non possono essere conservate il proprio stato.
<EditText android:id="@+id/good_deed_edit_text" android:layout_width="match_parent" android:layout_height="wrap_content" />
Come indicato nella tabella 1, le visualizzazioni salvano e ripristinano il valore da ViewState
a
tutte le operazioni che non rimuoveranno il frammento o non distruggono l'host.
SavedState
Il frammento è responsabile della gestione di piccole quantità di stati dinamici
fondamentali al funzionamento del frammento. Puoi conservare
i dati vengono facilmente serializzati utilizzando
Fragment.onSaveInstanceState(Bundle)
Simile a
Activity.onSaveInstanceState(Bundle)
,
i dati inseriti nel bundle vengono conservati mediante modifiche alla configurazione
ed elaborare la morte e la ricreazione ed è disponibile nel
onCreate(Bundle)
,
onCreateView(LayoutInflater, ViewGroup, Bundle)
,
e
onViewCreated(View, Bundle)
di machine learning.
Continuando con l'esempio precedente, randomGoodDeed
è l'atto che è
visualizzato all'utente e isEditing
è un flag per determinare se
mostra o nasconde EditText
. Lo stato salvato dovrebbe essere
è stato mantenuto mediante onSaveInstanceState(Bundle)
, come mostrato di seguito
esempio:
Kotlin
override fun onSaveInstanceState(outState: Bundle) { super.onSaveInstanceState(outState) outState.putBoolean(IS_EDITING_KEY, isEditing) outState.putString(RANDOM_GOOD_DEED_KEY, randomGoodDeed) }
Java
@Override public void onSaveInstanceState(@NonNull Bundle outState) { super.onSaveInstanceState(outState); outState.putBoolean(IS_EDITING_KEY, isEditing); outState.putString(RANDOM_GOOD_DEED_KEY, randomGoodDeed); }
Per ripristinare lo stato in onCreate(Bundle)
, recupera il valore memorizzato da
il bundle:
Kotlin
override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) isEditing = savedInstanceState?.getBoolean(IS_EDITING_KEY, false) randomGoodDeed = savedInstanceState?.getString(RANDOM_GOOD_DEED_KEY) ?: viewModel.generateRandomGoodDeed() }
Java
@Override public void onCreate(@Nullable Bundle savedInstanceState) { super.onCreate(savedInstanceState); if (savedInstanceState != null) { isEditing = savedInstanceState.getBoolean(IS_EDITING_KEY, false); randomGoodDeed = savedInstanceState.getString(RANDOM_GOOD_DEED_KEY); } else { randomGoodDeed = viewModel.generateRandomGoodDeed(); } }
Come indicato nella tabella 1, tieni presente che le variabili vengono conservate quando del frammento è posizionato sul backstack. Trattarli come stato salvato garantisce rimangono in tutte le operazioni distruttive.
Non-configurazione
I dati NonConfig devono essere posizionati all'esterno del frammento, ad esempio in
Un ViewModel
. Nella precedente
nell'esempio precedente, seed
(il nostro stato NonConfig) viene generato in ViewModel
.
La logica per mantenere il proprio stato è di proprietà di ViewModel
.
Kotlin
public class RandomGoodDeedViewModel : ViewModel() { private val seed = ... // Generate the seed private fun generateRandomGoodDeed(): String { val goodDeed = ... // Generate a random good deed using the seed return goodDeed } }
Java
public class RandomGoodDeedViewModel extends ViewModel { private Long seed = ... // Generate the seed private String generateRandomGoodDeed() { String goodDeed = ... // Generate a random good deed using the seed return goodDeed; } }
La classe ViewModel
consente intrinsecamente la permanenza dei dati alla configurazione
modifiche, come la rotazione dello schermo, e rimane in memoria quando
è collocato sulla pila posteriore. Dopo la morte e lo svago dei processi,
viene ricreato l'elemento ViewModel
e generato un nuovo seed
. L'aggiunta di un
Modulo SavedState
al tuo ViewModel
consente a ViewModel
di mantenere lo stato semplice tramite
processo di morte e ricreazione.
Risorse aggiuntive
Per ulteriori informazioni sulla gestione dello stato dei frammenti, consulta quanto segue risorse aggiuntive.
Codelab
- Codelab sui componenti sensibili al ciclo di vita