Conhecendo padr�es da SDK Android

Fique por dentro

Este artigo traz alguns dos padr�es que a SDK do Android traz para ajudar no desenvolvimento. Estes padr�es acabam algumas vezes sendo pouco ou subutilizados principalmente pelos desenvolvedores com pouca experi�ncia na plataforma. Os padr�es que ser�o apresentados s�o o intent, broadcast, asyntasx, loader e handler, service e adapter.

A SDK do Android traz com ela uma s�rie de soluç�es para ajudar no desenvolvimento de aplicaç�es e na otimizaç�o das aplicaç�es que j� sofrem bastante com as limitaç�es de desempenho dos smartphones atuais. Neste artigo voc� vai conhecer um pouco sobre alguns dos principais padr�es utilizados na plataforma que na sua maioria n�o s�o comuns de ver em outras plataformas como web ou desktop, mas que t�m muita import�ncia para a plataforma m�vel principalmente por causa de suas limitaç�es de recursos.

N�o poderia começar de outra forma se n�o falando sobre a classe Intent. Com certeza, a classe que gera mais d�vidas aos rec�m-chegados no desenvolvimento Android, justamente porque est� presente j� nas operaç�es mais b�sicas do sistema.

Esta classe facilita a interaç�o entre os diversos objetos que temos evitando acoplamento, quest�o que � de extrema import�ncia no desenvolvimento m�vel por conta da limitaç�o de mem�ria. Acoplamentos indesejados podem facilmente causar leaks de mem�ria.

Uma Intent � uma descriç�o de uma operaç�o a ser realizada que ser� executada pelo Android. Existem duas maneiras de escolher o componente a ser executado, pode-se explicitar utilizar o nome completo de sua classe ou utilizar uma aç�o gen�rica a ser realizada, com isso o sistema pode tomar a decis�o de quem executar� a operaç�o, ou mesmo solicitar ao usu�rio que decida. Esta aç�o gen�rica � definida atrav�s de um filtro de intent declarado no manifesto.

Um Intent pode tamb�m carregar uma s�rie de par�metros, por�m, estes par�metros devem ser serializ�veis para que caso necess�rio o Android os guarde de uma forma otimizada para posterior utilizaç�o.

Pode-se tamb�m usar flags para indicar comportamentos desejados durante transiç�es de atividades. Desta forma podemos modelar o fluxo da aplicaç�o para se adequar a suas necessidades. Existem uma s�rie de flags dispon�veis com variados efeitos e pode-se utilizar v�rias delas simultaneamente. Ao final do artigo h� um link para a documentaç�o atualizada delas.

A utilizaç�o de Intents � essencial para a comunicaç�o entre atividades e recursos do Android. � poss�vel fazer a requisiç�o de dados em Content Providers, fazer a chamada de outras aplicaç�es de forma espec�fica ou gen�rica e at� mesmo requisitar outra aplicaç�o para que abra ou execute um recurso que sua aplicaç�o n�o possui suporte, algo que � muito �til para reutilizarmos funcionalidades de outros aplicativos e ainda deixar que o usu�rio utilize suas ferramentas favoritas para o serviço.

O exemplo da Listagem 1 serve para realizar uma chamada de algum aplicativo de captura de fotos para tirar uma foto, salvar no arquivo desejado e retornar para nossa aplicaç�o. Esta integraç�o evita a escrita de um serviço para tirar fotos dentro de nossa aplicaç�o.


Intent takePictureIntent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
File f = createImageFile(smu.getId());
mCurrentPhotoPath = f.getAbsolutePath();
takePictureIntent.putExtra(MediaStore.EXTRA_OUTPUT, Uri.fromFile(f));
ctxActivity.startActivityForResult(takePictureIntent, actionCode);

Listagem 1. Chamar aplicativo de c�mera

Para fazer com que suas activities tamb�m possam ser chamadas de outras aplicaç�es, basta declarar ela como exported e adicionar filtros para facilitar sua utilizaç�o.

Nota: Nunca utilize filtros e exporte seus serviços. Isto abre uma brecha em sua aplicaç�o de forma que outro aplicativo possa interferir nos seus serviços. Al�m disso, justamente por n�o possu�rem uma interface, ser� dif�cil para que o usu�rio identifique este comportamento indesejado.

Broadcast

Este padr�o � amplamente utilizado pela SDK do Android e algumas funcionalidades dependem exclusivamente dele para que possam ser acessados. � muito semelhante ao padr�o Observer, onde voc� registra um observador para que receba eventos relacionados ao objeto ouvido.

Voc� pode utilizar este padr�o internamente para comunicar eventos que interessem � sua aplicaç�o sem a necessidade de verificaç�es constantes, ou para ouvir eventos lançados por outras aplicaç�es ou pelo pr�prio sistema Android.

Existe uma variedade muito grande de Broadcasts que constantemente s�o lançados pelo sistema, cobrindo uma variedade de eventos que acontecem no dispositivo. Entre eles est�o eventos de conex�o com rede, captura de coordenada, SMS recebida entre muitas outras. A lista completa pode ser encontrada dentro do c�digo-fonte da SDK e pode variar (geralmente de modo incremental) entre vers�es da SDK.

Como mencionado, temos dois lados para a utilizaç�o deste padr�o, a parte ativa, que lança o broadcast, e a parte que recebe o broadcast. Para receber um broadcast, inicialmente � necess�rio uma classe que estenda da classe BroadcastReceiver e associe ela ao broadcast que se queira receber. Observe que isto � din�mico, no momento que n�o mais for necess�rio o recebimento destes broadcasts deve-se desatrelar este objeto (enquanto atrelado, o objeto dever� receber todos os eventos relacionados).

Junto com o broadcast enviado � comum se enviar uma s�rie de dados associados a ele, sejam eles relacionados ao evento ocorrido ou ao estado atual que ele possa ter causado. Desta forma, facilita-se o acesso a informaç�es relacionadas e cria-se um evento consistente e independente. Os dados chegam como parte de um Intent. As Listagens 2 e 3 trazem um trecho com a implementaç�o de recebimento do broadcast para avisar quando se est� iniciando o sistema.

public class BootReceiver extends BroadcastReceiver {
  @Override
  public void onReceive(Context context, Intent intent) {
  //Realiza a operaç�o desejada ao receber o broadcast.
  }
}

Listagem 2. Broadcast Receiver

<receiver
 android:name=".receiver.BootReceiver"
 android:enabled="false"
 android:permission="android.permission.RECEIVE_BOOT_COMPLETED" >
   <intent-filter>
     <action android:name="android.intent.action.BOOT_COMPLETED" >
     </action>
   </intent-filter>
</receiver>

Listagem 3. Android XML

Mas como j� mencionado, tamb�m podemos enviar nossos pr�prios broadcasts para interagir com nossa pr�pria aplicaç�o ou at� mesmo com outras aplicaç�es que possam estar interessadas com algo que nossa aplicaç�o pode fornecer.

O envio do broadcast � ainda mais simples, deve-se utilizar um nome �nico para seu broadcast, junto com o nome do pacote de sua aplicaç�o e a partir da� apenas uma chamada a sendBroadcast() passando o Intent com a definiç�o do broadcast. O recebimento do broadcast segue exatamente o mesmo exemplo j� mencionado (veja a Listagem 4).

Intent i = new Intent("your.package.YOUR_ACTION");
sendBroadcast(i);

Listagem 4. Envio de Broadcast

AsyncTask

Sua finalidade � facilitar a interaç�o entre threads com a manipulaç�o de layout e feedback para usu�rio. Projetada de forma simplista, ela n�o prev� eventos externos como o ciclo de vida da Activity.

Ela n�o possui um limite relacionado a tempo de execuç�o, por�m como tem a finalidade de trazer um retorno para a thread principal (de layout), seu ciclo de vida passa a estar fortemente ligado � Activity que a criou, por isso � muito importante realizar verificaç�es no momento de realizar as operaç�es no layout (durante o m�todo onPostExecute()), pois este pode n�o estar mais dispon�vel. O mesmo vale para o feedback de progresso onProgressUpdate().

Pode-se facilmente reproduzir sua funcionalidade utilizando outros elementos, mas sua grande vantagem est� justamente na simplicidade de sua implementaç�o. Possuindo uma interface simples e v�rios callbacks relevantes, fica f�cil criar uma soluç�o para uma operaç�o com tempo de execuç�o incerto que seria invi�vel de se rodar na thread principal para que a capacidade de resposta e interaç�es n�o sejam comprometidas. Sua interface � tamb�m gen�rica, o que deixa pass�vel adaptaç�o para quase qualquer soluç�o atrav�s da adequaç�o de par�metros.

A partir da vers�o 3.0 do Android, todas as AsyncTasks passam a fazer uso de uma mesma thread em background, conhecida como worker. Desta forma, todas as AsyncTask ir�o rodar seu m�todo doInBackground() serialmente, o que deixa ainda mais claro sua finalidade de rodar serviços curtos em segundo plano e disponibilizar o mais brevemente poss�vel ao usu�rio. Veja o c�digo da Listagem 5.

AsyncTask<Void, Integer, String> task = new AsyncTask<Void, Integer, String>() {
 @Override
 protected void onPreExecute() {
  //Executado na thread principal antes de iniciar processo em background.
 }

 @Override
 protected String doInBackground(Void... params) {
   //Executado em background.
   setProgress(0);
   return "";
 }

 @Override
 protected void onProgressUpdate(Integer... values) {
   //Executado na thread principal durante o processo em background, 
   // para que possa retornar feedback para usuario 
   // de como est� o progresso.
 }

 @Override
 protected void onCancelled(String result) {
   //Executado na thread principal caso seja chamado AsyncTask.cancel().
 }

 @Override
 protected void onPostExecute(String result) {
   //Executado na thread principal ap�s doInBackground() completar.
 }
};
task.execute();

Listagem 5. Implementaç�o AsyncTask

Observe que a implementaç�o faz uso de conceitos provenientes do Java com seus tr�s par�metros gen�ricos que s�o obrigat�rios e devem ser explicitados na implementaç�o.

Loader

Os Loaders e sua principal implementaç�o CursorLoader foram introduzidos na plataforma para melhorar a utilizaç�o de operaç�es relacionadas a banco de dados. Eles j� v�m preparados para o ciclo de vida da Activity e para entregar dados sempre atualizados, por�m, depende de uma implementaç�o de um Content Provider sobre o banco de dados. Todas as interfaces que d�o acesso direto a informaç�es que o Android disponibiliza v�m com a implementaç�o de Content Provider.

A n�o exist�ncia de um Content Provider n�o inviabiliza completamente a utilizaç�o de Loaders para se carregar dados de um banco. Para isso existe a implementaç�o AsyncTaskLoader que estende da Loader e traz v�rias de suas vantagens para uma implementaç�o mais pr�xima do AsyncTask, por�m, exige novamente um pouco mais de atenç�o especialmente quanto a atualizaç�o dos dados.

Diferentemente de uma AsyncTask onde voc� implementa a classe e realiza a operaç�o em seus m�todos, em um Loader voc� atrela a um LoadManager que � disponibilizado em fragments ou activities atrav�s do m�todo getLoaderManager() e implementa uma interface de callback chamada LoaderCallbacks, onde ser�o recebidos eventos relacionados para se atualizar os dados apenas nos momentos necess�rios. Para inicializar a loader voc� utiliza o m�todo initLoader() do LoaderManager, normalmente no m�todo onCreate() da Activity ou onActivityCreated() do Fragment.

Handler e Looper

Em uma abstraç�o bem simples, podemos comparar esse padr�o com uma fila onde voc� adiciona as tarefas que ser�o executadas, as tarefas s�o executadas uma a uma serialmente sem concorr�ncia entre si. A fila � executada completamente em cada ciclo do processo, por isso uma tarefa maior, sendo executada desta forma interfere no momento de in�cio das pr�ximas tarefas.

Este padr�o j� vem pr�-implementado no Android pelas classes Activity, Fragment e Service, sendo as tarefas executadas na thread principal (a mesma do layout), o que torna de grande utilidade para a manipulaç�o de objetos que interferem no layout, mesmo sendo estas tarefas disparadas de threads diferentes. Entretanto, � muito importante tomar cuidado com tarefas pesadas ao utiliz�-las na Activity, pois o ciclo faz parte de toda a construç�o do layout, uma tarefa mais pesada pode comprometer o tempo de resposta de sua interface.

A especializaç�o de threads e serviços pode encontrar aqui uma importante vantagem: podemos ter threads especializadas para certo aspecto da aplicaç�o. Desta forma, podemos controlar precisamente sua prioridade quando ela est� rodando e como ela vai interferir no restante do sistema, sem gerar uma grande complexidade.

Para rodar um objeto Runnable atrav�s de um Handler � preciso apenas utilizar o m�todo post() ou postDelayed() caso queria que seja chamado em um tempo futuro.

No exemplo da Listagem 6 preparamos a thread para que possa rodar o looper. Em seguida criamos um objeto Handler com a implementaç�o do m�todo para recebimento de mensagens e em seguida iniciamos de fato o loop.


Looper.prepare();
  mHandler = new Handler() {
    public void handleMessage(Message msg) {
      System.out.println(msg.obj);
    }
  };

Listagem 6. Looper e Handler

Looper.loop();

O m�todo loop() da classe Looper � um m�todo locker, no momento que ele for chamado esta thread ficar� nela por tempo indefinido e resolver� as chamadas de serviços Handler.

O m�todo handleMessage() do Handler ser� chamado mesmo que o m�todo loop() do Looper ainda n�o tenha sido executado, por�m os objetos Runnable passados por post atrav�s de um Handler s� ser�o executados enquanto a thread estiver executando o m�todo loop().

Em qualquer momento voc� pode parar o loop atrav�s dos m�todos quitSafely() e quit() do pr�prio objeto Looper e que tamb�m podem ser acessados por qualquer Handler atrelados a este loop atrav�s do m�todo getLooper().

Com o c�digo apresentado na Listagem 7 voc� pode criar uma classe que executa funç�es em segundo plano para alguma operaç�o de sua aplicaç�o. Com esta implementaç�o temos uma vantagem muito interessante que � o fato de suas operaç�es rodarem serialmente.


//1. Atrav�s de mensagens 
  Message msg = Message.obtain();
  msg.obj = //obj
  mHandler.dispatchMessage(msg);
   
//2. Atrav�s de Runnable
  mHandler.post(new Runnable() {
    @Override
    public void run() {
      //operaç�o
    }
  });

Listagem 7. Chamada Handler

Service

Service � uma classe que pode rodar operaç�es por um longo per�odo em background, n�o possui uma interface gr�fica e pode realizar comunicaç�o entre threads e processos atrav�s de bind. A maior diferença de um Service para um Thread criada em uma Activity � justamente o fato dela rodar em background, pois uma Thread iniciada em uma Activity deve sempre ser parada ao sair desta Activity, caso contr�rio podem ocorrer comportamentos inesperados.

Um serviço apenas ser� interrompido no momento em que uma Activity em foco precisar de mais mem�ria do que a dispon�vel no momento, dando-se prioridade para manter serviços atrelados a Activity em foco e serviços declarados como foreground. Por�m, caso seja declarado como �sticky�, ele voltar� a ser executado assim que houver mem�ria dispon�vel.

Por padr�o, um Service vai rodar na mesma thread que � utilizada para as operaç�es de layout. Desta forma, operaç�es pesadas podem afetar suas activities. � importante que voc� utilize outras threads para rodar operaç�es mais pesadas, mas coordene elas atrav�s de seu Service. Assim voc� utiliza o ciclo de vida do Service e n�o afeta diretamente suas activities.

Temos tamb�m uma implementaç�o pronta da classe Service chamada IntentService que traz um comportamento um pouco diferente, ela automaticamente repassa todas as chamadas de startService() para um m�todo chamado onHandleIntent() com a intent recebida e na thread worker. Desta forma, os serviços s�o executados serialmente, evitando problemas com paralelismo e em segundo plano, muito semelhante ao que acontece com a AsyncTask, s� que desatrelado da Activity (veja a Listagem 8).


public class OlaIntentService extends IntentService {
  public OlaIntentService() {
    super("OlaIntentService");
  }
 
  @Override
  protected void onHandleIntent(Intent intent) {
    // Serviço realizado em background pela thread worker.
  }
}

Listagem 8. IntentService

Temos tamb�m como definir um serviço de �foreground�, o que significa que este serviço � de uma operaç�o extremamente importante para o usu�rio neste momento. Este tipo de serviço requer obrigatoriamente uma notificaç�o ativa na barra de status, de modo que se a notificaç�o for cancelada, o serviço tamb�m ser� cancelado. Exemplos desse tipo de serviço s�o players de m�sica e um download em andamento. Para iniciar um serviço em foreground, voc� deve iniciar o serviço com o m�todo startForeground(). Para remov�-lo de foreground utilize stopForeground() (continuar� como um serviço normal). Observe o c�digo da Listagem 9.


Notification notification = new Notification(R.drawable.icon, getText(R.string.texto), 
System.currentTimeMillis());
Intent notificationIntent = new Intent(this, ExampleActivity.class);
PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, notificationIntent, 123);
notification.setLatestEventInfo(this, getText(R.string.title),
getText(R.string.message), pendingIntent);
startForeground(NOTIFICATION_ID, notification);

Listagem 9. Foreground Service

Dentre os tipos de serviço que podem ser utilizados, destaco:

IntentServices para serviços com um ciclo de vida bem definido e que podem rodar serialmente;
A classe Service diretamente quando for para um serviço de tempo indeterminado e que precise estar constantemente rodando em segundo plano;
Um serviço com Bind para situaç�es em que precisar fornecer interfaces de seu serviço para outros aplicativos;
Um serviço foreground quando este for essencial para seu usu�rio durante sua execuç�o.

Adapter

Este � mais um padr�o que serve para ajudar a contornar as limitaç�es dos devices. A implementaç�o dele trabalha para manter a baixa utilizaç�o de mem�ria e evitar ao m�ximo poss�vel a criaç�o de objetos de tela.

A SDK j� traz consigo uma s�rie de classes que implementam este padr�o de forma que sua utilizaç�o seja facilitada. Para situaç�es mais simples e comuns voc� j� encontrar� classes totalmente implementadas e prontas para uso (SimpleAdapter, SimpleCursorAdapter, ArrayAdapter), j� em casos um pouco mais complexos voc� encontra alguma implementaç�o parcial como, por exemplo, para percorrer listas diretamente do banco (CursorAdapter), para casos n�o previstos voc� ter� que fazer sua pr�pria implementaç�o partindo da BaseAdapter.

Adapter � um padr�o que se encaixa muito bem com diversos outros padr�es para possibilitar uma usabilidade ainda mais flu�da. Por exemplo, ele pode ser utilizado em conjunto com Holders e Tags para facilitar no reaproveitamento das views. J� a utilizaç�o de LruCache para a manipulaç�o de objetos mais pesados como imagens pode ser algo muito importante, principalmente em smartphones com um menor poder de processamento.

Esta s�rie de padr�es pode ajudar muito no desenvolvimento de seus aplicativos e na performance de sua aplicaç�o. Vale lembrar que estes n�o s�o os �nicos padr�es prontos para utilizaç�o na plataforma, existem muitos outros que voc� deve explorar para se beneficiar ao m�ximo desta plataforma de desenvolvimento.

Links:

Confira tamb�m

Meu primeiro aplicativo Android

Curso

Preparando o ambiente