Eventos diferentes, alguns acionados pelo usuário e outros pelo sistema, podem fazer com que um
Activity faça a transição de um estado para outro. Este documento descreve
alguns casos comuns em que essas transições acontecem e como lidar com elas.
Para mais informações sobre os estados de atividade, consulte Ciclo de vida da atividade. Para
saber como a classe ViewModel pode ajudar você a gerenciar o ciclo de vida
da atividade, consulte a Visão geral do ViewModel.
Para a maioria das mudanças de atividade, não é necessário responder diretamente aos callbacks no
ciclo de vida da atividade. Como o Compose recria interfaces com base no estado, você pode aproveitar a recomposição automática garantindo que o estado seja armazenado em um lugar adequado, como rememberSaveable ou ViewModel.
Ocorre uma mudança na configuração
Há vários eventos que podem acionar uma mudança de configuração. Talvez o exemplo mais proeminente seja uma mudança entre as orientações retrato e paisagem. Outros casos que podem causar mudanças na configuração incluem mudanças no idioma ou no dispositivo de entrada.
Quando ocorre uma mudança na configuração, a atividade é destruída e recriada. Isso aciona os seguintes callbacks na instância da atividade original:
Uma nova instância da atividade é criada, e os seguintes callbacks são acionados:
No Compose, não é comum interagir diretamente com esses retornos de chamada. Em vez disso, use a API Lifecycle para observar as mudanças de estado. No Compose, você pode usar
LocalLifecycleOwner.current para receber o ciclo de vida atual e adicionar um
observador, permitindo que você responda a eventos.
Use uma combinação de instâncias ViewModel, rememberSaveable ou armazenamento local persistente para preservar o estado da interface de uma atividade nas mudanças de configuração.
Decidir como combinar essas opções depende da complexidade dos dados de IU, dos casos de uso do seu app e da consideração da velocidade de recuperação contra o uso da memória. Na maioria dos casos de uso, é necessário elevar o estado para um ViewModel e
usar rememberSaveable para garantir que o estado persista em mudanças de
configuração e encerramento do processo iniciado pelo sistema. Para mais informações sobre como salvar
o estado da sua interface de atividades, consulte Salvar estados da interface.
Quando uma atividade é recriada devido a uma mudança de configuração, a composição
inicial é descartada. O uso de ViewModel ou rememberSaveable garante que o
estado da interface seja restaurado na nova composição.
Para mais informações, consulte Ciclo de vida no Jetpack Compose e Estado e Jetpack Compose.
Gerenciar casos de várias janelas
Quando um app entra no modo de várias janelas, disponível no Android 7.0 (nível da API 24) e versões mais recentes, o sistema notifica a atividade em execução sobre uma mudança de configuração, passando pelas transições de ciclo de vida descritas anteriormente.
Esse comportamento também ocorre se um app que já está no modo de várias janelas for redimensionado. Sua atividade pode processar a mudança de configuração por conta própria ou permitir que o sistema destrua a atividade e a recrie com as novas dimensões.
Para mais informações sobre o ciclo de vida de várias janelas, consulte a explicação do ciclo de vida de várias janelas em Suporte ao modo de várias janelas.
No modo de várias janelas, embora haja dois apps visíveis para o usuário, apenas aquele com que o usuário está interagindo fica em primeiro plano e focalizado. Essa atividade está no estado "Retomado", enquanto o app na outra janela está no estado "Pausado".
Quando o usuário alterna do app A para o B, o sistema chama onPause no
app A e onResume no app B. Ele alterna entre esses dois métodos
sempre que o usuário alterna entre os apps.
Para mais detalhes sobre o modo de várias janelas, consulte Suporte ao modo de várias janelas.
A atividade ou a caixa de diálogo é exibida em primeiro plano
Se uma nova atividade ou caixa de diálogo aparecer em primeiro plano, assumindo o foco e encobrindo parcialmente a atividade em andamento, a atividade oculta perderá o foco e entrará no estado "Pausado". Em seguida, o sistema chama onPause.
Quando a atividade encoberta retorna para o primeiro plano e recupera o foco, o
sistema chama onResume.
Se uma nova atividade ou caixa de diálogo aparecer em primeiro plano, com foco e encobrindo completamente a atividade em andamento, a atividade encoberta perderá o foco e entrará no estado "Parado". Em seguida, o sistema, em rápida sucessão, chama
onPause e onStop.
Quando a mesma instância da atividade encoberta retorna para o primeiro plano, o
sistema chama onRestart, onStart e onResume na
atividade. Se for uma nova instância da atividade encoberta que chega ao segundo plano, o sistema não chamará onRestart, apenas onStart e onResume.
A recomposição não é afetada por caixas de diálogo que aparecem em primeiro plano. No entanto, efeitos colaterais vinculados ao ciclo de vida, como fluxos e animações, precisam usar APIs com reconhecimento do ciclo de vida (como collectAsStateWithLifecycle) para pausar e retomar o trabalho automaticamente conforme necessário. Para mais informações, consulte Estado
e Jetpack Compose.
O usuário toca ou faz um gesto para voltar
Se uma atividade estiver em primeiro plano e o usuário tocar ou fizer o gesto de voltar, a
atividade fará a transição pelos callbacks onPause, onStop e
onDestroy. A atividade é destruída e removida da
backstack.
Em um app de atividade única, como a maioria dos apps do Compose, o rememberSaveable não
mantém o estado se o elemento combinável for removido da backstack de navegação. Isso acontece porque, quando o usuário toca em "Voltar", não há expectativa de que ele retorne à mesma instância, então todo o estado é limpo.
Para implementar um comportamento de retorno personalizado, como mostrar uma caixa de diálogo que pede ao
usuário para confirmar se ele quer sair do app, use a
API NavigationEventHandler.
O sistema elimina o processo do app
Se um app estiver em segundo plano e o sistema precisar liberar memória para um aplicativo em primeiro plano, o sistema poderá encerrar o app em segundo plano. Quando o sistema encerra um app, não há garantia de que onDestroy seja chamado no app.
Para saber mais sobre como o sistema decide quais processos destroy, leia estado da atividade e expulsão da memória e Processos e ciclo de vida do app.
Para saber como salvar o estado da interface da atividade quando o sistema encerra o processo do app, consulte Como salvar e restaurar o estado transitório da interface.