Ciclo de vida da atividade

À medida que o usuário navega no aplicativo, sai dele e retorna a ele, as instâncias Activity no aplicativo transitam entre diferentes estados no ciclo de vida. A classe Activity fornece vários callbacks que informam à atividade quando um estado muda ou que o sistema está criando, interrompendo ou retomando uma atividade ou destruindo o processo em que ela reside.

Dentro dos métodos de callback do ciclo de vida, você pode declarar como a atividade se comporta quando o usuário sai e retorna dela. Por exemplo, se estiver construindo um reprodutor de vídeos de transmissão em sequência, você pode pausar o vídeo e encerrar a conexão de rede quando o usuário alternar para outro app. Quando o usuário retornar, será possível reconectar a rede e permitir que ele reinicie o vídeo de onde parou.

Cada callback permite que você realize o trabalho específico adequado a determinada mudança de estado. Fazer o trabalho certo no momento apropriado e gerenciar as transições da maneira correta faz com que seu aplicativo seja mais robusto e tenha melhor desempenho. Por exemplo, uma boa implementação dos callbacks de ciclo de vida pode ajudar seu app a evitar o seguinte:

• Falhas se o usuário receber uma ligação ou mudar para outro app enquanto usa o seu.
• Consumo de recursos importantes do sistema quando o usuário não estiver usando ativamente o aplicativo.
• Perda do progresso do usuário se ele sair do aplicativo e retornar mais tarde.
• Falhas ou perda do progresso do usuário quando a tela girar entre as orientações paisagem e retrato.

Este documento explica detalhadamente o ciclo de vida da atividade. O documento começa descrevendo o paradigma do ciclo de vida. Em seguida, cada um dos callbacks é explicado: o que acontece internamente quando eles operam e o que você precisa implementar durante a execução deles.

Depois é apresentada a relação entre o estado da atividade e a vulnerabilidade de um processo que está sendo eliminado pelo sistema. Por fim, vários tópicos relacionados às transições entre os estados de atividade são discutidos.

Para informações sobre como gerenciar ciclos de vida, incluindo orientação sobre práticas recomendadas, consulte Ciclo de vida no Jetpack Compose e Salvar estados da UI. Para saber como arquitetar um app robusto e de qualidade de produção usando atividades em combinação com componentes de arquitetura, consulte o Guia para a arquitetura do app.

Conceitos do ciclo de vida da atividade

Para navegar entre as fases do ciclo de vida da atividade, a classe Activity fornece um conjunto principal de seis callbacks: onCreate, onStart, onResume, onPause, onStop e onDestroy. O sistema invoca cada um desses callbacks conforme a atividade entra em um novo estado.

A Figura 1 mostra uma representação visual desse paradigma.

À medida que o usuário começa a sair da atividade, o sistema chama métodos para eliminá-la. Em alguns casos, a atividade é apenas parcialmente eliminada e ainda reside na memória, como quando o usuário alterna para outro app. Nesses casos, a atividade ainda pode voltar ao primeiro plano.

Se o usuário retornar à atividade, ela será retomada de onde o usuário parou. Com algumas exceções, os apps são impedidos de iniciar atividades quando executados em segundo plano.

A probabilidade de o sistema eliminar um determinado processo, com as atividades nele, depende do estado da atividade no momento. Para mais informações sobre a relação entre o estado e a vulnerabilidade à ejeção, consulte a seção sobre estado da atividade e ejeção da memória.

Dependendo da complexidade de sua atividade, não é necessário implementar todos os métodos do ciclo de vida. No entanto, é importante entender cada um deles e implementar somente os que garantem que o aplicativo tenha o desempenho esperado pelo usuário.

Compose e o ciclo de vida

No Compose, evite colocar lógica de negócios ou configuração manual de observadores diretamente em callbacks de atividade, como onStart ou onResume. Em vez disso, use efeitos com reconhecimento de ciclo de vida e observadores com reconhecimento de estado que se alinham automaticamente com a presença da interface na tela.

• Coleta com reconhecimento de ciclo de vida: use collectAsStateWithLifecycle para consumir fluxos do seu ViewModel. Essa API começa a coletar automaticamente quando a interface entra no estado "Iniciado" e para quando vai para o segundo plano, evitando o consumo desnecessário de recursos. Depois de coletar o fluxo como estado, use LifecycleEffects para executar o código quando um evento de ciclo de vida ocorrer.
• Fluxo de lógica: ao usar essas APIs, a interface reage ao estado do ciclo de vida naturalmente pela árvore de composição, garantindo que a lógica de negócios só seja executada quando o usuário estiver interagindo ativamente com o componente.

Para saber mais sobre o Compose e o ciclo de vida, consulte Ciclo de vida no Jetpack Compose.

Callbacks do ciclo de vida

Esta seção fornece informações conceituais e de implementação sobre os métodos de callback usados durante o ciclo de vida da atividade.

Algumas ações pertencem aos métodos do ciclo de vida da atividade. No entanto, coloque o código que implementa as ações de um componente dependente no componente, em vez do método de ciclo de vida da atividade. Para fazer isso, você precisa tornar o componente dependente ciente do ciclo de vida. Para saber como tornar seus componentes dependentes cientes do ciclo de vida, consulte Ciclo de vida no Jetpack Compose.

onCreate

Esse callback precisa ser implementado. Ele é acionado assim que o sistema cria a atividade. Quando a atividade é criada, ela insere o estado Criado. No método onCreate, execute a lógica básica de inicialização do aplicativo. Isso acontece somente uma vez durante todo o período que a atividade durar.

Por exemplo, sua implementação de onCreate pode vincular dados a listas, associar a atividade a um ViewModel e instanciar algumas variáveis com escopo de classe. Esse método recebe o parâmetro savedInstanceState, que é um objeto Bundle que contém o estado salvo anteriormente da atividade. Se a atividade nunca existiu, o valor do objeto Bundle será nulo.

Se você tiver um componente ciente do ciclo de vida conectado ao ciclo de vida da sua atividade, ele vai receber o evento ON_CREATE. O método anotado com @OnLifecycleEvent é chamado para que seu componente ciente do ciclo de vida possa executar qualquer código de configuração necessário para o estado criado.

O exemplo a seguir mostra como integrar um elemento combinável Text em uma atividade mínima:

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

Sua atividade não permanece no estado "Criado". Depois que o método onCreate conclui a execução, a atividade entra no estado Iniciado e o sistema chama os métodos onStart e onResume em rápida sucessão.

onStart

Quando a atividade entra no estado "Iniciado", o sistema invoca onStart. Essa chamada torna a atividade visível ao usuário à medida que o app se prepara para que a atividade entre em primeiro plano e se torne interativa. Por exemplo, é nesse método que o código que mantém a interface é inicializado.

Quando a atividade é movida para o estado "Iniciado", qualquer componente ciente do ciclo de vida ligado ao ciclo de vida da atividade recebe o evento ON_START.

O método onStart é concluído rapidamente e, como no estado "Criado", a atividade não permanece no estado "Iniciado". Quando a finalização é feita pelo callback, a atividade insere o estado Retomado e o sistema invoca o método onResume.

onResume

Quando a atividade entra no estado "Retomado", ela vem para o primeiro plano, e o sistema invoca o callback onResume. É nesse estado que o aplicativo interage com o usuário. O app permanece nesse estado até que algo afete o foco do app, como o dispositivo receber uma chamada telefônica, o usuário navegar para outra atividade ou a tela do dispositivo ser desativada.

Quando a atividade é movida para o estado "Retomado", qualquer componente ciente do ciclo de vida ligado ao ciclo de vida da atividade recebe o evento ON_RESUME. É nesse momento que os componentes do ciclo de vida podem ativar qualquer funcionalidade que precise operar enquanto o componente estiver visível e em primeiro plano, como o início da visualização da câmera.

Quando ocorre um evento de interrupção, a atividade entra no estado Pausado e o sistema invoca o callback onPause.

Se a atividade retornar do estado "Pausado" para o estado "Retomado", o sistema chamará novamente o método onResume. Por isso, implemente onResume para inicializar os componentes liberados durante onPause e executar outras inicializações que devem ocorrer sempre que a atividade entrar no estado "Retomado".

Este é um exemplo de componente ciente do ciclo de vida que acessa a câmera quando o componente recebe o evento ON_RESUME:

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

O código anterior inicializa a câmera quando o LifecycleObserver recebe o evento ON_RESUME. No entanto, no modo de várias janelas, a atividade poderá ficar completamente visível mesmo quando estiver no estado "Pausado". Por exemplo, quando o app está no modo de várias janelas e o usuário toca na janela que não contém a atividade, essa atividade é movida para o estado "Pausado".

Se você quiser que a câmera seja ativada somente quando o app estiver Retomado (visível e ativo em primeiro plano), inicialize a câmera após o evento ON_RESUME demonstrado anteriormente. Se você quiser manter a câmera ativa enquanto a atividade estiver pausada, mas visível, como no modo de várias janelas, inicialize a câmera após o evento ON_START.

No entanto, deixar a câmera ativa quando a atividade estiver pausada pode negar o acesso de outro aplicativo retomado no modo de várias janelas à câmera. Às vezes, é necessário manter a câmera ativa enquanto sua atividade está pausada, mas isso pode prejudicar a experiência geral do usuário.

Por isso, pense cuidadosamente sobre onde, no ciclo de vida, é mais apropriado assumir o controle de recursos compartilhados do sistema no contexto do modo de várias janelas. Para saber mais sobre o suporte ao modo de várias janelas, consulte Ofereça suporte ao modo de várias janelas.

Independentemente de qual evento de construção você escolher para executar uma operação de inicialização, certifique-se de usar o evento de ciclo de vida correspondente para liberar o recurso. Se você inicializar algo após o evento ON_START, libere ou finalize esse item após o evento ON_STOP. Se você inicializar após o evento ON_RESUME, faça a liberação após o evento ON_PAUSE.

O snippet de código anterior coloca o código de inicialização da câmera em um componente ciente do ciclo de vida. Em vez disso, você pode colocar esse código diretamente nos callbacks do ciclo de vida da atividade, como onStart e onStop, mas isso não é recomendado. Adicionar essa lógica a um componente independente e ciente do ciclo de vida permite reutilizar o componente em várias atividades sem ter que duplicar o código. Para saber como criar um componente ciente do ciclo de vida, consulte Ciclo de vida no Jetpack Compose.

onPause

O sistema chama esse método como a primeira indicação de que o usuário está deixando sua atividade, embora nem sempre signifique que a atividade esteja sendo destruída. Isso indica que a atividade não está mais em primeiro plano, mas ainda está visível se o usuário estiver no modo de várias janelas. Há vários motivos para uma atividade entrar nesse estado:

• Um evento que interrompe a execução do app, conforme descrito na seção sobre o callback onResume, pausa a atividade atual. Esse é o caso mais comum.
• No modo de várias janelas, apenas um app tem foco por vez, e o sistema pausa todos os outros apps.
• A abertura de uma nova atividade semitransparente, como uma caixa de diálogo, pausa a atividade que ela cobre. Enquanto a atividade estiver parcialmente visível, mas não em foco, ela permanecerá pausada.

Quando uma atividade é movida para o estado pausado, qualquer componente ciente do ciclo de vida ligado ao ciclo de vida da atividade recebe o evento ON_PAUSE. É nesse momento que os componentes do ciclo de vida podem interromper qualquer funcionalidade que não precise operar enquanto o componente não estiver em primeiro plano, como na pausa de uma visualização da câmera.

Use o método onPause para pausar ou ajustar operações que não podem continuar ou que podem continuar com moderação enquanto a Activity estiver no estado "Pausado" e que você espera retomar em breve.

Também é possível usar o método onPause para liberar recursos do sistema, tratamento de sensores (como GPS) ou quaisquer recursos que afetem a duração da bateria enquanto a atividade estiver pausada e o usuário não precisar deles.

No entanto, como mencionado na seção sobre onResume, uma atividade pausada ainda poderá ser completamente visível se o app estiver no modo de várias janelas. Considere usar onStop em vez de onPause para liberar ou ajustar completamente recursos e operações relacionadas à interface para melhorar o suporte do modo de várias janelas.

O exemplo a seguir de um LifecycleObserver reagindo ao evento ON_PAUSE é a contraparte do exemplo de evento ON_RESUME anterior, liberando a câmera que é inicializada após o recebimento do evento ON_RESUME:

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

Este exemplo posiciona o código de liberação da câmera depois que o evento ON_PAUSE é recebido pelo LifecycleObserver.

onPauseA execução é muito breve e não oferece necessariamente tempo suficiente para realizar operações de salvamento. Por isso, não use onPause para salvar dados do aplicativo ou do usuário, fazer chamadas de rede ou executar transações de banco de dados. Esse trabalho pode não ser concluído antes da conclusão do método.

Em vez disso, realize operações de desligamento pesadas durante onStop. Para mais informações sobre operações adequadas a serem realizadas durante onStop, consulte a próxima seção. Para mais informações sobre como salvar dados, consulte a seção sobre salvar e restaurar estado.

A conclusão do método onPause não significa que a atividade saia do estado "Pausado". Na verdade, a atividade permanece nesse estado até que ela seja retomada ou fique completamente invisível para o usuário. Se a atividade for retomada, o sistema invocará mais uma vez o callback onResume.

Se a atividade retornar do estado "Pausado" para o estado "Retomado", o sistema manterá a instância Activity residente na memória, chamando novamente a instância quando o sistema invocar onResume. Nesse cenário, não é necessário reiniciar componentes criados durante qualquer método de callback que leve ao estado "Retomado". Se a atividade ficar completamente invisível, o sistema chamará onStop.

onStop

Quando a atividade não estiver mais visível ao usuário, ela entrará no estado Interrompido e o sistema invocará o callback onStop. Isso pode acontecer quando uma atividade recém-lançada preenche toda a tela. O sistema também chama onStop quando a atividade para de operar e está prestes a ser concluída.

Quando a atividade é movida para o estado "Interrompido", qualquer componente ciente do ciclo de vida ligado ao ciclo de vida da atividade recebe o evento ON_STOP. É nesse momento que os componentes do ciclo de vida podem interromper qualquer funcionalidade que não precise operar enquanto o componente não estiver visível na tela.

No método onStop, libere ou ajuste recursos desnecessários enquanto o app não estiver visível ao usuário. Por exemplo, o app pode pausar animações ou alternar de atualizações de local mais específicas para as menos detalhadas. O uso de onStop em vez de onPause significa que o trabalho relacionado à interface continua, mesmo quando o usuário está visualizando a atividade no modo de várias janelas.

Use onStop também para realizar operações de desligamento de uso intensivo da CPU. Por exemplo, se você não encontrar um momento melhor para salvar informações em um banco de dados, poderá fazer isso durante onStop. O exemplo abaixo mostra uma implementação de onStop que salva o conteúdo de uma nota de rascunho no armazenamento persistente:

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()
}

Quando sua atividade entra no estado "Parado", o objeto Activity é mantido residente na memória: ele mantém todas as informações de estado e membro, mas não é anexado ao gerenciador de janelas. Quando a atividade é retomada, ela chama novamente essas informações.

A partir do estado "Interrompido", a atividade volta a interagir com o usuário ou para de operar e é encerrada. Se a atividade voltar, o sistema invocará onRestart. Se a Activity deixar de operar, o sistema chamará onDestroy.

onDestroy

onDestroy é chamado antes de a atividade ser destruída. O sistema invoca esse callback por um destes dois motivos:

1. A atividade está sendo finalizada porque o usuário a descartou completamente ou porque finish foi chamado nela.
2. O sistema está destruindo temporariamente a atividade devido a uma mudança na configuração, como a rotação do dispositivo ou a entrada no modo de várias janelas.

Quando a atividade é movida para o estado destruído, qualquer componente ciente do ciclo de vida ligado ao ciclo de vida da atividade recebe o evento ON_DESTROY. É nesse momento que os componentes do ciclo de vida podem limpar qualquer item que eles precisarem antes da destruição do Activity.

Em vez de inserir lógica na sua Activity para determinar por que ela está sendo destruída, use um objeto ViewModel para manter os dados de visualização relevantes para sua Activity. Se o Activity for recriado devido a uma mudança na configuração, o ViewModel não precisará fazer nada, já que será preservado e fornecido à próxima instância de Activity.

Se a Activity não for recriada, a ViewModel vai chamar o método onCleared, em que ela pode limpar os dados necessários antes da destruição. É possível distinguir entre essas duas situações com o método isFinishing.

Caso a atividade esteja sendo encerrada, onDestroy será o callback do ciclo de vida final recebido pela atividade. Se onDestroy for chamado como resultado de uma mudança na configuração, o sistema criará imediatamente uma nova instância de atividade e chamará onCreate nessa instância na nova configuração.

O callback onDestroy libera todos os recursos não liberados por callbacks anteriores, como onStop.

Estado da atividade e ejeção da memória

O sistema elimina processos quando precisa liberar RAM. A probabilidade de o sistema eliminar um determinado processo depende do estado dele no momento. O estado do processo, por sua vez, depende do estado da atividade em execução no processo. A tabela 1 mostra as correlações entre o estado do processo, o estado da atividade e a probabilidade de o sistema eliminar o processo. Essa tabela só se aplica se um processo não estiver executando outros tipos de componentes de aplicativo.

Tabela 1. Relação entre o ciclo de vida do processo e o estado da atividade.

O sistema nunca elimina uma atividade diretamente para liberar memória. Em vez disso, ele elimina o processo em que a atividade é executada, destruindo não só a atividade, mas todo o restante em execução no processo. Para saber como preservar e restaurar o estado da UI da atividade quando ocorre o encerramento do processo iniciado pelo sistema, consulte a seção sobre salvar e restaurar o estado.

O usuário também pode eliminar um processo usando o Gerenciador de aplicativos, em Configurações, para eliminar o app correspondente.

Para mais informações sobre processos, consulte Visão geral dos processos e das linhas de execução.

Como salvar e restaurar o estado transitório da IU

O usuário espera que o estado da interface de uma atividade permaneça o mesmo durante uma mudança de configuração, como girar ou mudar o dispositivo para o modo de várias janelas. No entanto, o sistema destrói a atividade por padrão quando ocorre uma mudança de configuração. Isso exclui qualquer estado de IU armazenado na instância da atividade.

Da mesma forma, um usuário espera que o estado da interface permaneça o mesmo se ele alternar temporariamente do seu app para outro e retornar ao inicial depois. No entanto, o sistema pode destruir o processo do aplicativo enquanto o usuário estiver ausente e a atividade for interrompida.

Quando limitações do sistema destroem a atividade, use uma combinação de ViewModel (para lógica de negócios complexa e estado da tela), a API rememberSaveable do Jetpack Compose (para estado da interface leve) e/ou armazenamento local para preservar o estado transitório da interface do usuário. Para saber mais sobre as expectativas do usuário em relação ao comportamento do sistema e como preservar melhor os dados complexos do estado da UI nas atividades iniciais pelo sistema e encerramento do processo, consulte Como salvar estados da UI.

O rememberSaveable sobrevive automaticamente a mudanças de configuração e ao encerramento do processo iniciado pelo sistema, agrupando o estado em segundo plano e oferecendo uma experiência perfeita sem a necessidade de clichês no nível da atividade.

Estado da instância

Há alguns casos em que a atividade é destruída devido ao comportamento normal do app, como quando o usuário pressiona o botão "Voltar" ou a atividade sinaliza a própria destruição chamando o método finish.

Quando a atividade é destruída porque o usuário pressionou o botão "Voltar" ou a atividade é finalizada, o conceito do sistema e do usuário dessa instância Activity se perde. Nesses cenários, a expectativa do usuário corresponde ao comportamento do sistema, e você não tem trabalho extra.

No entanto, se o sistema destruir a atividade devido a limitações dele mesmo (como uma mudança na configuração ou pressão sobre a memória), embora a instância Activity real tenha se perdido, o sistema recordará a existência dela. Se o usuário tentar navegar de volta para a atividade, o sistema criará uma nova instância dela usando um conjunto de dados salvos que descrevem o estado da atividade quando ela foi destruída.

Os dados salvos que o sistema usa para restaurar o estado anterior são chamados de estado da instância. Por baixo dos panos, é uma coleção de pares de chave-valor. Por padrão, o sistema usa o estado da instância para salvar informações básicas sobre o layout da interface, como entrada de texto do usuário ou posições de rolagem.

Você se conecta a esse comportamento do sistema usando rememberSaveable. Se a instância da atividade for destruída e recriada, qualquer estado da interface do usuário envolvido em rememberSaveable será restaurado automaticamente, sem precisar de mais código no nível da atividade.

No entanto, a atividade provavelmente terá informações de estado mais complexas que você gostaria de restaurar, como dados do usuário, respostas de rede ou variáveis de membro que rastreiam o progresso do usuário. O mecanismo de estado da instância (e, por extensão, rememberSaveable) não é adequado para preservar mais do que uma quantidade trivial de dados, porque requer serialização no thread principal e consome memória do processo do sistema.

Para preservar mais do que uma quantidade muito pequena de dados, use uma abordagem combinada com armazenamento local persistente, a classe ViewModel e elevação de estado do Compose, conforme descrito em Salvar estados da interface.

Salvar estados de UI leves e simples com rememberSaveable

À medida que a atividade começa a parar, o sistema se prepara para salvar informações de estado em um pacote de estado da instância. Para se conectar a esse comportamento do sistema, use rememberSaveable diretamente nas funções combináveis. O rememberSaveable salva e restaura automaticamente o estado transitório da interface, como entrada de texto do usuário ou posições de rolagem, durante a recriação da atividade.

Para salvar informações de estado personalizadas e leves (como o progresso de um usuário em um jogo), declare o estado usando rememberSaveable. O framework Compose processa a serialização para o pacote de estado da instância em segundo plano:

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

Para salvar os dados persistentes, como as preferências do usuário ou dados para um banco de dados, aproveite as oportunidades adequadas quando a atividade estiver em primeiro plano. Se essa oportunidade não surgir, salve os dados persistentes durante o método onStop.

Restaurar o estado de IU da atividade por meio de um estado da instância salvo

Quando a atividade é recriada depois de ter sido destruída, a restauração do estado é automática. Ao usar rememberSaveable, não é necessário escrever uma lógica de restauração explícita, verificar pacotes nulos ou substituir callbacks de atividade. O código que inicializa e salva o estado também o restaura sem problemas quando a atividade volta:

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

Atividades e navegação

Um app provavelmente vai fazer a transição entre telas muitas vezes durante a vida útil dele, como quando o usuário toca no botão "Voltar" do dispositivo ou seleciona um novo destino. Os apps Android modernos geralmente usam uma arquitetura de atividade única. Em vez de iniciar um novo Activity para cada tela, o app hospeda um único Activity e usa o componente Navigation para trocar telas combináveis nessa atividade.

Para saber como implementar a navegação moderna e com foco no Compose, consulte o guia da biblioteca Navigation 3 do Jetpack Compose.

Como iniciar uma atividade a partir de outra

Uma atividade pode precisar iniciar outra em algum momento. Essa necessidade surge, por exemplo, quando um app precisa ser movido da tela atual para uma nova.

Dependendo se sua atividade quer um resultado da atividade que está prestes a iniciar, inicie a nova atividade usando o método startActivity ou startActivityForResult. De qualquer forma, passe um objeto Intent.

O objeto Intent especifica a atividade exata a ser iniciada ou descreve o tipo de ação que ela deve executar. O sistema seleciona a atividade adequada, que pode ser até de um outro aplicativo. Um objeto Intent também pode carregar pequenas quantidades de dados que serão usados pela atividade iniciada. Para mais informações sobre a classe Intent, consulte Intents e filtros de intents.

startActivity

Se a atividade recém-criada não precisar retornar um resultado, a atividade atual poderá iniciá-la chamando o método startActivity.

Ao trabalhar no aplicativo, frequentemente será necessário iniciar uma atividade conhecida. Por exemplo, o snippet de código a seguir mostra como iniciar uma atividade chamada SignInActivity.

val context = LocalContext.current

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

Como iniciar atividades externas

Embora a navegação interna do app seja processada por Navigation, seu Activity precisará iniciar outras atividades ocasionalmente. Isso geralmente acontece quando você quer usar um app externo para realizar uma ação específica, como abrir um navegador da Web, enviar um e-mail ou tirar uma foto.

Para isso, use um objeto Intent para descrever o tipo de ação que você quer realizar, e o sistema inicia a atividade apropriada de outro aplicativo.

Por exemplo, se quiser que o usuário envie uma mensagem de e-mail, é possível criar a seguinte intent:

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

Se você precisar iniciar uma atividade externa e receber um resultado (como pedir para o app de câmera tirar uma foto e retornar a imagem), use as APIs de Activity resultado modernas em vez do callback startActivityForResult descontinuado.

Coordenação de atividades

Quando uma atividade inicia outra, ambas passam por transições no ciclo de vida. A primeira atividade para de operar e entra no estado "Pausado" ou "Interrompido" enquanto a outra atividade é criada. Caso essas atividades compartilhem dados salvos em disco ou em outro lugar, é importante compreender que a primeira atividade não é totalmente interrompida antes da criação da segunda. Em vez disso, o processo de iniciar a segunda se sobrepõe ao processo de interromper a primeira.

A ordem dos callbacks do ciclo de vida é bem definida, especialmente quando as duas atividades estão no mesmo processo (ou seja, no mesmo app) e uma está iniciando a outra. Esta é a ordem das operações que ocorrem quando a atividade A inicia a atividade B:

1. O método onPause da atividade A é executado.
2. Os métodos onCreate, onStart e onResume da atividade B são executados em sequência. A atividade B agora tem o foco do usuário.
3. Se a atividade A não estiver mais visível na tela, o método onStop será executado.

Essa sequência de callbacks do ciclo de vida permite gerenciar a transição de informações de uma atividade para outra.

Outros recursos

Para saber mais sobre o ciclo de vida da atividade, consulte os seguintes recursos adicionais:

Visualiza conteúdo

• O ciclo de vida da atividade (Views)