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.

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

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:

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.

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

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:

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

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

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

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.

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

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