Status wird mit Fragmenten gespeichert

Der Status des Fragments kann durch verschiedene Android-Systemvorgänge beeinflusst werden. Damit der Status des Nutzers gespeichert wird, hat das Android-Framework Die Fragmente und der Back-Stack werden gespeichert und wiederhergestellt. Daher benötigen Sie um sicherzustellen, dass alle Daten in Ihrem Fragment ebenfalls gespeichert und wiederhergestellt werden.

In der folgenden Tabelle sind die Vorgänge aufgeführt, die zum Verlust Ihres Fragments führen. und ermitteln, ob die verschiedenen Statustypen Änderungen. In der Tabelle werden die folgenden Statustypen aufgeführt:

• Variablen: lokale Variablen im Fragment.
• Ansichtsstatus: alle Daten, die zu einer oder mehreren Datenansichten im Fragment gehören
• SavedState: zu dieser Fragmentinstanz gehörende Daten, die gespeichert werden sollen in „onSaveInstanceState()“.
• NonConfig: Daten, die von einer externen Quelle abgerufen werden, z. B. einem Server oder einer lokalen Quelle Repository oder vom Nutzer erstellte Daten, die nach dem Commit an einen Server gesendet werden.

Häufig werden Variablen wie SavedState behandelt, aber In der folgenden Tabelle wird zwischen den beiden Methoden unterschieden, um den Effekt darzustellen der verschiedenen Vorgänge auf jedem Gerät.

Betrieb	Variablen	Ansichtsstatus	SavedState	NonConfig
Zum Back Stack hinzugefügt	✓	✓	x	✓
Konfigurationsänderung	x	✓	✓	✓
Prozess Tod/Freizeit	x	✓	✓	✓*
Entfernt und nicht zum Back Stack hinzugefügt	x	x	x	x
Organisator beendet	x	x	x	x

* Der NonConfig-Status kann über die Methode Modul „Saved State“ für ViewModel

Tabelle 1:Verschiedene destruktive Fragmentierung und ihre Auswirkungen die sie für verschiedene Bundesstaattypen haben.

Sehen wir uns ein konkretes Beispiel an. Nehmen wir einen Bildschirm, der ein zufälliger String erstellt, wird in einem TextView angezeigt und bietet eine Option zum Bearbeiten die Zeichenfolge, bevor du sie an einen Freund sendest:

<ph type="x-smartling-placeholder">

</ph>

Abbildung 1: Zufallstextgenerator-App, die verschiedene Arten von Bundesstaaten.

Nehmen wir für dieses Beispiel an, dass die Nutzenden, sobald sie auf die Schaltfläche „Bearbeiten“ klicken, App zeigt eine EditText-Ansicht an, in der der Nutzer die Mitteilung bearbeiten kann. Wenn die der Nutzer auf ABBRECHEN klickt, sollte die Ansicht EditText gelöscht und die Sichtbarkeit auf View.GONE eingestellt. Ein solches vier Daten verwalten müssen, um eine nahtlose Erfahrung:

Daten	Typ	Bundeslandtyp	Beschreibung
seed	Long	NonConfig	Seed-Wert, der zur zufälligen Erzeugung einer neuen guten Tat verwendet wird. Wird generiert, wenn Die ViewModel wird erstellt.
randomGoodDeed	String	SavedState + Variable	Wird bei der ersten Erstellung des Fragments generiert. randomGoodDeed wird gespeichert, damit Nutzer die auch nach dem Tod des Prozesses Freizeitaktivitäten.
isEditing	Boolean	SavedState + Variable	Das boolesche Flag wird auf true gesetzt, wenn der Nutzer mit dem Bearbeiten beginnt. isEditing wird gespeichert, damit der Bearbeitungsteil von bleibt der Bildschirm sichtbar, wenn das Fragment neu erstellt wird.
Bearbeiteter Text	Editable	Status ansehen (Eigentum von EditText)	Der bearbeitete Text in der Ansicht EditText. In der Ansicht „EditText“ wird dieser Text gespeichert, damit der Nutzer laufende Änderungen gehen nicht verloren.

Tabelle 2:Gibt an, dass die Zufallstextgenerator-App dies verwalten muss.

In den folgenden Abschnitten wird beschrieben, wie Sie den Status Ihrer Daten richtig verwalten durch destruktive Angriffe.

Status ansehen

Datenansichten sind für die Verwaltung ihres eigenen Status verantwortlich. Wenn zum Beispiel ein die Nutzereingabe akzeptiert, liegt es in der Verantwortung der Ansicht, diese zu speichern und wiederherzustellen. um Konfigurationsänderungen zu verarbeiten. Alle vom Android-Framework bereitgestellten Aufrufe haben ihre eigene Implementierung von onSaveInstanceState() und onRestoreInstanceState(). Sie müssen den Ansichtsstatus also nicht in Ihr Fragment.

Hinweis: Damit Konfigurationsänderungen ordnungsgemäß verarbeitet werden, sollten Sie Implementieren von onSaveInstanceState() und onRestoreInstanceState() für alle benutzerdefinierte Ansichten erstellen.

Im vorherigen Szenario wird der bearbeitete String beispielsweise in einem EditText Ein EditText weiß, den Wert des angezeigten Textes sowie andere Details wie Anfang und Ende eines ausgewählten Textes.

Eine Ansicht benötigt eine ID, um ihren Status beizubehalten. Diese ID muss innerhalb des Fragments und seiner Ansichtshierarchie. Ansichten ohne ID können keine ihren Bundesstaat.

<EditText
    android:id="@+id/good_deed_edit_text"
    android:layout_width="match_parent"
    android:layout_height="wrap_content" />

Wie in Tabelle 1 erwähnt, werden ViewState in Ansichten gespeichert und wiederherstellen Alle Vorgänge, bei denen das Fragment nicht entfernt oder der Host nicht zerstört wird.

SavedState

Ihr Fragment ist für die Verwaltung kleiner Bereiche des dynamischen Zustands verantwortlich. die entscheidend für die Funktionsweise des Fragments sind. Sie können ganz einfach zu serialisieren, Fragment.onSaveInstanceState(Bundle) Ähnlich wie Activity.onSaveInstanceState(Bundle), Die Daten, die Sie in das Bundle einfügen, werden durch Konfigurationsänderungen beibehalten. und Prozess Tod und Erholung und ist im onCreate(Bundle), onCreateView(LayoutInflater, ViewGroup, Bundle), und onViewCreated(View, Bundle). .

Achtung :onSaveInstanceState(Bundle) wird nur aufgerufen, wenn der Host des Fragments ruft eine Aktivität ihr eigenes onSaveInstanceState(Bundle) auf.

Tipp :Wenn Sie ViewModel verwenden, können Sie den Status direkt im ViewModel mit SavedStateHandle. Weitere Informationen finden Sie unter Modul „Saved State“ für ViewModel

Um auf das vorherige Beispiel zurückzukommen: randomGoodDeed ist die Tat, angezeigt wird, und isEditing ist ein Kennzeichen, mit dem bestimmt wird, ob der Fragment blendet EditText ein oder aus. Dieser gespeicherte Status sollte mit onSaveInstanceState(Bundle) beibehalten, wie im Folgenden gezeigt Beispiel:

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

Rufen Sie zum Wiederherstellen des Status in onCreate(Bundle) den gespeicherten Wert ab aus des Pakets:

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();
    }
}

Wie in Tabelle 1 erwähnt, bleiben die Variablen erhalten, wird im Backstack platziert. Wenn sie als gespeicherter Status behandelt werden, Sie bestehen bei allen destruktiven Vorgängen.

NonConfig

NonConfig-Daten sollten außerhalb Ihres Fragments platziert werden, z. B. in ViewModel. In der vorherigen Im obigen Beispiel wird seed (unser NonConfig-Status) in ViewModel generiert. Die Logik zur Beibehaltung des Status gehört 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;
    }
}

Die Klasse ViewModel sorgt von Natur aus dafür, dass Daten die Konfiguration überleben. z. B. Bildschirmdrehungen, und bleibt im Arbeitsspeicher, wird im Back Stack platziert. Nach Prozesstod und Genesung ViewModel wird neu erstellt und eine neue seed generiert. Hinzufügen eines Modul SavedState ViewModel hinzufügen, kann ViewModel den einfachen Zustand beibehalten, Tod und Genesung zu verarbeiten.

Weitere Informationen

Weitere Informationen zum Verwalten des Fragmentstatus finden Sie in den folgenden zusätzliche Ressourcen.

Codelabs

• Codelab zu Lebenszyklusbewussten Komponenten

Leitfäden

• Modul „Gespeicherter Status“ zur Ansicht des Modells
• UI-Status speichern