Salvataggio dello stato con i frammenti

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.

* 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:

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:

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:

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putBoolean(IS_EDITING_KEY, isEditing)
    outState.putString(RANDOM_GOOD_DEED_KEY, randomGoodDeed)
}

@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:

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    isEditing = savedInstanceState?.getBoolean(IS_EDITING_KEY, false)
    randomGoodDeed = savedInstanceState?.getString(RANDOM_GOOD_DEED_KEY)
            ?: viewModel.generateRandomGoodDeed()
}

@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.

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
    }
}

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

Guide

• Modulo dello stato salvato per Visualizza modello
• Salvataggio degli stati della UI