Introdução às atividades

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);
Se o objetivo é que o app seja independente e não permita que outros apps ativem as atividades, nenhum outro filtro de intent vai ser necessário. As atividades que você não quer disponibilizar a outros aplicativos não precisam ter filtros de intent. É possível iniciá-las usando intents explícitas. Para saber mais sobre como suas atividades podem responder a intents, consulte Intents e filtros de intent.

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.