Veja todas as aulas aqui.

E ae, galera! Tudo bem? Primeiramente gostaria de me desculpar pelo hiato das aulas. Infelizmente após terminar a 3ª aula eu tive um problema com o computador e demorei um pouco para resolver, quando consegui enfim arrumar tudo, me vi sem tempo por causa do trabalho… mas chega de desculpas e vamos para nossa 3ª aula!  #partiu

Não me odeiem, mas essa aula será teórica, então, por favor fechem o Android Studio :(

Mas não era sobre UI?

Sim! Mas antes de falar sobre User Interface, vamos falar sobre Activity (atividades) e Fragment (fragmentos). Sendo assim, UI fica para a próxima aula (Aula 5), mas não se preocupe, irei postá-la logo (dividi apenas para ficar mais organizado).

Então vamos a uma das maiores perguntas nessa fase do estudo: Qual a diferença entre Activity e Fragment no Android?

Activity

Uma Activity (usarei o termo em inglês com letra maiúscula, cujo plural é Activities, para já irmos nos acostumando) é uma única “coisa” que o usuário pode fazer. Parece estranho ou óbvio demais, mas é isso mesmo! Uma Activity é uma atividade ou ação da sua aplicação.

Toda aplicação Android é formada por uma ou mais Activities e só uma pode rodar por vez. Quase todas as Activities possuem interação com o usuário, desse modo, a classe Activity do Android cuida da criação de uma janela na qual você (desenvolvedor) vai jogar sua UI com o método setContentView(View) (falaremos disso com mais detalhes na próxima aula). Mas isso não é tudo: apesar de a maioria das Activities construírem sua UI em uma tela cheia, há casos de janelas flutuantes (num tema com windowIsFloating setado) e Activities dentro de outra Activity (ActivityGroup).

Fragment

A partir da versão HONEYCOMB a classe Activity implementou a classe Fragment pensando na modularização, na construição de User Interface sofisticados para telas maiores e em ajudar a expandir a sua aplicação entre telas pequenas e grandes.

De forma simples:
    Imagine que sua User Interface não vem mais na Activity, mas em uma “coisa” separada e você pode chamar esse código em várias Activities de acordo com sua vontade (ou com o Ciclo de Vida da Aplicação). Esse é o conceito base dos Fragments (fragmentos). E essa gerência é feita através do FragmentManager (assunto que veremos na prática, mais para frente).

Mobile vs Desktop

Como Desenvolvedor Android, você deve entender que um dispositivo móvel não possui a mesma capacidade de processamento de um Desktop, por exemplo. Então, diferente das aplicações Desktop, que podem rodar simultaneamente (alternando apenas com o Alt+Tab), as Activities dificilmente serão executadas em simultâneo (nem mesmo no nosso querido Android, que é um dos melhores sistemas operacionais para dispositivos móveis). É por isso, que temos a Activity Stack e o Ciclo de Vida de uma Activity.

Activity Stack

A forma mais fácil de identificar uma Activity é uma tela. Não é regra, mas geralmente se o App possui uma tela, possui uma Activity e duas telas significam 2 Activities. Além das Activities da sua aplicação, temos as Activities do próprio Android.

E como (geralmente) só uma Activity é executa por vez, a Activity Stack ou Pilha de Atividades é quem faz esse gerenciamento.

Na prática

Imagine um aplicativo de notícias. Estamos lendo uma notícia e essa “tela” representa uma Activity (em azul, na imagem abaixo), afinal toda a UI foi montada nela e os dados impressos na View. Ao terminar de ler, você quer compartilhar essa notícia, certo? Aí você toca no botão de Compartilhar e então uma nova Activity (em verde) surge sobre a anterior, mas ainda podemos vê-la por baixo (na web isso seria algo como uma lightbox ou um pop-up). Então você decide compartilhar por e-mail e ao escolher essa opção o App do Gmail abre por cima, ou seja, uma nova Activity (em laranja) foi para o topo da pilha.

Interessante, né? A escolha da Activity que está no topo é feita pela Activity Stack e toda essa mudança de estados faz parte do Ciclo da Vida da Activity. Sobre a Activity Stack já falamos, agora é hora do Ciclo da Vida ou Life Cycle de uma Activity no Android.

Life Cycle de uma Activity

Na imagem anterior, a Activity 1 ficou no estado pausado (on Pause state) enquanto a Activity 2 apareceu, pois ela ainda era visível. No momento em que a Activity 3 foi chamada, a 2 deixou de aparecer, sendo assim ela mudou para o estado parado (on Stop state). Isso ocorreu também com a Activity 2, mas como ela já cumpriu seu papel, depois do on Stop ela vai para o estado de destruída (on Destroy state) e é finalizada.

Após o envio do e-mail (ou por ação do usuário) a Activity 1 pode voltar para o topo, sendo assim, ela iria ser reiniciada (onRestart ocorre), já que estava no estado parado. Se o usuário tivesse cancelado a ação de compartilhar (no segundo passo) a Activity 2 teria sido destruída e a 1 retornaria para o 1° plano saindo do estado pausado, então ela não seria mais reiniciada, mas sim retomada (onResume ocorre).

Esse ciclo pode ser visto melhor na imagem abaixo:

Sendo assim, podemos identificar 3 ciclos:

O ciclo completo de vida da Activity ocorre entre a primeira chamada no onCreate(Bundle) até a única chamada de onDestroy(). Sendo assim, uma Activity irá executar tudo o que for “global” no onCreate() e liberar todos os recursos no onDestroy().

O ciclo visível de vida da Activity ocorre entre o onStart() até o onStop() correspondente (depois de um onStop, podemos ter outro onStart, depois de um onRestart). Durante esse tempo o usuário pode ver a UI gerada pela Activity na tela, mesmo que não possa interagir. Entre esses dois métodos você pode manter os recursos necessários para mostrar a Activity para o usuário. Por exemplo, você pode registrar um BroadcastReceiver no onStart() para monitorar as mudanças de dados que impactam na sua UI (atualização constante de dados, por exemplo) e retirar esse registro no onStop(), quando o usuário não consegue mais ver sua UI. Isso pode acontecer várias vezes enquanto a Activity se torna visível e invisível para o usuário, assim você economiza recurso (o BroadcastReceiver), quando ele não for necessário.

O ciclo de primeiro plano da vida da Activity acontece entre o onResume() até o seu onPause() correspondente (a mesma coisa do onStop e onStart, mas dessa vez, não teremos um método no meio, como o onRestart, mas sim a Activity vai direto, como você viu na imagem). Durante esse tempo a Activity está no topo da tela e o usuário pode interagir com ela. Uma Activity pode ir frequentemente entre o estado Paused (pausado) e Resumed (resumido), sendo assim o código aqui deve ser leve: nada de colocar todo o seu código aqui!

Os Métodos

Voltando à imagem (que eu tirei da documentação do Android, claro!) podemos ver que determinados métodos são chamados em cada mudança de estado e isso é legal, pois o Desenvolvedor pode manipular sua aplicação com isso. Por exemplo, ele pode salvar os dados antes da Activity ser parada ou destruída. Vamos ver cada método:

• onCreate() – Executado quando uma Activity é criada. Geralmente é o método responsável por carregar os layouts (XML) e outras operações de inicialização. Só é executado 1 vez durante o Clico de Vida da Activity.
• onStart() – É chamado logo depois do onCreate() ou quando a Activity que estava em background volta a ter foco. (Depois dela temos onResume, caso a Activity esteja em primeiro plano ou onStop se ela não for visível).
• onResume() – Método chamado quando a Activity vai começar a interagir com o usuário (ou retoma foco). Sempre vem depois do onStart, caso a Activity tenha sido iniciada ou se ela estava parada (onStop), ou pode ocorrer direto (vindo depois do onPause) caso a Activity, que não estava em primeiro plano, mas ainda visível, volte para o topo.
• onPause() – Ocorre logo antes da Activity perder o foco, ou seja, quando ir para o Background, mas não foi (ainda) destruída. Geralmente é usada para parar animações e recursos que estejam consumindo processamento e persistir dados não salvos, desta forma, se (por falta de recursos) a Activity for destruída, não perderemos essas informações. Tenha em mente que a Activity que está tomando o foco não será criada até que esse método retorne, sendo assim, o código aqui também deve ser leve.
• onStop() – Ocorre assim que a Activity deixa de aparecer totalmente. Pode ser seguida por onRestart caso a Activity volte ao topo ou por onDestroy caso ela passe dessa para uma melhor.
• onRestart() – É chamado quando uma Activity que estava parada volta ao foco. Bem antes do onStart.
• onDestroy() – Esse método ocorre logo antes da Activity ser destruída/finalizada (alguém chamou finish() ou o sistema está temporariamente a destruindo para salvar recursos, você pode verificar isFinishing() para distinguir essas situações).

Observação: Os métodos onDestroy, onStop e onPause (esse último apenas antes da versão HONEYCOMB) são marcados na documentação como “killable”, ou seja, nesses estados a aplicação pode ser destruída pelo sistema sem executar nenhuma linha de código, sendo assim, use o método onPause para gravar todos os dados que devem ser persistidos, caso a aplicação seja destruída. Além disso,o método onSaveInstanceState(Bundle) é chamado antes desses casos para que alguma informação de estado (Bundle) seja guardada e possa ser resguardada usando o método onCreate(Bundle), caso a Activity retorne. É um pouco complicado, mas você vai entender mais na prática. Enquanto isso, a leitura da documentação é válida.

Code!

Pra não me xingarem dizendo que eu não trouxe nenhum exemplo de código, abaixo temos uma Activity do meu Projeto Final no curso da Udacity:

public class AboutActivity extends ActionBarActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_about);
    }

    @Override
    protected void onResume() {
        super.onResume();
    }

    @TargetApi(Build.VERSION_CODES.JELLY_BEAN)
    @Override
    public Intent getParentActivityIntent() {
        return super.getParentActivityIntent().addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
    }
}

Lidando com mudanças no tempo de execução

Durante a execução do seu App, determinadas características podem mudar, como por exemplo o idioma e a orientação da sua tela (sim, caro amigo… se você é daqueles que deixam a orientação da tela destravada e os apps ficam mudando toda hora, você não é um cara legal ‘-‘ ). Brincadeiras à parte, quando uma dessas alterações acontecem, o sistema precisa reiniciar a Activity (dentre outras coisas, isso garante que o layout XML certo será chamado de acordo com as novas configurações).

Isso acontece sendo chamado o método onDetroy e logo depois o onCreate. Para tratar adequadamente essa situação, é importante que a sua Activity restaure seu estado anterior seguindo o seu novo Ciclo de Vida normalmente. Assim o Android chama o método onSaveInstanceState() antes do onDestroy de modo que você possa salvar os dados sobre o estado da aplicação. Em seguida, podemos restaurar o estado durante o onCreate ou onRestoreInstanceState().

Isso ficará mais claro na prática e em estudos mais aprofundados, por enquanto, você pode dar uma lida na documentação para matar a curiosidade :D

Conclusão

É isso pessoal! Activities são a base de toda aplicação Android (incluindo da UI) e por isso é muito importante estar por dentro de tudo o que falamos aqui. Caso você queira expandir seus conhecimentos, recomendo ler a documentação completa sobre Activities para ter noção dos métodos que podem ser usados durante o desenvolvimento.

Espero que tenham gostado! Peço desculpas novamente pela demora e na próxima aula começamos realmente a nos aprofundar sobre a Interface de Usuário. Até a próxima e não esqueça de compartilhar com os amigos, postar no Facebook e deixar seu comentário abaixo, para fazer um #Dev feliz. :D