Différents événements, certains déclenchés par l'utilisateur et d'autres par le système, peuvent entraîner le passage d'un Activity d'un état à un autre. Ce document décrit certains cas courants dans lesquels de telles transitions se produisent et explique comment les gérer.
Pour en savoir plus sur les états d'activité, consultez Cycle de vie d'une activité. Pour savoir comment la classe ViewModel peut vous aider à gérer le cycle de vie de l'activité, consultez la présentation de ViewModel.
Pour la plupart des modifications d'activité, vous n'avez pas besoin de répondre directement aux rappels dans le cycle de vie de l'activité. Étant donné que Compose reconstruit les UI à partir de l'état, vous pouvez profiter de la recomposition automatique en veillant à ce que l'état soit stocké dans un emplacement approprié, tel que rememberSaveable ou ViewModel.
Une modification de la configuration se produit
Plusieurs événements peuvent déclencher une modification de la configuration. L'exemple le plus flagrant est le passage du mode Portrait au mode Paysage. Les modifications de configuration peuvent également être dues à des changements de paramètres linguistiques ou de périphérique d'entrée.
Lorsqu'une modification de la configuration se produit, l'activité est détruite et recréée. Cela déclenche les rappels suivants dans l'instance d'activité d'origine :
Une nouvelle instance de l'activité est créée et les rappels suivants sont déclenchés :
Dans Compose, il n'est pas courant d'interagir directement avec ces rappels. Utilisez plutôt l'API Lifecycle pour observer les changements d'état. Dans Compose, vous pouvez utiliser LocalLifecycleOwner.current pour obtenir le cycle de vie actuel et ajouter un observateur, ce qui vous permet de répondre aux événements.
Utilisez une combinaison d'instances ViewModel, de rememberSaveable ou d'un stockage local persistant pour conserver l'état de l'UI d'une activité lors des modifications de configuration.
Le choix de la combinaison de ces options dépend de la complexité des données de votre UI, des cas d'utilisation de votre application, ainsi que de la vitesse de récupération par rapport à l'utilisation de la mémoire. Dans la plupart des cas d'utilisation, vous devez hisser l'état dans un ViewModel et utiliser rememberSaveable pour vous assurer que l'état persiste lors des changements de configuration et de l'arrêt d'un processus initié par le système. Pour en savoir plus sur l'enregistrement de l'état de l'UI de votre activité, consultez Enregistrer les états de l'UI.
Lorsqu'une activité est recréée en raison d'une modification de la configuration, la composition initiale est supprimée. L'utilisation de ViewModel ou rememberSaveable garantit que l'état de votre UI est restauré dans la nouvelle composition.
Pour en savoir plus, consultez Cycle de vie dans Jetpack Compose et État et Jetpack Compose.
Gérer les cas multifenêtres
Lorsqu'une application passe en mode multifenêtre, disponible sur Android 7.0 (niveau d'API 24) ou version ultérieure, le système notifie l'activité en cours d'une modification de configuration, ce qui entraîne les transitions de cycle de vie décrites précédemment.
Ce comportement se produit également si une application déjà en mode multifenêtre est redimensionnée. Votre activité peut gérer elle-même le changement de configuration ou permettre au système de détruire l'activité et de la recréer avec les nouvelles dimensions.
Pour en savoir plus sur le cycle de vie multifenêtre, consultez l'explication du cycle de vie multifenêtre dans Compatibilité avec le mode multifenêtre.
En mode multifenêtre, bien que deux applications soient visibles par l'utilisateur, seule celle avec laquelle il interagit est au premier plan et a le focus. Cette activité est à l'état "Reprise", tandis que l'application de l'autre fenêtre est à l'état "Mise en veille".
Lorsque l'utilisateur passe de l'application A à l'application B, le système appelle onPause sur l'application A et onResume sur l'application B. Il alterne entre ces deux méthodes chaque fois que l'utilisateur bascule entre les applications.
Pour en savoir plus sur le mode multifenêtre, consultez Prise en charge du mode multifenêtre.
Une activité ou une boîte de dialogue s'affiche au premier plan
Si une nouvelle activité ou boîte de dialogue apparaît au premier plan, prend le focus et recouvre partiellement l'activité en cours, l'activité recouverte perd le focus et passe à l'état "En pause". Le système appelle ensuite onPause.
Lorsque l'activité masquée revient au premier plan et retrouve le focus, le système appelle onResume.
Si une nouvelle activité ou boîte de dialogue apparaît au premier plan, prend le focus et recouvre complètement l'activité en cours, l'activité recouverte perd le focus et passe à l'état "Arrêtée". Le système appelle ensuite, rapidement et successivement, onPause et onStop.
Lorsque la même instance de l'activité couverte revient au premier plan, le système appelle onRestart, onStart et onResume sur l'activité. S'il s'agit d'une nouvelle instance de l'activité couverte qui passe en arrière-plan, le système n'appelle pas onRestart, mais uniquement onStart et onResume.
La recomposition n'est pas affectée par les boîtes de dialogue qui s'affichent au premier plan. Toutefois, les effets secondaires liés au cycle de vie, tels que les flux et les animations, doivent utiliser des API compatibles avec le cycle de vie (telles que collectAsStateWithLifecycle) pour mettre en pause et reprendre automatiquement le travail selon les besoins. Pour en savoir plus, consultez État et Jetpack Compose.
L'utilisateur appuie sur Retour ou effectue le geste Retour
Si une activité est au premier plan et que l'utilisateur appuie sur Retour ou effectue un geste Retour, l'activité passe par les rappels onPause, onStop et onDestroy. L'activité est détruite et supprimée de la pile Retour.
Dans une application à activité unique, comme la plupart des applications Compose, rememberSaveable ne conserve pas l'état si le composable est supprimé de la pile "Retour" de navigation. En effet, lorsque l'utilisateur appuie sur "Retour", il ne s'attend pas à revenir à la même instance. Par conséquent, tout l'état est effacé.
Pour implémenter un comportement de retour personnalisé, par exemple en affichant une boîte de dialogue demandant à l'utilisateur de confirmer qu'il souhaite quitter votre application, utilisez l'API NavigationEventHandler.
Le système arrête le processus de l'application
Si une application est en arrière-plan et que le système doit libérer de la mémoire pour une application au premier plan, il peut fermer l'application en arrière-plan. Lorsque le système ferme une application, il n'est pas garanti que onDestroy soit appelé dans l'application.
Pour en savoir plus sur la façon dont le système décide des processus à détruire, consultez État de l'activité et éjection de la mémoire et Processus et cycle de vie de l'application.
Pour savoir comment enregistrer l'état de l'UI de votre activité lorsque le système arrête le processus de votre application, consultez Enregistrer et restaurer l'état transitoire de l'UI.