La classe Activity est un composant crucial d'une application Android, et la manière dont les activités sont lancées et organisées est un élément fondamental du modèle d'application de la plate-forme. Contrairement aux paradigmes de programmation dans lesquels les applications sont lancées avec une méthode main(), le système Android lance le code dans une instance Activity en appelant des méthodes de rappel spécifiques qui correspondent à des étapes spécifiques de son cycle de vie.
Ce document présente le concept des activités, puis fournit des conseils simples sur la façon de les utiliser. Pour en savoir plus sur les bonnes pratiques de conception de l'architecture de votre application, consultez le Guide de l'architecture des applications.
Le concept d'activités
L'expérience d'une application mobile diffère de son homologue sur ordinateur, car l'interaction d'un utilisateur avec l'application ne commence pas toujours au même endroit. Au lieu de cela, le parcours utilisateur commence souvent de manière non déterministe. Par exemple, si vous ouvrez une application de messagerie depuis votre écran d'accueil, une liste d'e-mails peut s'afficher. En revanche, si vous utilisez une application de réseaux sociaux qui lance ensuite votre application de messagerie, vous pouvez accéder directement à l'écran de l'application de messagerie pour rédiger un e-mail.
La classe Activity est conçue pour faciliter ce paradigme.
Lorsqu'une application en appelle une autre, l'application appelante appelle une activité dans l'autre application plutôt que dans l'application en tant qu'ensemble atomique. De cette manière, l'activité sert de point d'entrée pour l'interaction d'une application avec l'utilisateur. Vous allez implémenter une activité en tant que sous-classe de la classe Activity.
Une activité fournit la fenêtre dans laquelle l'application dessine son UI. Cette fenêtre remplit généralement l'écran, mais peut être plus petite que l'écran et flotter au-dessus des autres fenêtres. En règle générale, une activité implémente un écran dans une application. Par exemple, l'une des activités d'une application peut implémenter un écran Préférences, tandis qu'une autre activité implémente un écran Sélectionner une photo.
La plupart des applications contiennent plusieurs écrans, ce qui signifie qu'elles comprennent plusieurs activités. En règle générale, une activité dans une application est spécifiée en tant qu'activité principale, qui est le premier écran qui s'affiche lorsque l'utilisateur lance l'application. Chaque activité peut ensuite démarrer une autre activité pour effectuer différentes actions. Par exemple, l'activité principale d'une application de messagerie simple peut fournir l'écran qui affiche une boîte de réception. À partir de là, l'activité principale peut lancer d'autres activités qui fournissent des écrans pour des tâches telles que la rédaction d'e-mails et l'ouverture d'e-mails individuels.
Bien que les activités fonctionnent ensemble pour former une expérience utilisateur cohérente dans une application, chaque activité n'est que faiblement liée aux autres activités. Il existe généralement des dépendances minimales entre les activités d'une application. En fait, les activités démarrent souvent des activités appartenant à d'autres applications. Par exemple, une application de navigateur peut lancer l'activité de partage d'une application de réseaux sociaux.
Pour utiliser des activités dans votre application, vous devez enregistrer les informations les concernant dans le fichier manifeste de l'application et gérer les cycles de vie des activités de manière appropriée. Le reste de ce document présente ces sujets.
Configurer le fichier manifeste
Pour que votre application puisse utiliser des activités, vous devez les déclarer, ainsi que certains de leurs attributs, dans le fichier manifeste.
Déclarer des activités
Pour déclarer votre activité, ouvrez votre fichier manifeste et ajoutez un élément <activity> en tant qu'enfant de l'élément <application>. Par exemple :
<manifest ... >
<application ... >
<activity android:name=".ExampleActivity" />
...
</application ... >
...
</manifest >
Le seul attribut obligatoire pour cet élément est android:name, qui spécifie le nom de classe de l'activité. Vous pouvez également ajouter des attributs qui définissent les caractéristiques d'une activité telles qu'un libellé, une icône ou un thème d'interface utilisateur. Pour en savoir plus sur ces attributs et sur d'autres, consultez la documentation de référence de l'élément <activity>.
Remarque : Une fois votre application publiée, vous ne devez plus modifier les noms des activités. Vous risqueriez de bloquer certaines fonctionnalités, comme les raccourcis d'applications. Pour en savoir plus sur les modifications à éviter après la publication, consultez la section Éléments qui ne peuvent pas changer.
Déclarer des filtres d'intent
Les filtres d'intent sont une fonctionnalité très puissante de la plate-forme Android. Ils permettent de lancer une activité basée non seulement sur une requête explicite, mais aussi implicite. Par exemple, une requête explicite peut indiquer au système de "lancer l'activité d'envoi d'e-mails dans l'application Gmail". En revanche, une requête implicite indique au système de "lancer un écran d'envoi d'e-mails dans toute activité pouvant effectuer la tâche". Lorsque l'UI du système demande à un utilisateur quelle application utiliser pour effectuer une tâche, il s'agit d'un filtre d'intent en action.
Vous pouvez profiter de cette fonctionnalité en déclarant un attribut <intent-filter> dans l'élément <activity>. La définition de cet élément inclut un élément <action> et, éventuellement, un élément <category> et/ou un élément <data>. Ces éléments se combinent pour spécifier le type d'intent auquel votre activité peut répondre. Par exemple, l'extrait de code suivant montre comment configurer une activité qui envoie des données textuelles et reçoit des requêtes provenant d'autres activités:
<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>
Dans cet exemple, l'élément <action> indique que cette activité envoie des données.
Déclarer l'élément <category> comme DEFAULT permet à l'activité de recevoir des demandes de lancement. L'élément <data> spécifie le type de données que cette activité peut envoyer. L'extrait de code suivant montre comment appeler l'activité décrite ci-dessus:
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);
Déclarer des autorisations
Vous pouvez utiliser la balise
<activity> du fichier manifeste pour contrôler les applications qui peuvent démarrer une activité particulière. Une activité parente ne peut pas lancer une activité enfant, sauf si les deux activités ont les mêmes autorisations dans leur fichier manifeste. Si vous déclarez un élément
<uses-permission> pour une activité parente, chaque activité enfant doit avoir un élément
<uses-permission> correspondant.
Par exemple, si votre application souhaite utiliser une application hypothétique appelée SocialApp pour partager une publication sur un réseau social, SocialApp elle-même doit définir l'autorisation qu'une application qui l'appelle doit avoir:
<manifest> <activity android:name="...." android:permission=”com.google.socialapp.permission.SHARE_POST” />
Ensuite, pour pouvoir appeler SocialApp, votre application doit correspondre à l'autorisation définie dans le fichier manifeste de SocialApp:
<manifest> <uses-permission android:name="com.google.socialapp.permission.SHARE_POST" /> </manifest>
Pour plus d'informations sur les autorisations et la sécurité en général, consultez la section Sécurité et autorisations.
Gérer le cycle de vie d'une activité
Au cours de sa durée de vie, une activité passe par plusieurs états. Vous allez utiliser une série de rappels pour gérer les transitions entre les états. Les sections suivantes présentent ces rappels.
onCreate()
Vous devez implémenter ce rappel, qui se déclenche lorsque le système crée votre activité. Votre implémentation doit initialiser les composants essentiels de votre activité. Par exemple, votre application doit créer des vues et lier des données à des listes ici. Plus important encore, c'est là que vous devez appeler setContentView() pour définir la mise en page de l'interface utilisateur de l'activité.
Lorsque onCreate() se termine, le rappel suivant est toujours onStart().
onStart()
Lorsque onCreate() se ferme, l'activité passe à l'état "Démarrée" et l'activité devient visible par l'utilisateur.
Ce rappel contient ce qui correspond aux préparations finales de l'activité pour passer au premier plan et devenir interactives.
onResume()
Le système invoque ce rappel juste avant que l'activité ne commence à interagir avec l'utilisateur. À ce stade, l'activité se trouve en haut de la pile d'activités et capture toutes les entrées utilisateur. La plupart des fonctionnalités de base d'une application sont implémentées dans la méthode onResume().
Le rappel onPause() suit toujours onResume().
onPause()
Le système appelle onPause() lorsque l'activité n'est plus active et passe à l'état "Mise en pause". Cet état se produit, par exemple, lorsque l'utilisateur appuie sur le bouton "Retour" ou "Récents". Lorsque le système appelle onPause() pour votre activité, cela signifie techniquement que votre activité est encore partiellement visible. Toutefois, le plus souvent, cela indique que l'utilisateur quitte l'activité et que celle-ci passe bientôt à l'état "Arrêtée" ou "Reprise".
Une activité mise en pause peut continuer à mettre à jour l'interface utilisateur si l'utilisateur s'attend à ce que celle-ci soit mise à jour. Il peut s'agir, par exemple, d'une activité affichant un écran de carte de navigation ou d'un lecteur multimédia en cours de lecture. Même si ces activités ne sont plus ciblées, l'utilisateur s'attend à ce que son UI continue de se mettre à jour.
Vous ne devez pas utiliser onPause() pour enregistrer des données d'application ou d'utilisateur, effectuer des appels réseau ou exécuter des transactions de base de données.
Pour en savoir plus sur l'enregistrement des données, consultez la section
Enregistrer et restaurer l'état d'une activité.
Une fois l'exécution de onPause() terminée, le rappel suivant est onStop() ou onResume(), en fonction de ce qui se passe une fois que l'activité passe à l'état "Mise en pause".
onStop()
Le système appelle onStop() lorsque l'activité n'est plus visible par l'utilisateur.
Cela peut se produire lorsque l'activité est détruite, qu'une nouvelle activité démarre ou qu'une activité existante est réactivée et couvre l'activité arrêtée.
Dans tous ces cas, l'activité arrêtée n'est plus visible.
Le prochain rappel appelé par le système est onRestart() si l'activité revient pour interagir avec l'utilisateur, ou onDestroy() si cette activité s'arrête complètement.
onRestart()
Le système invoque ce rappel lorsqu'une activité à l'état "Arrêtée" est sur le point de redémarrer. onRestart() restaure l'état de l'activité à partir du moment où elle a été arrêtée.
Ce rappel est toujours suivi de onStart().
onDestroy()
Le système invoque ce rappel avant la destruction d'une activité.
Ce rappel est le dernier que l'activité reçoit.
onDestroy() est généralement implémenté pour garantir que toutes les ressources d'une activité sont libérées lorsque l'activité, ou le processus qui la contient, est détruit.
Cette section constitue uniquement une introduction à ce sujet. Pour un traitement plus détaillé du cycle de vie d'une activité et de ses rappels, consultez la section Cycle de vie d'une activité.