Aktivitätslebenszyklus

Wenn ein Nutzer Ihre Anwendung durchläuft, wieder verlässt und zurück zu ihr führt, durchlaufen die Activity-Instanzen in Ihrer Anwendung in ihrem Lebenszyklus verschiedene Zustände. Die Klasse Activity bietet eine Reihe von Callbacks, mit denen die Aktivität informiert wird, wenn sich ein Status ändert oder dass das System eine Aktivität erstellt, beendet oder fortgesetzt oder den Prozess löscht, in dem sich die Aktivität befindet.

Innerhalb der Lebenszyklus-Callback-Methoden können Sie festlegen, wie sich Ihre Aktivität verhalten soll, wenn der Nutzer die Aktivität verlässt und wieder eintritt. Wenn Sie beispielsweise einen Streaming-Videoplayer erstellen, können Sie das Video anhalten und die Netzwerkverbindung beenden, wenn der Nutzer zu einer anderen App wechselt. Wenn der Nutzer zurückkehrt, können Sie die Verbindung zum Netzwerk wiederherstellen und es dem Nutzer ermöglichen, das Video von derselben Stelle aus fortzusetzen.

Mit jedem Callback können Sie bestimmte Arbeiten ausführen, die einer bestimmten Statusänderung entsprechen. Die richtige Arbeit zur richtigen Zeit und die richtige Verarbeitung von Übergängen machen Ihre App robust und leistungsfähiger. Durch eine gute Implementierung der Lebenszyklus-Callbacks lässt sich beispielsweise Folgendes vermeiden:

• Er stürzt ab, wenn der Nutzer einen Anruf erhält oder während der Nutzung der App zu einer anderen App wechselt.
• Wertvolle Systemressourcen werden verbraucht, wenn der Nutzer sie nicht aktiv verwendet.
• Sie verlieren den Fortschritt des Nutzers, wenn er die App verlässt und später wieder zu ihr zurückkehrt.
• Absturz oder Fortschritt des Nutzers, wenn der Bildschirm zwischen Quer- und Hochformat wechselt.

In diesem Dokument wird der Aktivitätslebenszyklus ausführlich erläutert. Zunächst wird das Lebenszyklusparadigma beschrieben. Als Nächstes wird jeder Callback erläutert: Was intern bei der Ausführung geschieht und was Sie dabei implementieren müssen.

Anschließend wird kurz die Beziehung zwischen dem Aktivitätsstatus und der Anfälligkeit eines Prozesses für die Löschung durch das System erläutert. Abschließend werden verschiedene Themen in Verbindung mit Übergängen zwischen Aktivitätsstatus behandelt.

Informationen zum Umgang mit Lebenszyklen sowie zu Best Practices finden Sie unter Umgang mit Lebenszyklen mit lebenszyklussensitiven Komponenten und UI-Status speichern. Informationen zum Erstellen einer robusten App in Produktionsqualität mithilfe von Aktivitäten in Kombination mit Architekturkomponenten finden Sie im Leitfaden zur Anwendungsarchitektur.

Konzepte des Aktivitätslebenszyklus

Für die Übergänge zwischen den Phasen des Aktivitätslebenszyklus bietet die Klasse Activity einen zentralen Satz von sechs Callbacks: onCreate(), onStart(), onResume(), onPause(), onStop() und onDestroy(). Das System ruft jeden dieser Callbacks auf, wenn die Aktivität einen neuen Status erreicht.

In Abbildung 1 ist dieses Modell visuell dargestellt.

Abbildung 1: Eine vereinfachte Darstellung des Aktivitätslebenszyklus.

Wenn der Nutzer beginnt, die Aktivität zu verlassen, ruft das System Methoden zum Beenden der Aktivität auf. In einigen Fällen wird die Aktivität nur teilweise entfernt und verbleibt im Arbeitsspeicher, z. B. wenn der Nutzer zu einer anderen App wechselt. In diesen Fällen kann die Aktivität trotzdem in den Vordergrund zurückkehren.

Wenn der Nutzer zur Aktivität zurückkehrt, wird sie an der Stelle fortgesetzt, an der er sie unterbrochen hat. Mit wenigen Ausnahmen können Anwendungen nicht Aktivitäten starten, wenn sie im Hintergrund ausgeführt werden.

Die Wahrscheinlichkeit, dass das System einen bestimmten Prozess beendet, und die darin enthaltenen Aktivitäten hängen vom Zustand der Aktivität zu diesem Zeitpunkt ab. Weitere Informationen zur Beziehung zwischen Status und Sicherheitslücke zum Ausschluss finden Sie im Abschnitt zum Aktivitätsstatus und Ausschluss aus dem Arbeitsspeicher.

Je nach Komplexität Ihrer Aktivität müssen Sie wahrscheinlich nicht alle Lebenszyklusmethoden implementieren. Es ist jedoch wichtig, dass Sie die einzelnen Komponenten verstehen und diejenigen implementieren, die dafür sorgen, dass sich Ihre App so verhält, wie die Nutzer es erwarten.

Lebenszyklus-Callbacks

Dieser Abschnitt enthält Konzept- und Implementierungsinformationen zu den Callback-Methoden, die während des Aktivitätslebenszyklus verwendet werden.

Einige Aktionen gehören zu den Methoden des Aktivitätslebenszyklus. Platziere den Code jedoch, der die Aktionen einer abhängigen Komponente implementiert, in die Komponente und nicht in die Methode des Aktivitätslebenszyklus. Dazu müssen Sie die abhängige Komponente auf den Lebenszyklus aufmerksam machen. Unter Umgang mit Lebenszyklen mit lebenszyklussensitiven Komponenten erfahren Sie, wie Sie Ihre abhängigen Komponenten auf den Lebenszyklus aufmerksam machen.

onCreate()

Sie müssen diesen Callback implementieren, der ausgelöst wird, wenn das System zum ersten Mal die Aktivität erstellt. Beim Erstellen einer Aktivität erhält die Aktivität den Status Erstellt. Führen Sie in der Methode onCreate() eine grundlegende Startlogik für die Anwendung aus, die während der gesamten Lebensdauer der Aktivität nur einmal ausgeführt wird.

Ihre Implementierung von onCreate() könnte beispielsweise Daten an Listen binden, die Aktivität mit einer ViewModel verknüpfen und einige Variablen auf Klassenebene instanziieren. Diese Methode empfängt den Parameter savedInstanceState, ein Bundle-Objekt, das den zuvor gespeicherten Status der Aktivität enthält. Wenn die Aktivität noch nie existiert hat, ist der Wert des Bundle-Objekts null.

Wenn Sie eine Komponente, die den Lebenszyklus berücksichtigt, an den Lebenszyklus Ihrer Aktivität angehängt ist, empfängt sie das Ereignis ON_CREATE. Die mit @OnLifecycleEvent annotierte Methode wird aufgerufen, damit Ihre lebenszyklussensitive Komponente jeden Einrichtungscode ausführen kann, den sie für den erstellten Status benötigt.

Das folgende Beispiel der Methode onCreate() zeigt die grundlegende Einrichtung der Aktivität, z. B. das Deklarieren der Benutzeroberfläche (definiert in einer XML-Layoutdatei), das Definieren von Mitgliedsvariablen und das Konfigurieren einiger Benutzeroberfläche. In diesem Beispiel übergibt die XML-Layoutdatei die Ressourcen-ID R.layout.main_activity der Datei an setContentView().

lateinit var textView: TextView

// Some transient state for the activity instance.
var gameState: String? = null

override fun onCreate(savedInstanceState: Bundle?) {
    // Call the superclass onCreate to complete the creation of
    // the activity, like the view hierarchy.
    super.onCreate(savedInstanceState)

    // Recover the instance state.
    gameState = savedInstanceState?.getString(GAME_STATE_KEY)

    // Set the user interface layout for this activity.
    // The layout is defined in the project res/layout/main_activity.xml file.
    setContentView(R.layout.main_activity)

    // Initialize member TextView so it is available later.
    textView = findViewById(R.id.text_view)
}

// This callback is called only when there is a saved instance previously saved using
// onSaveInstanceState(). Some state is restored in onCreate(). Other state can optionally
// be restored here, possibly usable after onStart() has completed.
// The savedInstanceState Bundle is same as the one used in onCreate().
override fun onRestoreInstanceState(savedInstanceState: Bundle?) {
    textView.text = savedInstanceState?.getString(TEXT_VIEW_KEY)
}

// Invoked when the activity might be temporarily destroyed; save the instance state here.
override fun onSaveInstanceState(outState: Bundle?) {
    outState?.run {
        putString(GAME_STATE_KEY, gameState)
        putString(TEXT_VIEW_KEY, textView.text.toString())
    }
    // Call superclass to save any view hierarchy.
    super.onSaveInstanceState(outState)
}

TextView textView;

// Some transient state for the activity instance.
String gameState;

@Override
public void onCreate(Bundle savedInstanceState) {
    // Call the superclass onCreate to complete the creation of
    // the activity, like the view hierarchy.
    super.onCreate(savedInstanceState);

    // Recover the instance state.
    if (savedInstanceState != null) {
        gameState = savedInstanceState.getString(GAME_STATE_KEY);
    }

    // Set the user interface layout for this activity.
    // The layout is defined in the project res/layout/main_activity.xml file.
    setContentView(R.layout.main_activity);

    // Initialize member TextView so it is available later.
    textView = (TextView) findViewById(R.id.text_view);
}

// This callback is called only when there is a saved instance previously saved using
// onSaveInstanceState(). Some state is restored in onCreate(). Other state can optionally
// be restored here, possibly usable after onStart() has completed.
// The savedInstanceState Bundle is same as the one used in onCreate().
@Override
public void onRestoreInstanceState(Bundle savedInstanceState) {
    textView.setText(savedInstanceState.getString(TEXT_VIEW_KEY));
}

// Invoked when the activity might be temporarily destroyed; save the instance state here.
@Override
public void onSaveInstanceState(Bundle outState) {
    outState.putString(GAME_STATE_KEY, gameState);
    outState.putString(TEXT_VIEW_KEY, textView.getText());

    // Call superclass to save any view hierarchy.
    super.onSaveInstanceState(outState);
}

Anstatt die XML-Datei zu definieren und an setContentView() zu übergeben, können Sie neue View-Objekte in Ihrem Aktivitätscode erstellen und eine Ansichtshierarchie erstellen, indem Sie neue View-Objekte in eine ViewGroup einfügen. Dieses Layout verwenden Sie dann, indem Sie den Stamm-ViewGroup an setContentView() übergeben. Weitere Informationen zum Erstellen einer Benutzeroberfläche finden Sie in der Dokumentation zur Benutzeroberfläche.

Ihre Aktivität bleibt nicht im Status „Erstellt“. Nachdem die Ausführung der Methode onCreate() abgeschlossen ist, wechselt die Aktivität in den Status Started (Gestartet) und das System ruft die Methoden onStart() und onResume() schnell hintereinander auf.

onStart()

Wenn die Aktivität in den Status „Gestartet“ übergeht, ruft das System onStart() auf. Durch diesen Aufruf wird die Aktivität für den Nutzer sichtbar, während die App darauf vorbereitet, dass die Aktivität in den Vordergrund eintritt und interaktiv wird. In dieser Methode wird beispielsweise der Code initialisiert, der die UI verwaltet.

Wenn die Aktivität in den Status „Gestartet“ wechselt, empfängt jede mit dem Lebenszyklus der Aktivität verknüpfte Komponente, die den Lebenszyklus berücksichtigt, das Ereignis ON_START.

Die Methode onStart() wird schnell abgeschlossen und wie beim Status „Erstellt“ bleibt die Aktivität nicht im Status „Gestartet“. Sobald dieser Callback abgeschlossen ist, wird die Aktivität in den Status Fortsetzen versetzt und das System ruft die Methode onResume() auf.

onResume()

Wenn die Aktivität in den Status „Fortsetzen“ wechselt, gelangt sie in den Vordergrund und das System ruft den onResume()-Callback auf. Dies ist der Status, in dem die App mit dem Nutzer interagiert. Die App bleibt in diesem Zustand, bis der Fokus von der App weggeworfen wird, z. B. wenn das Gerät einen Anruf empfängt, der Nutzer zu einer anderen Aktivität wechselt oder sich der Bildschirm des Geräts ausschaltet.

Wenn die Aktivität in den Status „Fortsetzen“ wechselt, empfängt jede mit dem Lebenszyklus der Aktivität verknüpfte Komponente, die den Lebenszyklus berücksichtigt, das Ereignis ON_RESUME. Hier können mit den Lebenszykluskomponenten alle Funktionen aktiviert werden, die ausgeführt werden müssen, während die Komponente sichtbar und im Vordergrund ausgeführt wird, z. B. das Starten einer Kameravorschau.

Wenn ein unterbrechendes Ereignis eintritt, wechselt die Aktivität in den Status Pausiert und das System ruft den onPause()-Callback auf.

Wenn die Aktivität aus dem Status „Pausiert“ in den Status „Fortsetzen“ zurückkehrt, ruft das System noch einmal die Methode onResume() auf. Implementieren Sie daher onResume(), um Komponenten zu initialisieren, die Sie während onPause() freigeben, und um alle anderen Initialisierungen auszuführen, die jedes Mal auftreten müssen, wenn die Aktivität in den Status „Fortsetzen“ übergeht.

Hier ist ein Beispiel für eine Komponente, die den Lebenszyklus berücksichtigt und auf die Kamera zugreift, wenn die Komponente das Ereignis ON_RESUME empfängt:

class CameraComponent : LifecycleObserver {
    ...
    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun initializeCamera() {
        if (camera == null) {
            getCamera()
        }
    }
    ...
}

public class CameraComponent implements LifecycleObserver {

    ...

    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    public void initializeCamera() {
        if (camera == null) {
            getCamera();
        }
    }
    ...
}

Mit dem vorherigen Code wird die Kamera initialisiert, sobald das LifecycleObserver-Ereignis das ON_RESUME-Ereignis empfängt. Im Mehrfenstermodus ist Ihre Aktivität jedoch möglicherweise vollständig sichtbar, auch wenn sie pausiert ist. Wenn sich die App beispielsweise im Mehrfenstermodus befindet und der Nutzer auf das Fenster tippt, das Ihre Aktivität nicht enthält, wird Ihre Aktivität in den Status „Pausiert“ versetzt.

Wenn Sie möchten, dass die Kamera nur dann aktiviert wird, wenn die App fortgesetzt wird, also im Vordergrund sichtbar und aktiv ist, initialisieren Sie die Kamera nach dem zuvor erwähnten ON_RESUME-Ereignis. Wenn die Kamera aktiv bleiben soll, während die Aktivität pausiert, aber sichtbar ist (z. B. im Mehrfenstermodus), initialisieren Sie die Kamera nach dem Ereignis ON_START.

Wenn die Kamera jedoch aktiv ist, während Ihre Aktivität pausiert ist, kann der Zugriff auf die Kamera einer anderen fortgesetzten App im Mehrfenstermodus verweigert werden. Manchmal ist es notwendig, die Kamera aktiv zu lassen, während Ihre Aktivität pausiert ist. In diesem Fall kann dies jedoch tatsächlich die gesamte Nutzererfahrung beeinträchtigen.

Überlegen Sie sich daher genau, an welcher Stelle im Lebenszyklus es am besten ist, die Kontrolle über gemeinsam genutzte Systemressourcen im Kontext des Mehrfenstermodus zu übernehmen. Weitere Informationen zur Unterstützung des Mehrfenstermodus finden Sie unter Unterstützung des Mehrfenstermodus.

Unabhängig davon, in welchem Build-Ereignis Sie einen Initialisierungsvorgang ausführen, muss zum Freigeben der Ressource das entsprechende Lebenszyklusereignis verwendet werden. Wenn Sie etwas nach dem ON_START-Ereignis initialisieren, müssen Sie es nach dem ON_STOP-Ereignis freigeben oder beenden. Wenn die Initialisierung nach dem ON_RESUME-Ereignis erfolgt, geben Sie die Freigabe nach dem ON_PAUSE-Ereignis frei.

Mit dem vorherigen Code-Snippet wird der Initialisierungscode der Kamera in eine lebenszyklusfähige Komponente eingefügt. Sie können diesen Code stattdessen direkt in die Callbacks für den Aktivitätslebenszyklus einfügen, z. B. onStart() und onStop(). Das wird jedoch nicht empfohlen. Wenn Sie diese Logik einer unabhängigen, Lebenszyklus berücksichtigenden Komponente hinzufügen, können Sie diese für mehrere Aktivitäten wiederverwenden, ohne Code duplizieren zu müssen. Informationen zum Erstellen einer Komponente, die den Lebenszyklus berücksichtigt, finden Sie unter Lebenszyklen mit lebenszyklussensitiven Komponenten handhaben.

onPause()

Das System ruft diese Methode als ersten Hinweis darauf auf, dass der Nutzer Ihre Aktivität verlässt. Dies bedeutet jedoch nicht immer, dass die Aktivität gelöscht wird. Es zeigt an, dass sich die Aktivität nicht mehr im Vordergrund befindet. Sie ist aber weiterhin sichtbar, wenn sich der Nutzer im Mehrfenstermodus befindet. Es gibt mehrere Gründe, warum eine Aktivität diesen Status erhalten kann:

• Ein Ereignis, das die Ausführung der Anwendung, wie im Abschnitt über den onResume()-Callback beschrieben, unterbricht, pausiert die aktuelle Aktivität. Dies ist der häufigste Fall.
• Im Mehrfenstermodus ist jeweils nur eine App im Fokus und das System pausiert alle anderen Apps.
• Wenn eine neue, halbtransparente Aktivität geöffnet wird, z. B. ein Dialogfeld, wird die entsprechende Aktivität pausiert. Solange die Aktivität nur teilweise sichtbar, aber nicht im Fokus ist, bleibt sie pausiert.

Wenn eine Aktivität in den Status „Pausiert“ wechselt, empfängt jede mit dem Lebenszyklus der Aktivität verknüpfte Komponente, die den Lebenszyklus berücksichtigt, das Ereignis ON_PAUSE. Hier können die Lebenszykluskomponenten alle Funktionen beenden, die nicht ausgeführt werden müssen, wenn sich die Komponente nicht im Vordergrund befindet, z. B. eine Kameravorschau.

Verwenden Sie die Methode onPause(), um Vorgänge zu pausieren oder anzupassen, die nicht fortgesetzt werden können oder in Moderation fortgesetzt werden können, während Activity im Status „Pausiert“ ist und die voraussichtlich bald fortgesetzt werden.

Mit der Methode onPause() kannst du auch Systemressourcen, Handles für Sensoren (z. B. GPS) oder Ressourcen freigeben, die sich auf die Akkulaufzeit auswirken, wenn deine Aktivität pausiert ist und der Nutzer sie nicht benötigt.

Wie im Abschnitt zu onResume() erwähnt, kann eine pausierte Aktivität jedoch weiterhin vollständig sichtbar sein, wenn sich die Anwendung im Mehrfenstermodus befindet. Sie können onStop() anstelle von onPause() verwenden, um UI-bezogene Ressourcen und Vorgänge vollständig freizugeben oder anzupassen und den Mehrfenstermodus besser zu unterstützen.

Das folgende Beispiel eines LifecycleObserver, der auf das ON_PAUSE-Ereignis reagiert, ist das Gegenstück zum vorherigen Beispiel des ON_RESUME-Ereignisses. Dabei wird die Kamera freigegeben, die nach dem Empfang des ON_RESUME-Ereignisses initialisiert wird:

class CameraComponent : LifecycleObserver {
    ...
    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun releaseCamera() {
        camera?.release()
        camera = null
    }
    ...
}

public class JavaCameraComponent implements LifecycleObserver {
    ...
    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    public void releaseCamera() {
        if (camera != null) {
            camera.release();
            camera = null;
        }
    }
    ...
}

In diesem Beispiel wird der Kamera-Release-Code platziert, nachdem das ON_PAUSE-Ereignis vom LifecycleObserver empfangen wurde.

Die Ausführung von onPause() ist sehr kurz und bietet nicht unbedingt genug Zeit, um Speichervorgänge durchzuführen. Verwenden Sie daher onPause() nicht, um Anwendungs- oder Nutzerdaten zu speichern, Netzwerkaufrufe durchzuführen oder Datenbanktransaktionen auszuführen. Solche Arbeiten sind möglicherweise nicht abgeschlossen, bevor die Methode abgeschlossen ist.

Führen Sie stattdessen während onStop() hohe Arbeitslasten zum Herunterfahren aus. Weitere Informationen zu geeigneten Vorgängen, die während onStop() ausgeführt werden können, finden Sie im nächsten Abschnitt. Weitere Informationen zum Speichern von Daten finden Sie im Abschnitt Status speichern und wiederherstellen.

Der Abschluss der Methode onPause() bedeutet nicht, dass die Aktivität den Status „Pausiert“ verlässt. Vielmehr bleibt die Aktivität in diesem Status, bis sie entweder fortgesetzt wird oder für den Nutzer vollständig unsichtbar wird. Wenn die Aktivität fortgesetzt wird, ruft das System wieder den onResume()-Callback auf.

Wenn die Aktivität vom Status „Pausiert“ in den Status „Fortsetzen“ zurückkehrt, behält das System die Instanz Activity im Arbeitsspeicher und ruft diese Instanz auf, wenn das System onResume() aufruft. In diesem Szenario müssen Sie Komponenten, die während einer der Callback-Methoden erstellt wurden, die zum Status „Fortsetzen“ führen, nicht neu initialisieren. Wenn die Aktivität vollständig unsichtbar wird, ruft das System onStop() auf.

onStop()

Wenn Ihre Aktivität für den Nutzer nicht mehr sichtbar ist, wird sie in den Status Angehalten versetzt und das System ruft den Callback onStop() auf. Das kann passieren, wenn eine neu gestartete Aktivität den gesamten Bildschirm abdeckt. Das System ruft auch onStop() auf, wenn die Aktivität beendet ist und bald beendet wird.

Wenn die Aktivität in den Status „Angehalten“ wechselt, empfängt jede mit dem Lebenszyklus der Aktivität verknüpfte Komponente, die den Lebenszyklus berücksichtigt, das Ereignis ON_STOP. Hier können die Lebenszykluskomponenten alle Funktionen beenden, die nicht ausgeführt werden müssen, solange die Komponente nicht auf dem Bildschirm sichtbar ist.

Geben Sie in der Methode onStop() Ressourcen frei oder passen Sie diese an, wenn die Anwendung für den Nutzer nicht sichtbar ist. Ihre App kann beispielsweise Animationen pausieren oder von detaillierten zu groben Standortupdates wechseln. Wenn Sie onStop() anstelle von onPause() verwenden, werden UI-bezogene Aufgaben auch dann weitergeführt, wenn der Nutzer Ihre Aktivitäten im Mehrfenstermodus ansieht.

Verwenden Sie außerdem onStop(), um relativ CPU-intensive Herunterfahrensvorgänge auszuführen. Wenn Sie beispielsweise keinen besseren Zeitpunkt finden, um Informationen in einer Datenbank zu speichern, können Sie dies während der onStop() nachholen. Das folgende Beispiel zeigt eine Implementierung von onStop(), die den Inhalt eines Notizenentwurfs im nichtflüchtigen Speicher speichert:

override fun onStop() {
    // Call the superclass method first.
    super.onStop()

    // Save the note's current draft, because the activity is stopping
    // and we want to be sure the current note progress isn't lost.
    val values = ContentValues().apply {
        put(NotePad.Notes.COLUMN_NAME_NOTE, getCurrentNoteText())
        put(NotePad.Notes.COLUMN_NAME_TITLE, getCurrentNoteTitle())
    }

    // Do this update in background on an AsyncQueryHandler or equivalent.
    asyncQueryHandler.startUpdate(
            token,     // int token to correlate calls
            null,      // cookie, not used here
            uri,       // The URI for the note to update.
            values,    // The map of column names and new values to apply to them.
            null,      // No SELECT criteria are used.
            null       // No WHERE columns are used.
    )
}

@Override
protected void onStop() {
    // Call the superclass method first.
    super.onStop();

    // Save the note's current draft, because the activity is stopping
    // and we want to be sure the current note progress isn't lost.
    ContentValues values = new ContentValues();
    values.put(NotePad.Notes.COLUMN_NAME_NOTE, getCurrentNoteText());
    values.put(NotePad.Notes.COLUMN_NAME_TITLE, getCurrentNoteTitle());

    // Do this update in background on an AsyncQueryHandler or equivalent.
    asyncQueryHandler.startUpdate (
            mToken,  // int token to correlate calls
            null,    // cookie, not used here
            uri,    // The URI for the note to update.
            values,  // The map of column names and new values to apply to them.
            null,    // No SELECT criteria are used.
            null     // No WHERE columns are used.
    );
}

Im vorherigen Codebeispiel wird SQLite direkt verwendet. Wir empfehlen jedoch die Verwendung von Room, einer Persistenzbibliothek, die eine Abstraktionsebene über SQLite bietet. Weitere Informationen zu den Vorteilen von Room und zur Implementierung von Room in Ihrer Anwendung finden Sie im Leitfaden Room Persistence Library.

Wenn die Aktivität in den Status „Angehalten“ wechselt, bleibt das Objekt Activity im Arbeitsspeicher: Es behält alle Status- und Mitgliedsinformationen bei, ist jedoch nicht mit dem Fenstermanager verknüpft. Wenn die Aktivität fortgesetzt wird, ruft sie diese Informationen wieder auf.

Sie müssen Komponenten, die während einer der Callback-Methoden erstellt wurden, die zum Status „Fortsetzen“ führen, nicht neu initialisieren. Das System erfasst auch den aktuellen Status für jedes View-Objekt im Layout. Wenn der Nutzer also Text in ein EditText-Widget eingibt, wird dieser Inhalt beibehalten, sodass Sie ihn nicht speichern und wiederherstellen müssen.

Hinweis : Wenn eine Aktivität beendet wird, kann es vorkommen, dass das System den Prozess mit der Aktivität zerstört, wenn das System Arbeitsspeicher wiederherstellen muss. Auch wenn das System den Prozess löscht, während die Aktivität angehalten wird, behält das System den Status der View-Objekte (z. B. Text in einem EditText-Widget) in einem Bundle – einem Blob von Schlüssel/Wert-Paaren – bei und stellt sie wieder her, wenn der Nutzer zur Aktivität zurückkehrt. Weitere Informationen zum Wiederherstellen einer Aktivität, zu der ein Nutzer zurückkehrt, finden Sie im Abschnitt Status speichern und wiederherstellen.

Im Status „Angehalten“ kehrt die Aktivität entweder zurück, um mit dem Nutzer zu interagieren, oder sie wurde beendet und verschwindet. Wenn die Aktivität wieder auftritt, ruft das System onRestart() auf. Wenn Activity fertig ist, ruft das System onDestroy() auf.

onDestroy()

onDestroy() wird aufgerufen, bevor die Aktivität gelöscht wird. Das System ruft diesen Callback aus einem von zwei Gründen auf:

1. Die Aktivität wird beendet, weil der Nutzer sie vollständig abgelehnt hat oder weil finish() für die Aktivität aufgerufen wurde.
2. Das System löscht die Aktivität vorübergehend aufgrund einer Konfigurationsänderung, z. B. der Geräterotation oder dem Wechsel in den Mehrfenstermodus.

Wenn die Aktivität in den gelöschten Status verschoben wird, empfängt jede mit dem Lebenszyklus der Aktivität verknüpfte Komponente, die den Lebenszyklus berücksichtigt, das Ereignis ON_DESTROY. Hier können die Lebenszykluskomponenten alles bereinigen, was sie benötigen, bevor das Activity gelöscht wird.

Anstatt den Activity mit einer Logik zu versehen, um zu ermitteln, warum er gelöscht wird, können Sie ein ViewModel-Objekt verwenden, um die relevanten Ansichtsdaten für Ihre Activity aufzunehmen. Wenn Activity aufgrund einer Konfigurationsänderung neu erstellt wird, muss der ViewModel nichts tun, da er beibehalten wird und an die nächste Activity-Instanz übergeben wird.

Wenn Activity nicht neu erstellt wird, wird in ViewModel die Methode onCleared() aufgerufen. Damit können alle erforderlichen Daten bereinigt werden, bevor sie gelöscht werden. Mit der Methode isFinishing() können Sie zwischen diesen beiden Szenarien unterscheiden.

Wenn die Aktivität abgeschlossen wird, ist onDestroy() der letzte Lebenszyklus-Callback, den die Aktivität empfängt. Wenn onDestroy() als Ergebnis einer Konfigurationsänderung aufgerufen wird, erstellt das System sofort eine neue Aktivitätsinstanz und ruft dann onCreate() für diese neue Instanz in der neuen Konfiguration auf.

Der Callback onDestroy() gibt alle Ressourcen frei, die nicht von früheren Callbacks wie onStop() freigegeben wurden.

Aktivitätsstatus und Ausschluss aus dem Arbeitsspeicher

Das System beendet Prozesse, wenn Arbeitsspeicher freigegeben werden muss. Wie wahrscheinlich es ist, dass das System einen bestimmten Prozess beendet, hängt vom jeweiligen Status des Prozesses ab. Der Prozessstatus wiederum hängt vom Status der im Prozess ausgeführten Aktivität ab. Tabelle 1 zeigt die Korrelationen zwischen dem Prozessstatus, dem Aktivitätsstatus und der Wahrscheinlichkeit, dass das System den Prozess beendet. Diese Tabelle gilt nur, wenn in einem Prozess keine anderen Arten von Anwendungskomponenten ausgeführt werden.

Tabelle 1 Beziehung zwischen Prozesslebenszyklus und Aktivitätsstatus.

Das System beendet niemals eine Aktivität direkt, um Arbeitsspeicher freizugeben. Stattdessen wird der Prozess, in dem die Aktivität ausgeführt wird, beendet und nicht nur die Aktivität, sondern auch alles andere, das während des Prozesses ausgeführt wird, zerstört. Informationen zum Beibehalten und Wiederherstellen des UI-Status Ihrer Aktivität, wenn der vom System initiierte Prozess abstürzt, finden Sie im Abschnitt zum Speichern und Wiederherstellen des Status.

Der Nutzer kann einen Prozess auch beenden, indem er unter „Einstellungen“ den Anwendungsmanager verwendet, um die entsprechende Anwendung zu beenden.

Weitere Informationen zu Prozessen finden Sie unter Prozesse und Threads – Übersicht.

Vorübergehenden UI-Status speichern und wiederherstellen

Ein Nutzer erwartet, dass der UI-Status einer Aktivität während einer Konfigurationsänderung, z. B. bei Drehung oder Wechsel in den Mehrfenstermodus, gleich bleibt. Das System löscht die Aktivität jedoch standardmäßig, wenn eine solche Konfigurationsänderung auftritt. Dabei werden alle in der Aktivitätsinstanz gespeicherten UI-Zustände gelöscht.

Ebenso erwartet ein Nutzer, dass der UI-Status gleich bleibt, wenn er vorübergehend von deiner App zu einer anderen App wechselt und später zu deiner App zurückkehrt. Das System kann jedoch den Prozess Ihrer Anwendung zerstören, während der Nutzer abwesend ist und Ihre Aktivität beendet wird.

Wenn die Aktivität durch Systemeinschränkungen gelöscht wird, behalten Sie den vorübergehenden UI-Status des Nutzers mit einer Kombination aus ViewModel, onSaveInstanceState() und/oder lokalem Speicher bei. Weitere Informationen zu Nutzererwartungen im Vergleich zum Systemverhalten und dazu, wie Sie komplexe UI-Statusdaten bei vom System initiierten Aktivitäten und bei allen Prozessen am besten beibehalten können, finden Sie unter UI-Status speichern.

In diesem Abschnitt wird der Instanzstatus beschrieben und wie die Methode onSaveInstance() implementiert, bei der es sich um einen Callback für die Aktivität selbst handelt. Wenn Ihre UI-Daten einfach sind, können Sie nur onSaveInstance() verwenden, um den UI-Status sowohl über Konfigurationsänderungen als auch über den vom System initiierten Prozessabbruch beizubehalten. Da onSaveInstance() jedoch Serialisierungs-/Deserialisierungskosten verursacht, verwenden Sie in den meisten Fällen sowohl ViewModel als auch onSaveInstance(), wie unter UI-Status speichern beschrieben.

Hinweis : Weitere Informationen zu Konfigurationsänderungen, zum Einschränken der Aktivitätserstellung bei Bedarf und zum Reagieren auf diese Konfigurationsänderungen über „View System“ und Jetpack Compose finden Sie auf der Seite Konfigurationsänderungen verarbeiten.

Instanzstatus

Es gibt einige Szenarien, in denen Ihre Aktivität aufgrund des normalen Anwendungsverhaltens gelöscht wird, z. B. wenn der Nutzer auf die Schaltfläche „Zurück“ drückt oder Ihre Aktivität durch Aufrufen der Methode finish() ihr eigenes Löschen signalisiert.

Wenn Ihre Aktivität gelöscht wird, weil der Nutzer auf „Zurück“ drückt oder die Aktivität selbst beendet wird, ist sowohl das Konzept dieser Activity Instanz des Systems als auch des Nutzers für immer verschwunden. In diesen Szenarien entspricht die Erwartung der Nutzer dem Verhalten des Systems und Sie müssen nichts zusätzlich tun.

Wenn das System die Aktivität jedoch aufgrund von Systemeinschränkungen wie einer Konfigurationsänderung oder Speicherauslastung löscht, wird die tatsächliche Activity-Instanz nicht mehr angezeigt, aber das System merkt sich, dass sie existiert hat. Wenn der Nutzer versucht, zu der Aktivität zurückzukehren, erstellt das System eine neue Instanz dieser Aktivität mit einem Satz gespeicherter Daten, die den Status der Aktivität zum Zeitpunkt ihrer Löschung beschreiben.

Die gespeicherten Daten, die das System zur Wiederherstellung des vorherigen Zustands verwendet, werden als Instanzstatus bezeichnet. Es ist eine Sammlung von Schlüssel/Wert-Paaren, die in einem Bundle-Objekt gespeichert sind. Standardmäßig verwendet das System den Instanzstatus Bundle, um Informationen zu jedem View-Objekt in Ihrem Aktivitätslayout zu speichern, z. B. den in ein EditText-Widget eingegebenen Textwert.

Wenn Ihre Aktivitätsinstanz also gelöscht und neu erstellt wird, wird der Zustand des Layouts auf den vorherigen Zustand zurückgesetzt, ohne dass Sie Code benötigen. Möglicherweise enthalten Ihre Aktivitäten jedoch weitere Statusinformationen, die Sie wiederherstellen möchten, z. B. Mitgliedsvariablen, die den Fortschritt des Nutzers in der Aktivität verfolgen.

Hinweis: Damit das Android-System den Status der Ansichten in Ihrer Aktivität wiederherstellen kann, muss jede Ansicht eine eindeutige ID haben, die durch das Attribut android:id bereitgestellt wird.

Ein Bundle-Objekt eignet sich nicht zur Beibehaltung von mehr als einer trivialen Datenmenge, da es Serialisierung im Hauptthread erfordert und Systemprozessspeicher belegt. Wenn Sie mehr als eine sehr kleine Datenmenge sichern möchten, sollten Sie einen kombinierten Ansatz zur Beibehaltung von Daten verfolgen und dafür den nichtflüchtigen lokalen Speicher, die Methode onSaveInstanceState() und die Klasse ViewModel verwenden, wie unter UI-Status speichern beschrieben.

Mit onSaveInstanceState() wird der einfache, schlanke UI-Status gespeichert.

Sobald die Aktivität endet, ruft das System die Methode onSaveInstanceState() auf, damit die Aktivität Statusinformationen in einem Instanzstatus-Bundle speichern kann. Bei der Standardimplementierung dieser Methode werden vorübergehende Informationen zum Status der Ansichtshierarchie der Aktivität gespeichert, z. B. der Text in einem EditText-Widget oder die Scrollposition eines ListView-Widgets.

Wenn Sie zusätzliche Instanzstatusinformationen für Ihre Aktivität speichern möchten, überschreiben Sie onSaveInstanceState() und fügen Sie dem Objekt Bundle Schlüssel/Wert-Paare hinzu, die gespeichert werden, falls Ihre Aktivität unerwartet gelöscht wird. Wenn Sie onSaveInstanceState() überschreiben, müssen Sie die Implementierung der übergeordneten Klasse aufrufen, wenn der Status der Ansichtshierarchie in der Standardimplementierung gespeichert werden soll. Dies wird im folgenden Beispiel veranschaulicht:

override fun onSaveInstanceState(outState: Bundle?) {
    // Save the user's current game state.
    outState?.run {
        putInt(STATE_SCORE, currentScore)
        putInt(STATE_LEVEL, currentLevel)
    }

    // Always call the superclass so it can save the view hierarchy state.
    super.onSaveInstanceState(outState)
}

companion object {
    val STATE_SCORE = "playerScore"
    val STATE_LEVEL = "playerLevel"
}

static final String STATE_SCORE = "playerScore";
static final String STATE_LEVEL = "playerLevel";
// ...


@Override
public void onSaveInstanceState(Bundle savedInstanceState) {
    // Save the user's current game state.
    savedInstanceState.putInt(STATE_SCORE, currentScore);
    savedInstanceState.putInt(STATE_LEVEL, currentLevel);

    // Always call the superclass so it can save the view hierarchy state.
    super.onSaveInstanceState(savedInstanceState);
}

Hinweis : onSaveInstanceState() wird nicht aufgerufen, wenn der Nutzer die Aktivität explizit schließt, oder in anderen Fällen, wenn finish() aufgerufen wird.

Um nichtflüchtige Daten wie Nutzereinstellungen oder Daten für eine Datenbank zu speichern, sollten Sie geeignete Gelegenheiten ergreifen, wenn Ihre Aktivität im Vordergrund ausgeführt wird. Wenn sich diese Möglichkeit nicht bietet, speichern Sie persistente Daten während der onStop()-Methode.

Aktivitäts-UI-Status mithilfe des Status der gespeicherten Instanz wiederherstellen

Wenn Ihre Aktivität nach dem Löschen neu erstellt wird, können Sie den Status der gespeicherten Instanz aus dem Bundle wiederherstellen, das das System an Ihre Aktivität übergibt. Die Callback-Methoden onCreate() und onRestoreInstanceState() erhalten denselben Bundle, der die Informationen zum Instanzstatus enthält.

Da die Methode onCreate() unabhängig davon aufgerufen wird, ob das System eine neue Instanz Ihrer Aktivität erstellt oder eine vorherige Instanz neu erstellt, müssen Sie prüfen, ob der Status Bundle null ist, bevor Sie versuchen, ihn zu lesen. Wenn dieser Wert null ist, erstellt das System eine neue Instanz der Aktivität, anstatt eine vorherige gelöschte Instanz wiederherzustellen.

Das folgende Code-Snippet zeigt, wie du einige Statusdaten in onCreate() wiederherstellen kannst:

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState) // Always call the superclass first

    // Check whether we're recreating a previously destroyed instance.
    if (savedInstanceState != null) {
        with(savedInstanceState) {
            // Restore value of members from saved state.
            currentScore = getInt(STATE_SCORE)
            currentLevel = getInt(STATE_LEVEL)
        }
    } else {
        // Probably initialize members with default values for a new instance.
    }
    // ...
}

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState); // Always call the superclass first

    // Check whether we're recreating a previously destroyed instance.
    if (savedInstanceState != null) {
        // Restore value of members from saved state.
        currentScore = savedInstanceState.getInt(STATE_SCORE);
        currentLevel = savedInstanceState.getInt(STATE_LEVEL);
    } else {
        // Probably initialize members with default values for a new instance.
    }
    // ...
}

Anstatt den Status während onCreate() wiederherzustellen, können Sie onRestoreInstanceState() implementieren, das das System nach der Methode onStart() aufruft. Das System ruft onRestoreInstanceState() nur dann auf, wenn ein gespeicherter Status wiederhergestellt werden kann. Daher müssen Sie nicht prüfen, ob Bundle null ist.

override fun onRestoreInstanceState(savedInstanceState: Bundle?) {
    // Always call the superclass so it can restore the view hierarchy.
    super.onRestoreInstanceState(savedInstanceState)

    // Restore state members from saved instance.
    savedInstanceState?.run {
        currentScore = getInt(STATE_SCORE)
        currentLevel = getInt(STATE_LEVEL)
    }
}

public void onRestoreInstanceState(Bundle savedInstanceState) {
    // Always call the superclass so it can restore the view hierarchy.
    super.onRestoreInstanceState(savedInstanceState);

    // Restore state members from saved instance.
    currentScore = savedInstanceState.getInt(STATE_SCORE);
    currentLevel = savedInstanceState.getInt(STATE_LEVEL);
}

Achtung: Rufen Sie immer die Implementierung der übergeordneten Klasse von onRestoreInstanceState() auf, damit die Standardimplementierung den Zustand der Ansichtshierarchie wiederherstellen kann.

Zwischen Aktivitäten wechseln

Es ist wahrscheinlich, dass eine App während ihrer Lebensdauer eine Aktivität startet und beendet, z. B. wenn der Nutzer auf die Zurück-Taste des Geräts tippt oder die Aktivität eine andere Aktivität startet.

In diesem Abschnitt werden Themen behandelt, die Sie wissen müssen, um erfolgreiche Aktivitätsübergänge zu implementieren. Zu diesen Themen gehören das Starten einer Aktivität aus einer anderen Aktivität, das Speichern des Aktivitätsstatus und das Wiederherstellen des Aktivitätsstatus.

Eine Aktivität aus einer anderen starten

Häufig muss mit einer Aktivität irgendwann eine andere Aktivität gestartet werden. Das ist beispielsweise dann erforderlich, wenn eine App vom aktuellen Bildschirm zu einem neuen wechseln muss.

Je nachdem, ob für Ihre Aktivität ein Ergebnis aus der neuen Aktivität zurückgegeben werden soll, die gestartet werden soll, starten Sie die neue Aktivität entweder mit der Methode startActivity() oder startActivityForResult(). In beiden Fällen übergeben Sie ein Intent-Objekt.

Das Intent-Objekt gibt entweder die genaue Aktivität an, die Sie starten möchten, oder beschreibt die Art der auszuführenden Aktion. Das System wählt die entsprechende Aktivität aus, die auch aus einer anderen Anwendung stammen kann. Ein Intent-Objekt kann auch kleine Datenmengen enthalten, die für die gestartete Aktivität verwendet werden können. Weitere Informationen zur Klasse Intent finden Sie unter Intents und Intent-Filter.

startActivity()

Wenn die neu gestartete Aktivität kein Ergebnis zurückgeben muss, kann die aktuelle Aktivität sie durch Aufrufen der Methode startActivity() starten.

Wenn Sie innerhalb Ihrer eigenen Anwendung arbeiten, müssen Sie häufig einfach eine bekannte Aktivität starten. Das folgende Code-Snippet zeigt beispielsweise, wie eine Aktivität namens SignInActivity gestartet wird.

val intent = Intent(this, SignInActivity::class.java)
startActivity(intent)

Intent intent = new Intent(this, SignInActivity.class);
startActivity(intent);

Unter Umständen möchte Ihre Anwendung anhand von Daten aus Ihren Aktivitäten auch eine Aktion ausführen, z. B. eine E-Mail, eine SMS senden oder ein Statusupdate ausführen. In diesem Fall verfügt Ihre Anwendung möglicherweise nicht über eigene Aktivitäten zum Ausführen solcher Aktionen. In diesem Fall können Sie stattdessen die von anderen Anwendungen auf dem Gerät bereitgestellten Aktivitäten nutzen, die diese Aktionen für Sie ausführen können.

Hier sind Intents sehr wertvoll. Sie können einen Intent erstellen, der eine auszuführende Aktion beschreibt, und das System startet die entsprechende Aktivität aus einer anderen Anwendung. Wenn es mehrere Aktivitäten gibt, mit denen der Intent verarbeitet werden kann, kann der Nutzer auswählen, welche verwendet werden soll. Wenn Sie beispielsweise zulassen möchten, dass der Nutzer eine E-Mail-Nachricht senden kann, können Sie den folgenden Intent erstellen:

val intent = Intent(Intent.ACTION_SEND).apply {
    putExtra(Intent.EXTRA_EMAIL, recipientArray)
}
startActivity(intent)

Intent intent = new Intent(Intent.ACTION_SEND);
intent.putExtra(Intent.EXTRA_EMAIL, recipientArray);
startActivity(intent);

Das zusätzliche EXTRA_EMAIL, das dem Intent hinzugefügt wird, ist ein String-Array mit E-Mail-Adressen, an die die E-Mail gesendet werden soll. Wenn eine E-Mail-Anwendung auf diesen Intent antwortet, liest sie das im Extra enthaltene String-Array und platziert die Adressen im Feld "to" des E-Mail-Formulars. In dieser Situation beginnt die Aktivität der E-Mail-Anwendung. Wenn der Nutzer fertig ist, wird Ihre Aktivität fortgesetzt.

startActivityForResult()

Manchmal möchten Sie nach einer Aktivität ein Ergebnis erhalten. Sie können beispielsweise eine Aktivität starten, bei der der Nutzer eine Person aus einer Kontaktliste auswählen kann. Am Ende wird die ausgewählte Person zurückgegeben. Dazu rufen Sie die Methode startActivityForResult(Intent, int) auf, bei der der Ganzzahlparameter den Aufruf identifiziert.

Diese ID dient dazu, mehrere Aufrufe von startActivityForResult(Intent, int) aus derselben Aktivität zu unterscheiden. Es ist keine globale Kennung und es besteht kein Risiko, dass es zu Konflikten mit anderen Apps oder Aktivitäten kommt. Das Ergebnis wird über die Methode onActivityResult(int, int, Intent) zurückgegeben.

Wenn eine untergeordnete Aktivität beendet wird, kann sie setResult(int) aufrufen, um Daten an das übergeordnete Element zurückzugeben. Die untergeordnete Aktivität muss einen Ergebniscode bereitstellen. Dabei kann es sich um die Standardergebnisse RESULT_CANCELED, RESULT_OK oder benutzerdefinierte Werte ab RESULT_FIRST_USER handeln.

Außerdem kann die untergeordnete Aktivität optional ein Intent-Objekt zurückgeben, das weitere gewünschte Daten enthält. Die übergeordnete Aktivität verwendet die Methode onActivityResult(int, int, Intent) zusammen mit der Ganzzahl-ID, die die übergeordnete Aktivität ursprünglich angegeben hat, um die Informationen zu erhalten.

Wenn eine untergeordnete Aktivität aus irgendeinem Grund fehlschlägt, z. B. durch einen Absturz, erhält die übergeordnete Aktivität ein Ergebnis mit dem Code RESULT_CANCELED.

class MyActivity : Activity() {
    // ...

    override fun onKeyDown(keyCode: Int, event: KeyEvent?): Boolean {
        if (keyCode == KeyEvent.KEYCODE_DPAD_CENTER) {
            // When the user center presses, let them pick a contact.
            startActivityForResult(
                    Intent(Intent.ACTION_PICK,Uri.parse("content://contacts")),
                    PICK_CONTACT_REQUEST)
            return true
        }
        return false
    }

    override fun onActivityResult(requestCode: Int, resultCode: Int, intent: Intent?) {
        when (requestCode) {
            PICK_CONTACT_REQUEST ->
                if (resultCode == RESULT_OK) {
                    // A contact was picked. Display it to the user.
                    startActivity(Intent(Intent.ACTION_VIEW, intent?.data))
                }
        }
    }

    companion object {
        internal val PICK_CONTACT_REQUEST = 0
    }
}

public class MyActivity extends Activity {
     // ...

     static final int PICK_CONTACT_REQUEST = 0;

     public boolean onKeyDown(int keyCode, KeyEvent event) {
         if (keyCode == KeyEvent.KEYCODE_DPAD_CENTER) {
             // When the user center presses, let them pick a contact.
             startActivityForResult(
                 new Intent(Intent.ACTION_PICK,
                 new Uri("content://contacts")),
                 PICK_CONTACT_REQUEST);
            return true;
         }
         return false;
     }

     protected void onActivityResult(int requestCode, int resultCode,
             Intent data) {
         if (requestCode == PICK_CONTACT_REQUEST) {
             if (resultCode == RESULT_OK) {
                 // A contact was picked. Display it to the user.
                 startActivity(new Intent(Intent.ACTION_VIEW, data));
             }
         }
     }
 }

Aktivitäten koordinieren

Wenn eine Aktivität eine andere startet, durchlaufen beide einen Lebenszykluswechsel. Die erste Aktivität wird beendet und wechselt in den Status „Pausiert“ oder „Angehalten“, während die andere Aktivität erstellt wird. Falls für diese Aktivitäten Daten verwendet werden, die auf einer Festplatte oder an anderer Stelle gespeichert sind, ist es wichtig zu verstehen, dass die erste Aktivität nicht vollständig beendet wird, bevor die zweite erstellt wird. Vielmehr überschneidet sich der Prozess zum Starten der zweiten mit dem Prozess zum Beenden der ersten.

Die Reihenfolge der Lebenszyklus-Callbacks ist klar definiert, insbesondere wenn sich die beiden Aktivitäten im selben Prozess – also in derselben Anwendung – befinden und die eine die andere startet. Hier ist die Reihenfolge der Vorgänge, die stattfinden, wenn Aktivität A Aktivität B startet:

1. Die Methode onPause() von Aktivität A wird ausgeführt.
2. Die Methoden onCreate(), onStart() und onResume() von Aktivität B werden nacheinander ausgeführt. Aktivität B liegt nun auf der Nutzenden.
3. Wenn Aktivität A nicht mehr auf dem Bildschirm sichtbar ist, wird die zugehörige Methode onStop() ausgeführt.

Mit dieser Abfolge von Lebenszyklus-Callbacks können Sie die Übertragung von Informationen von einer Aktivität zur anderen verwalten.