Diferentes eventos, algunos activados por el usuario y otros activados por el sistema, pueden provocar que un
Activity pase de un estado a otro. En este documento, se describen algunos casos comunes en los que ocurren tales transiciones y cómo administrarlas.
Para obtener más información sobre los estados de una actividad, consulta El ciclo de vida de la actividad. Para
obtener información sobre cómo la ViewModel clase puede ayudarte a administrar el ciclo de vida de la actividad, consulta la descripción general de ViewModel.
Para la mayoría de los cambios de actividad, no es necesario que respondas directamente a las devoluciones de llamadas en el ciclo de vida de la actividad. Como Compose vuelve a compilar las IUs a partir del estado, puedes aprovechar la recomposición automática si te aseguras de que el estado se almacene en un lugar adecuado, como rememberSaveable o ViewModel.
Se produce un cambio de configuración
Hay una serie de eventos que pueden activar un cambio de configuración. Quizás el ejemplo más destacado es un cambio entre las orientaciones vertical y horizontal. Entre otros casos que pueden causar cambios de configuración, se incluyen los cambios de configuración de idioma o de dispositivo de entrada.
Cuando se produce un cambio de configuración, la actividad se elimina y se vuelve a crear. Esto activa las siguientes devoluciones de llamadas en la instancia de actividad original:
Se crea una nueva instancia de la actividad y se activan las siguientes devoluciones de llamadas:
En Compose, no es habitual interactuar con estas devoluciones de llamadas directamente. En su lugar, usa la API de Lifecycle para observar los cambios de estado. En Compose, puedes usar LocalLifecycleOwner.current para obtener el ciclo de vida actual y agregar un observador, lo que te permite responder a los eventos.
Usa una combinación de instancias de ViewModel, rememberSaveable o almacenamiento local persistente para conservar el estado de la IU de una actividad durante los cambios de configuración.
Para decidir cómo combinar estas opciones, se debe tener en cuenta la complejidad de los datos de la IU, los casos de uso de la app y la velocidad de recuperación en relación con el uso de la memoria. Para la mayoría de los casos de uso, debes elevar el estado a un ViewModel y usar rememberSaveable para garantizar que el estado persista a través de los cambios de configuración y el cierre del proceso iniciado por el sistema. Para obtener más información sobre cómo guardar
el estado de IU de tu actividad, consulta Cómo guardar estados de la IU.
Cuando se vuelve a crear una actividad debido a un cambio de configuración, se descarta la composición inicial. El uso de ViewModel o rememberSaveable garantiza que se restablezca el estado de la IU en la nueva composición.
Para obtener más información, consulta Ciclo de vida en Jetpack Compose y El estado y Jetpack Compose.
Cómo administrar los casos en modo multiventana
Cuando una app activa el modo multiventana en Android 7.0 (nivel de API 24) y versiones posteriores, el sistema notifica a la actividad que está actualmente en ejecución sobre un cambio de configuración y pasa por las transiciones del ciclo de vida que se describen más arriba.
Este comportamiento también se produce si se cambia el tamaño de una app que ya está en modo multiventana. Tu actividad puede administrar el cambio de configuración o permitir que el sistema elimine la actividad y la vuelva a crear con las nuevas dimensiones.
Para obtener más información sobre el ciclo de vida del modo multiventana, consulta la explicación de el ciclo de vida del modo multiventana en Compatibilidad con el modo multiventana.
En el modo multiventana, si bien hay dos apps que son visibles para el usuario, solo aquella con la que el usuario está interactuando está en primer plano y tiene el foco. El estado de esta actividad es Reanudada, mientras que el de la app en la otra ventana es Detenida.
Cuando el usuario cambia de la app A a la app B, el sistema llama a onPause en
la app A y a onResume en la app B. Cada vez que el usuario cambia de app, se alterna entre estos dos métodos.
Para obtener más información sobre el modo multiventana, consulta Compatibilidad con el modo multiventana.
La actividad o el diálogo aparecen en primer plano
Si aparece en primer plano una nueva actividad o un nuevo diálogo que obtiene el foco y cubre parcialmente la actividad en progreso, la actividad cubierta pierde el foco y pasa al estado Detenida. Luego, el sistema llama a onPause en esta.
Cuando la actividad cubierta vuelve al primer plano y obtiene el foco, el
sistema llama a onResume.
Si aparece en primer plano una nueva actividad o un nuevo diálogo que obtiene el foco y cubre completamente la actividad en progreso, la actividad cubierta pierde el foco y pasa al estado Detenida. Luego, el sistema llama rápidamente a
onPause y onStop.
Cuando la misma instancia de la actividad cubierta vuelve al primer plano, el
sistema llama a onRestart, onStart y onResume en la
actividad. Si se trata de una instancia nueva de la actividad cubierta que aparece en segundo plano, el sistema no invoca a onRestart, solo llama a onStart y onResume.
La recomposición no se ve afectada por los diálogos que aparecen en primer plano. Sin embargo,
los efectos secundarios vinculados al ciclo de vida, como los flujos y las animaciones, deben usar
APIs compatibles con el ciclo de vida (como collectAsStateWithLifecycle) para
pausar y reanudar automáticamente el trabajo según sea necesario. Para obtener más información, consulta El estado
y Jetpack Compose.
El usuario toca o hace gestos de Atrás
Si una actividad está en primer plano y el usuario toca o hace gestos de Atrás, la
actividad pasa por las devoluciones de llamadas onPause, onStop y
onDestroy. La actividad se elimina y se quita de la pila de actividades.
En una app de una sola actividad, como la mayoría de las apps de Compose, rememberSaveable no mantendrá el estado si se quita el componible de la pila de actividades de navegación. Esto se debe a que, cuando el usuario presiona Atrás, no se espera que regrese a la misma instancia, por lo que se borra todo el estado.
Para implementar un comportamiento personalizado de Atrás, como mostrar un diálogo que le pida al usuario que confirme que quiere salir de tu app, usa la API de NavigationEventHandler.
El sistema elimina el proceso de la app
Si una app está en segundo plano y el sistema necesita liberar memoria para una app en primer plano, el sistema puede eliminar la que está en segundo plano. Cuando el sistema elimina una app, no se garantiza que se llame a onDestroy en la app.
Para obtener más información sobre cómo el sistema decide qué procesos destruir, lee Estado de la actividad y expulsión de la memoria y Ciclo de vida de procesos y aplicaciones.
Para obtener información sobre cómo guardar el estado de la IU de la actividad cuando el sistema elimina el proceso de tu app, consulta Cómo guardar y restablecer el estado de la IU transitorio.