A classe Activity
é um componente crucial de um app
Android, e a maneira como as atividades são iniciadas e reunidas é uma parte fundamental
do modelo de aplicativo da plataforma. Ao contrário dos paradigmas de programação em
que os apps são iniciados com um método main()
, o sistema
Android inicia o código em uma instância de Activity
invocando métodos de callback específicos que correspondem a estágios específicos
do ciclo de vida.
Este documento apresenta o conceito de atividades e fornece algumas orientações simples sobre como trabalhar com elas. Para mais informações sobre as práticas recomendadas para arquitetar seu app, consulte o Guia para a arquitetura do app.
O conceito de atividades
A experiência do app para dispositivos móveis é diferente da versão para computador, porque a interação do usuário com o app nem sempre começa no mesmo lugar. Em vez disso, a jornada do usuário geralmente começa de forma não determinista. Por exemplo, se você abrir um app de e-mails na tela inicial, poderá ver uma lista de e-mails. Por outro lado, se você estiver usando um app de mídia social que inicia seu app de e-mails, pode ir diretamente para a tela do app para escrever um e-mail.
A classe Activity
foi desenvolvida para facilitar esse paradigma.
Quando um app invoca outro, o app de chamada invoca uma atividade no outro
app, em vez do app como um todo atômico. Dessa forma, a atividade serve como
ponto de entrada para a interação de um app com o usuário. Implemente uma
atividade como uma subclasse da classe Activity
.
Uma atividade disponibiliza a janela em que o app desenha a interface. Essa janela normalmente preenche a tela, mas pode ser menor que a tela e flutuar sobre outras janelas. Geralmente, uma atividade implementa uma tela em um app. Por exemplo, uma das atividades de um app pode implementar uma tela de Preferências, enquanto outra atividade implementa uma tela de Selecionar foto.
A maioria dos apps contém várias telas, o que significa que incluem diversas atividades. Normalmente, uma atividade em um app é especificada como a atividade principal, que é a primeira tela que aparece quando o usuário inicia o app. Cada atividade pode iniciar outra para realizar ações diferentes. Por exemplo, a atividade principal em um app de e-mail simples pode fornecer a tela que mostra uma caixa de entrada de e-mail. Depois disso, a atividade principal pode iniciar outras atividades que fornecem telas para tarefas como escrever e-mails e abrir e-mails individuais.
Embora as atividades trabalhem juntas para formar uma experiência do usuário coesa em um app, cada uma delas só é levemente vinculada a outras. Geralmente, há dependências mínimas entre as atividades em um app. Na verdade, as atividades geralmente iniciam atividades que pertencem a outros apps. Por exemplo, um app de navegação pode iniciar a atividade "Compartilhar" de um app de mídias sociais.
Para usar as atividades no app, é necessário registrar informações sobre elas no manifesto e gerenciar os ciclos de vida da atividade de forma adequada. O restante deste documento introduz esses assuntos.
Como configurar o manifesto
Para que seu app possa usar atividades, você precisa declará-las e alguns dos atributos delas no manifesto.
Declarar atividades
Para declarar a atividade, abra o arquivo de manifesto e adicione um elemento <activity> como filho do elemento <application>. Por exemplo:
<manifest ... > <application ... > <activity android:name=".ExampleActivity" /> ... </application ... > ... </manifest >
O único atributo obrigatório para esse elemento é android:name, que especifica o nome da classe da atividade. Também é possível adicionar atributos que definem características da atividade, como rótulo, ícone ou tema da interface. Para mais informações sobre esses e outros atributos, consulte a documentação de referência do elemento <activity>.
Observação : depois de publicar seu app, não mude os nomes das atividades. Se fizer isso, você poderá corromper alguma funcionalidade, como atalhos de apps. Para mais informações sobre as mudanças a serem evitadas após a publicação, consulte O que não pode mudar.
Declarar filtros de intent
Os filtros de intent são um recurso muito eficiente da plataforma Android. Com elas, é possível iniciar uma atividade com base não só em uma solicitação explícita, mas também implícita. Por exemplo, uma solicitação explícita pode dizer ao sistema para "Iniciar a atividade de envio de e-mail no app Gmail". Por outro lado, uma solicitação implícita diz ao sistema para "Iniciar uma tela de envio de e-mail em qualquer atividade que possa realizar a tarefa". Quando a interface do sistema pergunta a um usuário qual app usar para executar uma tarefa, esse é um filtro de intent em ação.
Você pode aproveitar esse recurso declarando um atributo <intent-filter> no elemento <activity>. A definição desse elemento inclui um elemento <action> e, opcionalmente, um elemento <category> e/ou um elemento <data>. Esses elementos são combinados para especificar o tipo de intent a que sua atividade pode responder. Por exemplo, o snippet de código abaixo mostra como configurar uma atividade que envia dados de texto e recebe solicitações de outras atividades para fazer isso:
<activity android:name=".ExampleActivity" android:icon="@drawable/app_icon"> <intent-filter> <action android:name="android.intent.action.SEND" /> <category android:name="android.intent.category.DEFAULT" /> <data android:mimeType="text/plain" /> </intent-filter> </activity>
Neste
exemplo, o elemento <action>
especifica que essa atividade envia dados.
Declarar o elemento <category>
como DEFAULT
permite que a atividade
receba solicitações de inicialização. O elemento <data>
especifica o tipo de dados que
essa atividade pode enviar. O snippet de código abaixo mostra como chamar a
atividade descrita acima:
Kotlin
val sendIntent = Intent().apply { action = Intent.ACTION_SEND type = "text/plain" putExtra(Intent.EXTRA_TEXT, textMessage) } startActivity(sendIntent)
Java
// Create the text message with a string Intent sendIntent = new Intent(); sendIntent.setAction(Intent.ACTION_SEND); sendIntent.setType("text/plain"); sendIntent.putExtra(Intent.EXTRA_TEXT, textMessage); // Start the activity startActivity(sendIntent);
Declarar permissões
Você pode usar a tag
<activity>
do manifesto para controlar
quais apps podem iniciar uma atividade específica. Uma atividade mãe não pode iniciar uma
atividade filha, a menos que as duas tenham as mesmas permissões no
manifesto. Se você declarar um elemento
<uses-permission>
para uma atividade mãe, cada atividade filha vai precisar ter um elemento
<uses-permission>
correspondente.
Por exemplo, se o app quiser usar um app hipotético chamado SocialApp para compartilhar uma postagem nas mídias sociais, o próprio SocialApp precisará definir a permissão que um app chamado precisa ter:
<manifest> <activity android:name="...." android:permission=”com.google.socialapp.permission.SHARE_POST” />
Em seguida, para poder chamar o SocialApp, seu app precisa corresponder à permissão definida no manifesto do SocialApp:
<manifest> <uses-permission android:name="com.google.socialapp.permission.SHARE_POST" /> </manifest>
Para mais informações sobre permissões e segurança em geral, consulte Segurança e permissões.
Como gerenciar o ciclo de vida da atividade
Ao longo da vida útil de uma atividade, ela passa por vários estados. Uma série de callbacks são usados para lidar com transições entre estados. As seções a seguir apresentam esses callbacks.
onCreate()
É necessário implementar esse callback, que é acionado quando o sistema cria sua
atividade. A implementação precisa inicializar os componentes essenciais da
atividade. Por exemplo, seu app precisa criar visualizações e vincular dados a
listas aqui. Mais importante, é aqui que você precisa chamar
setContentView()
para definir o layout da interface do usuário da atividade.
Quando onCreate()
terminar, o
próximo callback será sempre onStart()
.
onStart()
À medida que onCreate()
sai, a atividade
entra no estado "Iniciado" e fica visível para o usuário.
Esse callback contém o que equivale aos preparativos finais da atividade para
vir para o primeiro plano e se tornar interativa.
onResume()
O sistema invoca esse callback pouco antes da atividade começar a interagir
com o usuário. Nesse momento, a atividade está na parte de cima da pilha
de atividades e captura todas as entradas do usuário. A maior parte da funcionalidade principal de um app é
implementada no método onResume()
.
O callback onPause()
sempre
segue onResume()
.
onPause()
O sistema chama onPause()
quando a atividade perde
o foco e entra em um estado "Pausado". Esse estado ocorre quando, por exemplo, o usuário
toca no botão "Voltar" ou "Recentes". Quando o sistema chama
onPause()
para sua atividade,
tecnicamente isso significa que ela ainda está parcialmente visível, mas na maioria das vezes é uma indicação de que
o usuário está saindo da atividade e que ela logo entrará no
estado "Interrompido" ou "Retomado".
Uma atividade no estado "Pausado" pode continuar atualizando a interface se o usuário esperar que ela seja atualizada. Exemplos desse tipo de atividade incluem a exibição de uma tela de mapa de navegação ou de um player de mídia sendo reproduzido. Mesmo que essas atividades percam o foco, o usuário espera que a interface continue sendo atualizada.
Não use
onPause()
para salvar dados de aplicativos ou usuários,
fazer chamadas de rede ou executar transações de banco de dados.
Para mais informações sobre como salvar dados, consulte
Como salvar e restaurar o estado da atividade.
Depois que a execução de onPause()
for concluída,
o próximo callback será onStop()
ou
onResume()
, dependendo do que
acontece depois que a atividade entra no estado "Pausado".
onStop()
O sistema chama onStop()
quando a
atividade não está mais visível para o usuário.
Isso pode acontecer porque a atividade está sendo destruída, uma nova atividade está
começando ou uma atividade existente está entrando
em um estado "Retomado" e está cobrindo a atividade interrompida.
Em todos esses casos, a atividade interrompida não fica mais
visível.
O próximo callback que o sistema chama é
onRestart()
, se a
atividade está voltando para interagir com o usuário, ou por
onDestroy()
,
se essa atividade está sendo completamente encerrada.
onRestart()
O sistema invoca esse callback quando uma atividade no estado "Interrompido" está
prestes de ser reiniciada. onRestart()
restaura o estado da atividade a partir do momento em que foi interrompida.
Esse callback é sempre seguido por
onStart()
.
onDestroy()
O sistema invoca esse callback antes que uma atividade seja destruída.
Esse é o último callback que a atividade recebe.
onDestroy()
geralmente é
implementado para garantir que todos os recursos de uma atividade sejam
liberados quando ela ou o processo que a contém for destruído.
Esta seção é apenas uma introdução a esse tema. Para um tratamento mais detalhado do ciclo de vida da atividade e dos callbacks dele, consulte Ciclo de vida da atividade.