Cycle de vie d'une activité

Lorsqu'un utilisateur parcourt votre application, la quitte et y revient, les instances Activity de votre application passent par différents états de leur cycle de vie. La classe Activity fournit un certain nombre de rappels qui permettent à l'activité de savoir quand un état change, ou que le système crée, arrête ou reprend une activité, ou détruit le processus dans lequel l'activité réside.

Dans les méthodes de rappel de cycle de vie, vous pouvez déclarer le comportement de votre activité lorsque l'utilisateur la quitte et y revient. Par exemple, si vous créez un lecteur vidéo en streaming, vous pouvez mettre la vidéo en pause et mettre fin à la connexion réseau lorsque l'utilisateur passe à une autre application. Lorsqu'il revient, vous pouvez vous reconnecter au réseau et lui permettre de reprendre la vidéo au même endroit.

Chaque rappel vous permet d'effectuer un travail spécifique adapté à un changement d'état donné. Effectuer les bonnes tâches au bon moment et gérer correctement les transitions rend votre application plus robuste et plus performante. Par exemple, une bonne implémentation des rappels de cycle de vie peut aider votre application à éviter les problèmes suivants :

• Plantage si l'utilisateur reçoit un appel téléphonique ou passe à une autre application pendant qu'il utilise votre application.
• Consommer des ressources système précieuses lorsque l'utilisateur ne l'utilise pas activement.
• Perte de la progression de l'utilisateur s'il quitte votre application et y revient plus tard.
• Plantage ou perte de la progression de l'utilisateur lorsque l'écran passe du mode paysage au mode portrait.

Ce document explique en détail le cycle de vie d'une activité. Le document commence par décrire le paradigme du cycle de vie. Ensuite, il explique chacun des rappels : ce qui se passe en interne pendant leur exécution et ce que vous devez implémenter pendant leur exécution.

Il présente ensuite brièvement la relation entre l'état de l'activité et la vulnérabilité d'un processus à être arrêté par le système. Enfin, il aborde plusieurs sujets liés aux transitions entre les états d'activité.

Pour en savoir plus sur la gestion des cycles de vie, y compris sur les bonnes pratiques, consultez Cycle de vie dans Jetpack Compose et Enregistrer les états de l'interface utilisateur. Pour savoir comment concevoir une application robuste et de qualité en utilisant des activités en combinaison avec des composants d'architecture, consultez le Guide de l'architecture d'applications.

Concepts du cycle de vie d'une activité

Pour naviguer entre les étapes du cycle de vie d'une activité, la classe Activity fournit un ensemble de six rappels principaux : onCreate, onStart, onResume, onPause, onStop et onDestroy. Le système appelle chacun de ces rappels lorsque l'activité passe à un nouvel état.

La figure 1 présente une représentation visuelle de ce paradigme.

Figure 1. Illustration simplifiée du cycle de vie d'une activité.

Lorsque l'utilisateur commence à quitter l'activité, le système appelle des méthodes pour la démanteler. Dans certains cas, l'activité n'est que partiellement démantelée et réside toujours en mémoire, par exemple lorsque l'utilisateur passe à une autre application. Dans ce cas, l'activité peut toujours revenir au premier plan.

Si l'utilisateur revient à l'activité, elle reprend là où il l'avait laissée. À quelques exceptions près, les applications ne sont pas autorisées à démarrer des activités lorsqu'elles s'exécutent en arrière-plan.

La probabilité que le système arrête un processus donné, ainsi que les activités qu'il contient, dépend de l'état de l'activité à ce moment-là. Pour en savoir plus sur la relation entre l'état et la vulnérabilité à l'éjection, consultez la section sur l'état de l'activité et l'éjection de la mémoire.

Selon la complexité de votre activité, vous n'aurez probablement pas besoin d'implémenter toutes les méthodes de cycle de vie. Toutefois, il est important que vous les compreniez toutes et que vous implémentiez celles qui permettent à votre application de se comporter comme les utilisateurs l'attendent.

Compose et le cycle de vie

Dans Compose, évitez de placer la logique métier ou la configuration manuelle de l'observateur directement dans les rappels d'activité tels que onStart ou onResume. Utilisez plutôt des effets tenant compte du cycle de vie et des observateurs tenant compte de l'état qui s'alignent automatiquement sur la présence de l'UI à l'écran.

• Collecte tenant compte du cycle de vie : utilisez collectAsStateWithLifecycle pour consommer les flux de votre ViewModel. Cette API commence automatiquement la collecte lorsque l'UI passe à l'état "Started" et s'arrête lorsqu'elle passe en arrière-plan, ce qui évite une consommation inutile de ressources. Après avoir collecté le flux en tant qu'état, vous pouvez utiliser LifecycleEffects pour exécuter du code lorsqu'un événement de cycle de vie se produit.
• Flux logique : en utilisant ces API, l'UI réagit naturellement à l'état du cycle de vie via l'arborescence de composition, ce qui garantit que la logique métier ne s'exécute que lorsque l'utilisateur interagit activement avec le composant.

Pour en savoir plus sur Compose et le cycle de vie, consultez Cycle de vie dans Jetpack Compose.

Rappels de cycle de vie

Cette section fournit des informations conceptuelles et d'implémentation sur les méthodes de rappel utilisées pendant le cycle de vie d'une activité.

Certaines actions appartiennent aux méthodes du cycle de vie de l'activité. Toutefois, placez le code qui implémente les actions d'un composant dépendant dans le composant, plutôt que dans la méthode de cycle de vie de l'activité. Pour ce faire, vous devez rendre le composant dépendant sensible au cycle de vie. Pour savoir comment rendre vos composants dépendants compatibles avec le cycle de vie, consultez Cycle de vie dans Jetpack Compose.

onCreate

Vous devez implémenter ce rappel, qui se déclenche lorsque le système crée l'activité pour la première fois. Lors de sa création, l'activité passe à l'état Créée. Dans la méthode onCreate, exécutez la logique de démarrage de base de l'application, qui ne se produit qu'une seule fois pendant toute la durée de vie de l'activité.

Par exemple, votre implémentation de onCreate peut lier des données à des listes, associer l'activité à un ViewModel et instancier certaines variables de champ d'application de classe. Cette méthode reçoit le paramètre savedInstanceState, qui est un objet Bundle contenant l'état précédemment enregistré de l'activité. Si l'activité n'a jamais existé auparavant, la valeur de l'objet Bundle est nulle.

Si vous disposez d'un composant tenant compte du cycle de vie qui est associé au cycle de vie de votre activité, il reçoit l'événement ON_CREATE. La méthode annotée avec @OnLifecycleEvent est appelée pour que votre composant tenant compte du cycle de vie puisse exécuter le code de configuration dont il a besoin pour l'état créé.

L'exemple suivant montre comment intégrer un composable Text dans une activité minimale :

class ExampleActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent { // In here, we can call composables!
            MaterialTheme {
                Greeting(name = "compose")
            }
        }
    }
}

@Composable
fun Greeting(name: String) {
    Text(text = "Hello $name!")
}
InteroperabilityAPIsSnippets.kt

Votre activité ne reste pas à l'état "Créée". Une fois l'exécution de la méthode onCreate terminée, l'activité passe à l'état Démarré, et le système appelle les méthodes onStart et onResume en succession rapide.

onStart

Lorsque l'activité passe à l'état "Démarré", le système appelle onStart. Cet appel rend l'activité visible par l'utilisateur, car l'application prépare l'activité à passer au premier plan et à devenir interactive. Par exemple, cette méthode permet d'initialiser le code qui gère l'interface utilisateur.

Lorsque l'activité passe à l'état "Démarrée", tout composant tenant compte du cycle de vie associé au cycle de vie de l'activité reçoit l'événement ON_START.

La méthode onStart se termine rapidement et, comme pour l'état "Created", l'activité ne reste pas à l'état "Started". Une fois ce rappel terminé, l'activité passe à l'état Reprise et le système appelle la méthode onResume.

onResume

Lorsque l'activité passe à l'état "Reprise", elle passe au premier plan et le système appelle le rappel onResume. Il s'agit de l'état dans lequel l'application interagit avec l'utilisateur. L'application reste dans cet état jusqu'à ce qu'un événement détourne l'attention de l'application, par exemple lorsque l'appareil reçoit un appel téléphonique, que l'utilisateur accède à une autre activité ou que l'écran de l'appareil s'éteint.

Lorsque l'activité passe à l'état "Reprise", tout composant tenant compte du cycle de vie associé au cycle de vie de l'activité reçoit l'événement ON_RESUME. C'est là que les composants du cycle de vie peuvent activer toutes les fonctionnalités qui doivent s'exécuter lorsque le composant est visible et au premier plan, comme le démarrage d'un aperçu de l'appareil photo.

Lorsqu'un événement d'interruption se produit, l'activité passe à l'état Paused (En pause) et le système appelle le rappel onPause.

Si l'activité passe de l'état "En pause" à l'état "Reprise", le système appelle à nouveau la méthode onResume. Pour cette raison, implémentez onResume pour initialiser les composants que vous publiez pendant onPause et pour effectuer toutes les autres initialisations qui doivent se produire chaque fois que l'activité passe à l'état "Reprise".

Voici un exemple de composant sensible au cycle de vie qui accède à l'appareil photo lorsque le composant reçoit l'événement ON_RESUME :

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

Le code précédent initialise la caméra une fois que LifecycleObserver reçoit l'événement ON_RESUME. En mode multifenêtre, toutefois, votre activité peut être entièrement visible même lorsqu'elle est en pause. Par exemple, lorsque l'application est en mode multifenêtre et que l'utilisateur appuie sur la fenêtre qui ne contient pas votre activité, celle-ci passe à l'état "En pause".

Si vous souhaitez que la caméra ne soit active que lorsque l'application est reprise (visible et active au premier plan), initialisez-la après l'événement ON_RESUME présenté précédemment. Si vous souhaitez que l'appareil photo reste actif lorsque l'activité est suspendue, mais visible, par exemple en mode multifenêtre, initialisez l'appareil photo après l'événement ON_START.

Toutefois, si l'appareil photo est actif alors que votre activité est en pause, une autre application reprise en mode multifenêtre risque de ne pas pouvoir y accéder. Il est parfois nécessaire de laisser la caméra active lorsque votre activité est suspendue, mais cela peut dégrader l'expérience utilisateur globale.

C'est pourquoi vous devez réfléchir attentivement à l'endroit du cycle de vie où il est le plus approprié de prendre le contrôle des ressources système partagées dans le contexte du mode multifenêtre. Pour en savoir plus sur la prise en charge du mode multifenêtre, consultez Prise en charge du mode multifenêtre.

Quel que soit l'événement de création que vous choisissez pour effectuer une opération d'initialisation, veillez à utiliser l'événement de cycle de vie correspondant pour libérer la ressource. Si vous initialisez un élément après l'événement ON_START, libérez-le ou arrêtez-le après l'événement ON_STOP. Si vous initialisez après l'événement ON_RESUME, libérez après l'événement ON_PAUSE.

L'extrait de code précédent place le code d'initialisation de l'appareil photo dans un composant sensible au cycle de vie. Vous pouvez également placer ce code directement dans les rappels de cycle de vie de l'activité, tels que onStart et onStop, mais nous ne le recommandons pas. L'ajout de cette logique à un composant indépendant et tenant compte du cycle de vie vous permet de réutiliser le composant dans plusieurs activités sans avoir à dupliquer le code. Pour savoir comment créer un composant sensible au cycle de vie, consultez Cycle de vie dans Jetpack Compose.

onPause

Le système appelle cette méthode pour indiquer que l'utilisateur quitte votre activité, même si cela ne signifie pas toujours que l'activité est détruite. Il indique que l'activité n'est plus au premier plan, mais qu'elle est toujours visible si l'utilisateur est en mode multifenêtre. Une activité peut passer à cet état pour plusieurs raisons :

• Un événement qui interrompt l'exécution de l'application, comme décrit dans la section sur le rappel onResume, met en pause l'activité en cours. Il s'agit du cas le plus courant.
• En mode multifenêtre, une seule application est active à la fois, et le système met en pause toutes les autres.
• L'ouverture d'une nouvelle activité semi-transparente, telle qu'une boîte de dialogue, met en pause l'activité qu'elle couvre. Tant que l'activité est partiellement visible, mais qu'elle n'est pas sélectionnée, elle reste en pause.

Lorsqu'une activité passe à l'état "En pause", tout composant tenant compte du cycle de vie associé au cycle de vie de l'activité reçoit l'événement ON_PAUSE. C'est là que les composants de cycle de vie peuvent arrêter toute fonctionnalité qui n'a pas besoin de s'exécuter lorsque le composant n'est pas au premier plan, comme l'arrêt d'un aperçu de l'appareil photo.

Utilisez la méthode onPause pour suspendre ou ajuster les opérations qui ne peuvent pas continuer, ou qui peuvent continuer avec modération, lorsque l'Activity est à l'état "Suspendu" et que vous prévoyez de reprendre rapidement.

Vous pouvez également utiliser la méthode onPause pour libérer des ressources système, des poignées de capteurs (comme le GPS) ou toute ressource ayant un impact sur l'autonomie de la batterie lorsque votre activité est suspendue et que l'utilisateur n'en a pas besoin.

Toutefois, comme indiqué dans la section sur onResume, une activité mise en pause peut rester entièrement visible si l'application est en mode multifenêtre. Envisagez d'utiliser onStop au lieu de onPause pour libérer ou ajuster entièrement les ressources et les opérations liées à l'interface utilisateur afin de mieux prendre en charge le mode multifenêtre.

L'exemple suivant d'un LifecycleObserver réagissant à l'événement ON_PAUSE est l'équivalent de l'exemple d'événement ON_RESUME précédent, qui libère l'appareil photo qui s'initialise après la réception de l'événement ON_RESUME :

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

Cet exemple place le code de libération de la caméra après la réception de l'événement ON_PAUSE par LifecycleObserver.

L'exécution de onPause est très brève et ne laisse pas nécessairement assez de temps pour effectuer des opérations d'enregistrement. C'est pourquoi vous ne devez pas utiliser onPause pour enregistrer des données d'application ou d'utilisateur, passer des appels réseau ou exécuter des transactions de base de données. Il est possible que ces opérations ne soient pas terminées avant la fin de la méthode.

Effectuez plutôt les opérations d'arrêt à charge élevée pendant onStop. Pour en savoir plus sur les opérations appropriées à effectuer pendant onStop, consultez la section suivante. Pour en savoir plus sur l'enregistrement des données, consultez la section sur l'enregistrement et la restauration de l'état.

L'exécution de la méthode onPause ne signifie pas que l'activité quitte l'état "En pause". L'activité reste dans cet état jusqu'à ce qu'elle reprenne ou qu'elle devienne complètement invisible pour l'utilisateur. Si l'activité reprend, le système appelle à nouveau le rappel onResume.

Si l'activité passe de l'état "En pause" à l'état "Reprise", le système conserve l'instance Activity en mémoire et la rappelle lorsqu'il appelle onResume. Dans ce scénario, vous n'avez pas besoin de réinitialiser les composants créés lors des méthodes de rappel menant à l'état "Reprise". Si l'activité devient complètement invisible, le système appelle onStop.

onStop

Lorsque votre activité n'est plus visible par l'utilisateur, elle passe à l'état Arrêté et le système appelle le rappel onStop. Cela peut se produire lorsqu'une activité nouvellement lancée couvre l'intégralité de l'écran. Le système appelle également onStop lorsque l'activité se termine et qu'elle est sur le point d'être arrêtée.

Lorsque l'activité passe à l'état "Arrêté", tout composant tenant compte du cycle de vie lié au cycle de vie de l'activité reçoit l'événement ON_STOP. C'est là que les composants du cycle de vie peuvent arrêter toute fonctionnalité qui n'a pas besoin de s'exécuter lorsque le composant n'est pas visible à l'écran.

Dans la méthode onStop, libérez ou ajustez les ressources qui ne sont pas nécessaires lorsque l'application n'est pas visible par l'utilisateur. Par exemple, votre application peut suspendre les animations ou passer de mises à jour de position précises à des mises à jour de position approximatives. L'utilisation de onStop au lieu de onPause signifie que le travail lié à l'UI se poursuit, même lorsque l'utilisateur consulte votre activité en mode multifenêtre.

Utilisez également onStop pour effectuer des opérations d'arrêt qui sollicitent relativement beaucoup le processeur. Par exemple, si vous ne trouvez pas de meilleur moment pour enregistrer des informations dans une base de données, vous pouvez le faire pendant onStop. L'exemple suivant montre une implémentation de onStop qui enregistre le contenu d'un brouillon de note dans un espace de stockage persistant :

override fun onStop() {
    super.onStop()

    // Delegate the save operation to the ViewModel, which handles the
    // background thread operations (e.g., using Kotlin Coroutines and Room).
    noteViewModel.saveDraft()
}

Lorsque votre activité passe à l'état "Arrêtée", l'objet Activity est conservé en mémoire : il conserve toutes les informations d'état et de membre, mais n'est pas associé au gestionnaire de fenêtres. Lorsque l'activité reprend, elle rappelle ces informations.

À partir de l'état "Arrêtée", l'activité revient pour interagir avec l'utilisateur, ou elle se termine et disparaît. Si l'activité revient, le système appelle onRestart. Si l'exécution de Activity est terminée, le système appelle onDestroy.

onDestroy

onDestroy est appelé avant la destruction de l'activité. Le système appelle ce rappel pour l'une des deux raisons suivantes :

1. L'activité se termine, car l'utilisateur l'a complètement ignorée ou parce que finish a été appelé sur l'activité.
2. Le système détruit temporairement l'activité en raison d'une modification de la configuration, par exemple une rotation de l'appareil ou l'activation du mode multifenêtre.

Lorsque l'activité passe à l'état "Détruite", tout composant tenant compte du cycle de vie associé au cycle de vie de l'activité reçoit l'événement ON_DESTROY. C'est là que les composants du cycle de vie peuvent nettoyer tout ce dont ils ont besoin avant la destruction de Activity.

Au lieu d'ajouter une logique dans votre Activity pour déterminer pourquoi elle est détruite, utilisez un objet ViewModel pour contenir les données de vue pertinentes pour votre Activity. Si l'Activity est recréé en raison d'une modification de la configuration, l'ViewModel n'a rien à faire, car il est conservé et transmis à l'instance Activity suivante.

Si l'Activity n'est pas recréé, la méthode onCleared est appelée sur l'ViewModel, ce qui lui permet de nettoyer toutes les données nécessaires avant d'être détruit. Vous pouvez distinguer ces deux scénarios à l'aide de la méthode isFinishing.

Si l'activité se termine, onDestroy est le dernier rappel de cycle de vie qu'elle reçoit. Si onDestroy est appelé à la suite d'un changement de configuration, le système crée immédiatement une instance d'activité, puis appelle onCreate sur cette instance dans la nouvelle configuration.

Le rappel onDestroy libère toutes les ressources qui n'ont pas été libérées par les rappels précédents, comme onStop.

État de l'activité et éjection de la mémoire

Le système arrête les processus lorsqu'il doit libérer de la RAM. La probabilité que le système arrête un processus donné dépend de l'état du processus à ce moment-là. L'état du processus dépend à son tour de l'état de l'activité en cours d'exécution dans le processus. Le tableau 1 présente les corrélations entre l'état du processus, l'état de l'activité et la probabilité que le système arrête le processus. Ce tableau ne s'applique que si un processus n'exécute pas d'autres types de composants d'application.

Probabilité d'être tué	État du processus	État d'activité final
La plus faible	Premier plan (ayant ou sur le point d'avoir le focus)	A repris
Faible	Visible (non sélectionné)	Démarré/Mis en pause
Plus élevé	Arrière-plan (invisible)	Stopped
La plus élevée	Vide	Détruite

Tableau 1. Relation entre le cycle de vie du processus et l'état de l'activité

Le système ne supprime jamais directement une activité pour libérer de la mémoire. Au lieu de cela, il arrête le processus dans lequel l'activité s'exécute, détruisant non seulement l'activité, mais aussi tout ce qui s'exécute dans le processus. Pour savoir comment préserver et restaurer l'état de l'UI de votre activité en cas d'arrêt du processus initié par le système, consultez la section Enregistrer et restaurer l'état.

L'utilisateur peut également arrêter un processus en utilisant le gestionnaire d'applications, sous "Paramètres", pour arrêter l'application correspondante.

Pour en savoir plus sur les processus, consultez Présentation des processus et des threads.

Enregistrer et restaurer l'état transitoire de l'UI

Un utilisateur s'attend à ce que l'état de l'interface utilisateur d'une activité reste le même en cas de modification de la configuration, par exemple en cas de rotation ou d'un passage en mode multifenêtre. Toutefois, le système détruit par défaut l'activité lorsqu'une telle modification de configuration se produit, effaçant tout état d'interface utilisateur stocké dans l'instance d'activité.

De même, l'utilisateur s'attend à ce que l'état de l'UI reste le même s'il passe temporairement à une autre application, puis revient plus tard à la vôtre. Cependant, le système peut détruire le processus de votre application lorsque l'utilisateur n'est pas là et que votre activité est arrêtée.

Lorsque les contraintes du système détruisent l'activité, conservez l'état d'UI temporaire de l'utilisateur en combinant ViewModel (pour la logique métier complexe et l'état de l'écran), l'API Jetpack Compose rememberSaveable (pour l'état d'UI léger) et/ou l'espace de stockage local. Pour en savoir plus sur les attentes des utilisateurs par rapport au comportement du système et sur la meilleure façon de conserver les données d'état d'UI complexes lors de l'arrêt d'un processus et d'une activité initié par le système, consultez Enregistrer les états de l'UI.

rememberSaveable survit automatiquement aux modifications de configuration et à l'arrêt du processus initié par le système en regroupant l'état en arrière-plan. Cela offre une expérience fluide sans nécessiter de code récurrent au niveau de l'activité.

Remarque : Pour en savoir plus sur les modifications de configuration ou pour découvrir comment limiter la recréation d'activité si nécessaire et comment réagir à ces modifications de configuration dans Jetpack Compose, consultez la page Gérer les modifications de configuration.

État de l'instance

Dans certains cas, votre activité est détruite en raison d'un comportement normal de l'application, par exemple lorsque l'utilisateur appuie sur le bouton Retour ou que votre activité signale sa propre destruction en appelant la méthode finish.

Lorsque votre activité est détruite parce que l'utilisateur appuie sur "Retour" ou que l'activité se termine d'elle-même, le concept de cette instance Activity du système et de l'utilisateur disparaît définitivement. Dans ces scénarios, les attentes de l'utilisateur correspondent au comportement du système, et vous n'avez aucune tâche supplémentaire à effectuer.

Toutefois, si le système détruit l'activité en raison de contraintes système (telles qu'une modification de la configuration ou une sollicitation de la mémoire), l'instance Activity réelle disparaît, mais le système se souvient qu'elle existait. Si l'utilisateur tente de revenir à l'activité, le système crée une instance de cette activité à l'aide d'un ensemble de données enregistrées qui décrivent l'état de l'activité au moment de sa destruction.

Les données enregistrées que le système utilise pour restaurer l'état précédent sont appelées état d'instance. En arrière-plan, il s'agit d'une collection de paires clé-valeur. Par défaut, le système utilise l'état de l'instance pour enregistrer des informations de base sur la mise en page de votre UI, telles que la saisie de texte par l'utilisateur ou les positions de défilement.

Vous pouvez vous connecter à ce comportement du système à l'aide de rememberSaveable. Si votre instance d'activité est détruite et recréée, tout état d'UI encapsulé dans rememberSaveable est automatiquement restauré, sans qu'aucun code supplémentaire au niveau de l'activité ne soit requis de votre part.

Toutefois, votre activité contiendra probablement des informations d'état plus complexes que vous souhaiterez restaurer, telles que des données utilisateur, des réponses réseau ou des variables de membre qui suivent la progression de l'utilisateur. Le mécanisme d'état d'instance (et, par extension, rememberSaveable) n'est pas adapté pour conserver plus qu'une quantité minime de données, car il nécessite une sérialisation sur le thread principal et consomme de la mémoire du processus système.

Pour conserver plus qu'une très petite quantité de données, adoptez une approche combinée utilisant le stockage local persistant, la classe ViewModel et le hissage d'état Compose, comme indiqué dans Enregistrer les états de l'interface utilisateur.

Enregistrer un état d'UI simple et léger à l'aide de rememberSaveable

Lorsque votre activité commence à s'arrêter, le système se prépare à enregistrer les informations d'état dans un bundle d'états d'instances. Pour vous connecter à ce comportement du système, utilisez rememberSaveable directement dans vos fonctions composables. rememberSaveable enregistre et restaure automatiquement l'état temporaire de l'UI, comme la saisie de texte par l'utilisateur ou les positions de défilement, lors de la recréation de l'activité.

Pour enregistrer des informations d'état personnalisées et légères (comme la progression d'un utilisateur dans un jeu), déclarez votre état à l'aide de rememberSaveable. Le framework Compose gère la sérialisation dans le bundle d'état de l'instance en arrière-plan :

var userTypedQuery by rememberSaveable(typedQuery, stateSaver = TextFieldValue.Saver) {
    mutableStateOf(
        TextFieldValue(text = typedQuery, selection = TextRange(typedQuery.length))
    )
}
StateOverviewSnippets.kt

Remarque : Le mécanisme d'état d'instance du système (et donc rememberSaveable) n'est pas déclenché lorsque l'utilisateur ferme explicitement l'activité ou dans d'autres cas lorsque finish est appelé.

Pour enregistrer des données persistantes, telles que les préférences de l'utilisateur ou les données d'une base de données, profitez des opportunités appropriées lorsque votre activité est au premier plan. Si aucune opportunité de ce type ne se présente, enregistrez les données persistantes pendant la méthode onStop.

Restaurer l'état de l'UI d'une activité à l'aide de l'état d'instance enregistré

Lorsque votre activité est recréée après avoir été détruite, la restauration de l'état est automatique. Lorsque vous utilisez rememberSaveable, vous n'avez pas besoin d'écrire de logique de restauration explicite, de vérifier les bundles nuls ni de remplacer les rappels d'activité. Le code qui initialise et enregistre votre état le restaure également de manière fluide lorsque l'activité reprend :

var userTypedQuery by rememberSaveable(typedQuery, stateSaver = TextFieldValue.Saver) {
    mutableStateOf(
        TextFieldValue(text = typedQuery, selection = TextRange(typedQuery.length))
    )
}
StateOverviewSnippets.kt

Activités et navigation

Une application est susceptible de passer d'un écran à un autre de nombreuses fois au cours de sa durée de vie, par exemple lorsque l'utilisateur appuie sur le bouton Retour de l'appareil ou sélectionne une nouvelle destination. Les applications Android modernes utilisent généralement une architecture à activité unique. Au lieu de démarrer une nouvelle Activity pour chaque écran, votre application héberge une seule Activity et utilise le composant Navigation pour échanger des écrans composables dans cette activité.

Pour savoir comment implémenter une navigation moderne axée sur Compose, consultez le guide de la bibliothèque Navigation 3 de Jetpack Compose.

Démarrer une activité à partir d'une autre

Une activité peut avoir besoin de démarrer une autre activité à un moment donné. Ce besoin se présente, par exemple, lorsqu'une application doit passer de l'écran actuel à un nouvel écran.

Selon que votre activité souhaite ou non obtenir un résultat de la nouvelle activité qu'elle est sur le point de démarrer, vous démarrez la nouvelle activité à l'aide de la méthode startActivity ou startActivityForResult. Dans les deux cas, vous transmettez un objet Intent.

L'objet Intent spécifie l'activité exacte que vous souhaitez démarrer ou décrit le type d'action que vous souhaitez effectuer. Le système sélectionne l'activité appropriée, qui peut même provenir d'une autre application. Un objet Intent peut également transporter de petites quantités de données à utiliser par l'activité lancée. Pour en savoir plus sur la classe Intent, consultez Intents et filtres d'intent.

Remarque : Dans Compose, nous vous recommandons d'utiliser une architecture à activité unique dans l'ensemble de votre application. Si ce n'est pas possible, vous devrez peut-être démarrer une activité à partir d'une autre.

startActivity

Si l'activité nouvellement démarrée n'a pas besoin de renvoyer un résultat, l'activité actuelle peut la démarrer en appelant la méthode startActivity.

Lorsque vous travaillez dans votre propre application, vous devez souvent lancer une activité connue. Par exemple, l'extrait de code suivant montre comment lancer une activité appelée SignInActivity.

val context = LocalContext.current

Button(onClick = {
    val intent = Intent(context, SignInActivity::class.java)
    context.startActivity(intent)
}) {
    Text("Sign In")
}

Démarrer des activités externes

Bien que la navigation interne de l'application soit gérée par Navigation, votre Activity devra parfois démarrer d'autres activités. Cela se produit généralement lorsque vous souhaitez exploiter une application externe pour effectuer une action spécifique, comme ouvrir un navigateur Web, envoyer un e-mail ou prendre une photo.

Pour ce faire, vous utilisez un objet Intent pour décrire le type d'action que vous souhaitez effectuer, et le système lance l'activité appropriée à partir d'une autre application.

Par exemple, si vous souhaitez permettre à l'utilisateur d'envoyer un e-mail, vous pouvez créer l'intent suivant :

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

Si vous devez lancer une activité externe et obtenir un résultat (par exemple, demander à l'application Appareil photo de prendre une photo et de renvoyer l'image), utilisez les API de résultat Activity modernes plutôt que le rappel startActivityForResult obsolète.

Activités de coordination

Lorsqu'une activité en démarre une autre, elles subissent toutes deux des transitions de cycle de vie. La première activité cesse de fonctionner et passe à l'état "En pause" ou "Arrêtée", tandis que l'autre activité est créée. Si ces activités partagent des données enregistrées sur le disque ou ailleurs, il est important de comprendre que la première activité n'est pas complètement arrêtée avant la création de la seconde. Le processus de démarrage de la deuxième instance chevauche plutôt le processus d'arrêt de la première.

L'ordre des rappels de cycle de vie est bien défini, en particulier lorsque les deux activités se trouvent dans le même processus (autrement dit, la même application) et que l'une démarre l'autre. Voici l'ordre des opérations qui se produisent lorsque l'activité A démarre l'activité B :

1. La méthode onPause de l'activité A s'exécute.
2. Les méthodes onCreate, onStart et onResume de l'activité B s'exécutent l'une après l'autre. L'activité B reçoit désormais le focus de l'utilisateur.
3. Si l'activité A n'est plus visible à l'écran, sa méthode onStop s'exécute.

Cette séquence de rappels de cycle de vie vous permet de gérer la transition des informations d'une activité à une autre.

Ressources supplémentaires

Pour en savoir plus sur le cycle de vie d'une activité, consultez les ressources supplémentaires suivantes :

Contenu des vues

• Cycle de vie d'une activité (vues)