Die Activity-Klasse ist eine wichtige Komponente einer Android-App. Die Art und Weise, wie Aktivitäten gestartet und zusammengeführt werden, ist ein wesentlicher Bestandteil des Anwendungsmodells der Plattform. Anders als Programmierparadigmen, bei denen Anwendungen mit einer main()-Methode gestartet werden, initiiert das Android-System Code in einer Activity-Instanz durch Aufrufen bestimmter Callback-Methoden, die bestimmten Phasen des Lebenszyklus entsprechen.
In diesem Dokument wird das Konzept von Aktivitäten vorgestellt. Anschließend finden Sie einige einfache Anleitungen zur Arbeit mit diesen Aktivitäten. Weitere Informationen zu Best Practices für die Architektur von Anwendungen finden Sie im Leitfaden zur Anwendungsarchitektur.
Das Konzept der Aktivitäten
Mobile Apps unterscheiden sich von Desktop-Versionen insofern, als die Interaktion eines Nutzers mit der App nicht immer an derselben Stelle beginnt. Stattdessen beginnt die User Journey oft nicht deterministisch. Wenn Sie beispielsweise eine E-Mail-App auf dem Startbildschirm öffnen, wird möglicherweise eine Liste mit E-Mails angezeigt. Wenn Sie dagegen eine Social-Media-App verwenden, über die Ihre E‐Mail-Anwendung gestartet wird, können Sie zum Schreiben einer E‐Mail direkt zum Bildschirm der E‐Mail-Anwendung wechseln.
Die Klasse Activity wurde entwickelt, um dieses Paradigma zu ermöglichen.
Wenn eine Anwendung eine andere aufruft, ruft die aufrufende Anwendung eine Aktivität in der anderen Anwendung auf und nicht die Anwendung als atomares Ganzes. Auf diese Weise dient die Aktivität als Einstiegspunkt für die Interaktion einer App mit dem Nutzer. Sie implementieren eine Aktivität als abgeleitete Klasse der Activity-Klasse.
Eine Aktivität stellt das Fenster bereit, in dem die App ihre UI erstellt. Dieses Fenster füllt in der Regel den Bildschirm aus, ist aber möglicherweise kleiner als der Bildschirm und schwebt über anderen Fenstern. In der Regel wird bei einer Aktivität ein Bildschirm in einer App implementiert. Beispielsweise kann bei einer Aktivität einer App ein Bildschirm Einstellungen implementiert sein, während bei einer anderen Aktivität der Bildschirm Foto auswählen implementiert ist.
Die meisten Apps haben mehrere Bildschirme und somit mehrere Aktivitäten. In der Regel wird eine Aktivität in einer App als Hauptaktivität angegeben. Dies ist der erste Bildschirm, der angezeigt wird, wenn der Nutzer die App startet. Jede Aktivität kann dann eine weitere Aktivität starten, um andere Aktionen auszuführen. Beispielsweise kann die Hauptaktivität in einer einfachen E-Mail-Anwendung den Bildschirm mit einem E-Mail-Posteingang bereitstellen. Von dort aus kann die Hauptaktivität andere Aktivitäten starten, die Bildschirme für Aufgaben wie das Schreiben von E-Mails und das Öffnen einzelner E-Mails bereitstellen.
Obwohl Aktivitäten gemeinsam eine zusammenhängende Nutzererfahrung in einer App bilden, ist jede Aktivität nur lose an die anderen Aktivitäten gebunden. Zwischen den Aktivitäten in einer App gibt es normalerweise nur minimale Abhängigkeiten. Tatsächlich starten Aktivitäten häufig Aktivitäten, die zu anderen Apps gehören. Beispielsweise kann eine Browser-App die Teilen-Aktivität einer Social-Media-App starten.
Wenn Sie Aktivitäten in Ihrer App verwenden möchten, müssen Sie Informationen über sie im Manifest der App registrieren und Aktivitätslebenszyklen entsprechend verwalten. Im Rest dieses Dokuments werden diese Themen vorgestellt.
Manifest konfigurieren
Damit Ihre App Aktivitäten verwenden kann, müssen Sie die Aktivitäten und bestimmte ihrer Attribute im Manifest deklarieren.
Aktivitäten deklarieren
Um Ihre Aktivität zu deklarieren, öffnen Sie die Manifestdatei und fügen Sie dem Element <application> ein <activity>-Element hinzu. Beispiele:
<manifest ... >
<application ... >
<activity android:name=".ExampleActivity" />
...
</application ... >
...
</manifest >
Das einzige erforderliche Attribut für dieses Element ist android:name, das den Klassennamen der Aktivität angibt. Sie können auch Attribute hinzufügen, die Aktivitätseigenschaften wie ein Label, ein Symbol oder ein UI-Design definieren. Weitere Informationen zu diesen und anderen Attributen finden Sie in der Referenzdokumentation zu <activity>-Elementen.
Hinweis : Nachdem Sie Ihre Anwendung veröffentlicht haben, sollten Sie die Aktivitätsnamen nicht mehr ändern. Andernfalls könnten Funktionen wie App-Verknüpfungen beeinträchtigt werden. Weitere Informationen dazu, welche Änderungen nach der Veröffentlichung vermieden werden sollten, finden Sie unter Dinge, die sich nicht ändern können.
Intent-Filter deklarieren
Intent-Filter sind eine sehr leistungsstarke Funktion der Android-Plattform. Sie bieten die Möglichkeit, eine Aktivität nicht nur basierend auf einer expliziten, sondern auch auf einer impliziten Anfrage zu starten. Eine explizite Anfrage kann dem System beispielsweise mitteilen, dass die Aktivität „E-Mail senden“ in der Gmail App gestartet werden soll. Im Gegensatz dazu wird das System über eine implizite Anfrage angewiesen, bei jeder Aktivität, die den Job ausführen kann, einen Bildschirm zum Senden von E-Mails zu starten. Wenn Nutzer über die System-UI gefragt werden, welche App zum Ausführen einer Aufgabe verwendet werden soll, ist dies ein Intent-Filter.
Sie können diese Funktion nutzen, indem Sie im Element <activity> das Attribut <intent-filter> deklarieren. Die Definition dieses Elements umfasst ein <action>-Element und optional ein <category>- und/oder <data>-Element. Diese Elemente werden kombiniert, um den Typ des Intents anzugeben, auf den Ihre Aktivität reagieren kann. Das folgende Code-Snippet zeigt beispielsweise, wie Sie dazu eine Aktivität konfigurieren, die Textdaten sendet und Anfragen von anderen Aktivitäten empfängt:
<activity android:name=".ExampleActivity" android:icon="@drawable/app_icon">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="text/plain" />
</intent-filter>
</activity>
In diesem Beispiel gibt das Element <action> an, dass diese Aktivität Daten sendet.
Wenn Sie das <category>-Element als DEFAULT deklarieren, kann die Aktivität Startanfragen erhalten. Das Element <data> gibt den Datentyp an, der mit dieser Aktivität gesendet werden kann. Das folgende Code-Snippet zeigt, wie die oben beschriebene Aktivität aufgerufen wird:
Kotlin
val sendIntent = Intent().apply {
action = Intent.ACTION_SEND
type = "text/plain"
putExtra(Intent.EXTRA_TEXT, textMessage)
}
startActivity(sendIntent)
Java
// Create the text message with a string
Intent sendIntent = new Intent();
sendIntent.setAction(Intent.ACTION_SEND);
sendIntent.setType("text/plain");
sendIntent.putExtra(Intent.EXTRA_TEXT, textMessage);
// Start the activity
startActivity(sendIntent);
Deklarieren von Berechtigungen
Mit dem Tag
<activity> des Manifests lässt sich steuern, welche Apps eine bestimmte Aktivität starten können. Eine übergeordnete Aktivität kann nur dann eine untergeordnete Aktivität starten, wenn beide Aktivitäten im Manifest dieselben Berechtigungen haben. Wenn Sie ein
<uses-permission>-Element für eine übergeordnete Aktivität deklarieren, muss jede untergeordnete Aktivität ein übereinstimmendes Element
<uses-permission> haben.
Wenn Ihre App beispielsweise eine hypothetische App namens SocialApp verwenden möchte, um einen Beitrag in sozialen Medien zu teilen, muss SocialApp selbst die Berechtigung definieren, die eine App, die sie aufruft, haben muss:
<manifest> <activity android:name="...." android:permission=”com.google.socialapp.permission.SHARE_POST” />
Damit Sie SocialApp aufrufen können, muss Ihre App dann der Berechtigung entsprechen, die im Manifest von SocialApp festgelegt ist:
<manifest> <uses-permission android:name="com.google.socialapp.permission.SHARE_POST" /> </manifest>
Weitere Informationen zu Berechtigungen und Sicherheit im Allgemeinen finden Sie unter Sicherheit und Berechtigungen.
Aktivitätslebenszyklus verwalten
Im Laufe ihrer Lebensdauer durchläuft eine Aktivität eine Reihe von Stadien. Sie verwenden eine Reihe von Callbacks, um Übergänge zwischen Status zu verarbeiten. In den folgenden Abschnitten werden diese Callbacks vorgestellt.
onCreate()
Sie müssen diesen Callback implementieren, der ausgelöst wird, wenn das System Ihre Aktivität erstellt. Ihre Implementierung sollte die wesentlichen Komponenten Ihrer Aktivität initialisieren: Ihre Anwendung sollte beispielsweise Ansichten erstellen und Daten hier an Listen binden. Am wichtigsten ist hier, dass Sie hier setContentView() aufrufen müssen, um das Layout für die Benutzeroberfläche der Aktivität zu definieren.
Wenn onCreate() abgeschlossen ist, ist der nächste Callback immer onStart().
onStart()
Wenn onCreate() beendet wird, wechselt die Aktivität in den Status „Gestartet“ und die Aktivität wird für den Nutzer sichtbar.
Dieser Callback enthält die letzten Vorbereitungen der Aktivität, um in den Vordergrund zu kommen und interaktiv zu werden.
onResume()
Das System ruft diesen Callback auf, kurz bevor die Aktivität mit der Interaktion mit dem Nutzer beginnt. An diesem Punkt befindet sich die Aktivität oben im Aktivitätsstapel und erfasst alle Nutzereingaben. Die meisten Hauptfunktionen einer App werden in der Methode onResume() implementiert.
Der onPause()-Callback folgt immer onResume().
onPause()
Das System ruft onPause() auf, wenn die Aktivität den Fokus verliert und in den Status „Pausiert“ wechselt. Dieser Zustand tritt beispielsweise ein, wenn der Nutzer auf die Schaltfläche „Zurück“ oder „Zuletzt verwendet“ tippt. Wenn das System onPause() für deine Aktivität aufruft, bedeutet dies technisch, dass deine Aktivität noch teilweise sichtbar ist. Meist weist das jedoch darauf hin, dass der Nutzer die Aktivität verlässt und die Aktivität bald in den Status „Angehalten“ oder „Fortsetzen“ wechselt.
Bei einer Aktivität im Status „Pausiert“ kann die UI weiterhin aktualisiert werden, wenn der Nutzer eine Aktualisierung erwartet. Beispiele für solche Aktivitäten sind das Abspielen eines Navigationskartenbildschirms oder die Wiedergabe eines Mediaplayers. Auch wenn solche Aktivitäten den Fokus verlieren, erwartet der Nutzer, dass die UI weiterhin aktualisiert wird.
Sie sollten onPause() nicht verwenden, um Anwendungs- oder Nutzerdaten zu speichern, Netzwerkaufrufe durchzuführen oder Datenbanktransaktionen auszuführen.
Informationen zum Speichern von Daten finden Sie unter
Aktivitätsstatus speichern und wiederherstellen.
Sobald onPause() die Ausführung abgeschlossen hat, ist der nächste Callback entweder onStop() oder onResume(), je nachdem, was passiert, nachdem die Aktivität in den Status „Pausiert“ übergegangen ist.
onStop()
Das System ruft onStop() auf, wenn die Aktivität für den Nutzer nicht mehr sichtbar ist.
Dies kann passieren, wenn die Aktivität gelöscht wird, eine neue Aktivität gestartet wird oder eine vorhandene Aktivität in den Status „Fortgesetzt“ übergeht und die beendete Aktivität abdeckt.
In all diesen Fällen ist die beendete Aktivität überhaupt nicht mehr sichtbar.
Der nächste Callback, den das System aufruft, ist entweder onRestart(), wenn die Aktivität zurückkehrt, um mit dem Nutzer zu interagieren, oder onDestroy(), wenn diese Aktivität vollständig beendet wird.
onNeustart()
Das System ruft diesen Callback auf, wenn eine Aktivität im Status „Angehalten“ neu gestartet wird. onRestart() stellt den Status der Aktivität ab dem Zeitpunkt wieder her, an dem sie angehalten wurde.
Auf diesen Callback folgt immer onStart().
onDestroy()
Das System ruft diesen Callback auf, bevor eine Aktivität gelöscht wird.
Dieser Callback ist der letzte Callback, den die Aktivität erhält.
onDestroy() wird normalerweise implementiert, damit alle Ressourcen einer Aktivität freigegeben werden, wenn die Aktivität oder der Prozess, in dem sie enthalten ist, gelöscht wird.
Dieser Abschnitt bietet nur eine Einführung in dieses Thema. Ausführliche Informationen zum Aktivitätslebenszyklus und seine Callbacks finden Sie unter Aktivitätslebenszyklus.