ANR Android: Evitando o Application Not Responding com tarefas paralelas

Fique por dentro

Saber trabalhar com tarefas em paralelo na plataforma Android � essencial. Este artigo ser� �til no entendimento em relaç�o � forma como tarefas paralelas devem ser executadas em uma aplicaç�o Android a fim de evitar os erros conhecidos como ANR (Application Not Responding). Para exemplificar, ser� desenvolvida uma aplicaç�o de consumo de feeds, a qual far� o download das mesmas a partir de um web service.

As aplicaç�es para smartphones geralmente necessitam buscar recursos de fontes externas para realizar determinadas tarefas ou dar acesso ao usu�rio a algum conte�do pertinente do escopo do aplicativo. Por se tratar de programaç�o sequencial conforme mostra a Figura 1, quando a tarefa a ser realizada � custosa em relaç�o ao tempo a ser gasto para realiz�-la e o processamento desses recursos ocorre na UIThread conforme mostra a Figura 2, a aplicaç�o � travada at� que a instruç�o seja conclu�da. Por causa desse travamento, o sistema operacional fecha a aplicaç�o evidenciando uma ANR (Application Not Responding), pois por restriç�o do pr�prio sistema operacional, nesse caso Android, o aplicativo n�o deve ficar mais do que cinco segundos indispon�vel �s interaç�es do usu�rio.

Para que tal erro n�o ocorra, � necess�rio utilizar formas de processamento em paralelo como Threads e tomar o cuidado de evitar a comunicaç�o direta entre qualquer Thread que n�o seja a principal com a interface do usu�rio (UI).

Al�m de evitar o travamento pela indisponibilidade da aplicaç�o em responder �s interaç�es do usu�rio, a programaç�o em paralelo, de forma geral, tamb�m pode melhorar o desempenho da aplicaç�o atrav�s da divis�o a tarefa em partes menores a fim de tornar mais r�pida a soluç�o do problema.

Como ponto negativo, programar em paralelo � muitas vezes mais complicado al�m de trazer para o escopo novos problemas que n�o ocorrem na programaç�o sequencial como a possibilidade de um m�todo ser executado sem que ainda possua os valores corretos, os quais ser�o calculados em outro m�todo.

Figura 1. Programaç�o sequencial

Figura 2. Tarefas na UIThread

Contudo, com o objetivo de fornecer ao usu�rio uma melhor experi�ncia de uso, as instruç�es mais complexas e/ou demoradas da aplicaç�o como, por exemplo, as requisiç�es para serviços web, o acesso a um banco de dados ou arquivo, devem ser realizadas de forma concorrente para que a aplicaç�o n�o fique indispon�vel.

Utilizando Thread

Thread � a forma de um processo se dividir sozinho em duas ou mais tarefas que podem ser executadas ao mesmo tempo de forma concorrente com seu estado variando entre: unstarted, running, suspended e stopped.

A vantagem de se utilizar Thread na aplicaç�o � poder executar mais de uma tarefa ao mesmo tempo, evitando que a aplicaç�o trave � espera de um processo demorado. No caso do sistema Android, essa demora, como j� citado anteriormente, ir� causar a finalizaç�o autom�tica da aplicaç�o enviando um erro ANR. Para executar tanto uma Thread quanto um Runnable, � necess�rio instanciar um objeto. No caso da classe Thread, para iniciar a execuç�o, basta chamar o m�todo start(), enquanto para a interface Runnable, o m�todo run().

O sistema Android oferece o suporte para a utilizaç�o da classe Thread em Java para a realizaç�o de tarefas ass�ncronas, assim como do pacote java.util.concurrent para realizaç�o de tarefas em background. Contudo, o desenvolvedor deve ter certo cuidado ao utilizar uma classe que herde diretamente da classe Thread ou implemente a interface Runnable. Isso porque as mesmas n�o oferecem um recurso padr�o para tratar as mudanças de configuraç�o da aplicaç�o como, por exemplo, a mudança do modo de orientaç�o de retrato para paisagem ou vice-versa. A utilizaç�o da classe Thread tamb�m n�o oferece um recurso padr�o para sincronizaç�o com a main thread (UIThread) em casos nos quais � necess�rio retornar um resultado. Al�m de todas essas implicaç�es, a inexist�ncia de um processo padr�o para cancelamento da classe Thread faz com que a aplicaç�o mantenha a classe executando at� que esta termine mesmo que j� n�o seja necess�rio que todo o processo nela seja executado.

Utilizando Handler

Para solucionar as limitaç�es e suprir as desvantagens geradas para utilizaç�o da classe Thread em Java no pr�prio sistema, o Google desenvolveu a classe Handler, a qual est� dispon�vel desde a API level 1. Ela permite enviar e processar objetos da classe Message e da interface Runnable que est�o associados a uma fila de mensagens/processos implementada pela classe MessageQueue.

A principal dificuldade encontrada pelos desenvolvedores ao criar processos em uma classe Thread ou Runnable � encontrar formas de enviar dados necess�rios entre as Threads. Para solucionar esse problema, um objeto da classe Handler oferece um canal �nico de comunicaç�o com a Thread na qual o mesmo � instanciado. Outro ponto positivo da classe Handler � a possibilidade de reutilizar o objeto da classe Handler j� existente em uma Activity e evitar assim que muitas inst�ncias sejam criadas.

Apesar de n�o possuir uma forma de implementaç�o t�o intuitiva, a classe Handler � comumente utilizada em casos no qual � necess�rio agendar a execuç�o de objetos da classe Message ou Runnable. Outro caso no qual a classe Handler � utilizada � quando existe a necessidade de adicionar uma aç�o a uma fila de execuç�o que n�o � a mesma da classe Handler. Para utiliz�-la, � necess�rio criar uma classe que herde de Handler e que sobrescreva o m�todo handleMessage(). Caso seja necess�rio agendar a execuç�o de alguma tarefa para ser executada posteriormente, � poss�vel fazer isso atrav�s de diversos m�todos como post(), postDelayed(), sendMessage(), etc.

Utilizando AsyncTask

A fim de facilitar e possibilitar a utilizaç�o da UI Thread a partir de um processo em background, a classe AsyncTask foi disponibilizada a partir da API level 3. Com ela � poss�vel processar, a partir do encapsulamento da criaç�o e da sincronizaç�o com a UI Thread, as operaç�es em background e retornar o resultado para a UI Thread sem a necessidade de manipular Threads e/ou Handlers. A classe AsyncTask � definida a partir de tr�s par�metros gen�ricos Params, Progress e Result, e quatro m�todos onPreExecute(), doInBackground(), onProgressUpdate() e onPostResult().

A classe AsyncTask foi projetada para facilitar o desenvolvimento de tarefas simples (com duraç�o de poucos segundos, no m�ximo) processadas em background. Al�m disso, ela possibilita informar o progresso da tarefa que est� sendo executada e enviar o resultado obtido, quando existir, para a UI Thread de forma simples.

Contudo, assim como a Thread em Java, a AsyncTask n�o possui um m�todo padr�o para lidar automaticamente com alteraç�es na aplicaç�o como a mudança de orientaç�o retrato para paisagem e vice-versa. Ou seja, caso a Activity na qual a AsyncTask est� associada seja recriada, o desenvolvedor deve lidar com essa condiç�o de forma manual. Uma soluç�o comum � utilizar a AsyncTask associada a um Fragment que possua o m�todo para que seu estado atual seja mantido mesmo com alteraç�es de orientaç�o.

Para utilizar a classe AsyncTask, � necess�rio criar uma classe que herde de AsyncTask. A subclasse deve definir tr�s par�metros (Params, Progress e Result), respectivamente, onde Params corresponde ao tipo de dado que ser� passado como par�metro ao m�todo doInBackground(), Progress corresponde ao tipo de dado que ser� enviado � UI Thread informando o progresso da tarefa e Result � o tipo de dado que ser� retornado do m�todo doInBackground() para o m�todo onPostExecute(). Desses m�todos, o que dever� ser sobrescrito da classe pai � o m�todo doInBackground(), o qual � respons�vel por realizar a tarefa em paralelo a UI Thread. No caso de existir a necessidade da tarefa retornar um resultado para a UI Thread, a subclasse dever� sobrescrever o m�todo onPostExecute() da classe pai. � comum enviar tamb�m para a UI Thread o progresso da tarefa e este pode ser feito atrav�s do m�todo onProgressUpdate(), o qual dever� ser sobrescrito.

Utilizando Loader

Mais recentemente, a partir da API level 11, foi introduzida a classe Loader. Ela permite realizar a leitura ass�ncrona de dados em uma Activity ou Fragmente de forma simples, monitorar o reposit�rio de dados enviando os novos conte�dos assim que o reposit�rio � alterado. A classe Loader tamb�m permite que os dados carregados n�o sejam perdidos com qualquer alteraç�o na configuraç�o da aplicaç�o e que seja acess�vel a qualquer Activity ou Fragment da aplicaç�o.

Import�ncia do feedback em tempo de execuç�o ao usu�rio

Quando duas ou mais pessoas interagem entre si, elas podem se entender atrav�s de um feedback que uma envia a outra. A relaç�o usu�rio-aplicativo, apesar de predominantemente unilateral, ocorre de forma semelhante: o usu�rio interage com algum elemento da aplicaç�o e para que o mesmo entenda que a aplicaç�o recebeu o est�mulo e ir� responder a ele, mas que ainda n�o possui os valores necess�rios para gerar a resposta, o desenvolvedor deve criar formas de enviar um feedback ao usu�rio atrav�s da aplicaç�o.

A opç�o mais comum de enviar um feedback ao usu�rio � atrav�s de uma Dialog. Esta opç�o consiste em mostrar ao usu�rio uma janela com uma barra de progresso, uma mensagem ou ambos informando que uma tarefa est� sendo executada.

Al�m de ser a forma mais comum, a utilizaç�o de uma Dialog para enviar o feedback ao usu�rio � �til em casos onde h� a necessidade de evitar a interaç�o do usu�rio com qualquer outro componente dispon�vel na tela sem que se trave ela.

No entanto, por travar a navegaç�o do usu�rio, o feedback atrav�s de uma Dialog deve ser utilizado de forma consciente. � poss�vel habilitar a possibilidade do usu�rio remover a Dialog atrav�s do toque no bot�o voltar do sistema operacional ou atrav�s do toque na �rea externa ao Dialog. Ambos os casos removem o feedback enviado ao usu�rio mesmo que a tarefa em background continue sendo executada.

A outra opç�o � enviar o feedback como uma inner view, ou seja, inflando o componente com o feedback em um componente j� existente no layout da aplicaç�o. Assim como no feedback via Dialog, o componente pode se resumir a uma barra de progress�o e/ou uma mensagem informando ao usu�rio da exist�ncia de uma tarefa sendo processada em background sem que se trave a navegaç�o do mesmo.

A vantagem de se utilizar o feedback atrav�s de uma inner view � possibilitar ao usu�rio a livre navegaç�o mesmo que uma tarefa esteja rodando em background. Contudo, � necess�rio que o desenvolvedor crie formas de evitar que o usu�rio acesse �reas da aplicaç�o que necessitem do resultado obtido pela tarefa executada em background. Caso contr�rio, a interaç�o poder� resultar em uma exceç�o, sendo nesse caso o NullPointerException mais comumente obtido.

Explicando o web service

Para exemplificar o conceito dos componentes respons�veis pela execuç�o de tarefas em background, ser� desenvolvida uma aplicaç�o chamada Example. A aplicaç�o ir� consistir em uma �nica tela na qual ser� carregado uma lista de coment�rios. Estes coment�rios ser�o armazenados no servidor externo e carregados a partir de uma requisiç�o feita ao web service. Tamb�m ser� poss�vel gravar novos coment�rios enviando para o servidor externo o conte�do inserido pelo usu�rio em um EditText. Todas as requisiç�es dever�o ser feitas definindo o tipo dos par�metros como POST.

O web service est� implementado com duas funcionalidades b�sicas: get() e post() e as duas realizam consultas em uma �nica tabela denominada FEED. Esta tabela possui quatro colunas: id, username, comment e log_date conforme mostra a Figura 3.

Figura 3. Colunas da tabela FEED

Quando a aplicaç�o necessitar buscar os coment�rios no banco de dados externo, ela ter� que realizar uma requisiç�o passando como o par�metro action o valor get. Nesta requisiç�o, tamb�m ser� necess�rio enviar os par�metros page e limit como pode ser visto na Listagem 1.


switch($_POST[''action'']) {
  case get:
     $page = $_POST[''page''];
     $limit = $_POST[''limit''];
       
     $feed = new Feed();
     $feed->get($page, $limit);
     break;
...

Listagem 1. Requisiç�o ao m�todo get()

E quando a aplicaç�o necessitar gravar um novo coment�rio no banco de dados externo, ela ter� que realizar uma requisiç�o passando como o par�metro action o valor post. Nesta requisiç�o, tamb�m ser� necess�rio enviar os par�metros username, comment e log_date como pode ser visto na Listagem 2.


switch($_POST[''action'']) {
  ... 
  case post:
   $username = $_POST[''username''];
   $comment = $_POST[''comment''];
   $log_date = $_POST[''log_date''];
       
   $feed = new Feed();
   $feed->post($username, $comment, $log_date);
   break;
}

Listagem 2. Requisiç�o ao m�todo post()

Criando a aplicaç�o

Para começar, ser� criada a aplicaç�o atrav�s do wizard do Android Studio. A aplicaç�o ter� como pacote br.com.example.concurrence e a Activity principal ser� chamada MainActivity e esta far� refer�ncia ao layout activity_main.xml conforme mostra a Figura 4.

Figura 4. Interface Android Studio ap�s criaç�o da aplicaç�o Example

Nota: A aplicaç�o foi desenvolvida utilizando a IDE Android Studio. Caso o leitor esteja mais familiarizado com o Eclipse e preferir utiliz�-lo, ao inv�s do Android Studio, n�o haver� qualquer perda de conte�do ou funcionalidade.

Para exemplificar de forma adequada a utilizaç�o da classe AsyncTask, a aplicaç�o ir� realizar requisiç�es para um serviço externo. Para que o sistema n�o bloqueie as requisiç�es, � necess�rio adicionar a permiss�o de acesso � internet no manifest da aplicaç�o. Contudo, a aplicaç�o poder� fazer uma requisiç�o no momento no qual a conex�o com a internet n�o est� dispon�vel, ent�o � necess�rio verificar se a conex�o com a internet est� ativa ou n�o. Para realizar a verificaç�o da conex�o, tamb�m � obrigat�rio adicionar a permiss�o de leitura do estado da rede do dispositivo ao manifest da aplicaç�o como pode ser visto no c�digo:

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"></uses-permission>
<uses-permission android:name="android.permission.INTERNET"></uses-permission>

Com as permiss�es adicionadas ao manifest da aplicaç�o, ser� poss�vel realizar as requisiç�es nos serviços externos e verificar a disponibilidade de conex�o com a internet do dispositivo a fim de evitar erros de indisponibilidade de rede como pode ser visto na Listagem 3. Nas aplicaç�es que consomem muitos dados de serviços externos, � prefer�vel desconsiderar a possibilidade de uso da rede 3G para evitar consumo e cobranças desnecess�rias ao usu�rio.


public NetworkState isOnline(Context context) {
  try { 
    ConnectivityManager connManager = (ConnectivityManager) 
    context.getSystemService(Context.CONNECTIVITY_SERVICE);
    NetworkInfo mWifi = connManager.getNetworkInfo(ConnectivityManager.TYPE_WIFI);
    NetworkInfo m3G = connManager.getNetworkInfo(ConnectivityManager.TYPE_MOBILE);
    if (mWifi.isConnected())
    return NetworkState.WiFi;
    else if (m3G.isConnected())
    return NetworkState.GGG;
  } catch (Exception e) {
  }
  return NetworkState.None;
}

Listagem 3. M�todo de verificaç�o da disponibilidade de conex�o com a internet

O m�todo isOnline() ser� utilizado sempre que uma requisiç�o precisar ser executada. O m�todo ir� retornar um valor enum de NetworkState que ir� variar entre WiFi, None e GGG.

Nas permiss�es do manifest, o desenvolvedor poder� adicionar a permiss�o para verificar a disponibilidade apenas da conex�o Wifi ao inv�s da conex�o com a internet em geral alterando o android.permission.ACCESS_NETWORK_STATE por android.permission.ACCESS_WIFI_STATE. � �til, no entanto, tratar o poss�vel tr�fego intenso de dados como invi�vel no caso da disponibilidade �nica da conex�o 3G.

Nota: O valor referente � conex�o 3G em NetworkState foi atribu�da como GGG porque em Java n�o � poss�vel declarar vari�veis que comecem com numeral.

Antes de dar in�cio ao processo que ser� executado em paralelo e sincronizar o resultado obtido com a UI Thread, � importante padronizar a forma de enviar ao usu�rio o feedback da atividade. Para isso, ser� implementado uma interface na classe Request com os m�todos de padronizaç�o das requisiç�es como pode ser visto na Listagem 4.

public interface Callback {
  public void onStart(Class<?> executingClass);
  public void onSuccess(Class<?> executingClass, Object result);
  public void onError(Class<?> executingClass, String errorMessage);
  public void onCancel(Class<?> executingClass);
}

Listagem 4. Interface de padronizaç�o dos m�todos das requisiç�es

A interface ter� definido quatro m�todos de sincronizaç�o com a UI Thread. Para enviar um feedback de que uma task est� sendo executada, o m�todo onStart() da inst�ncia da interface na subclasse de AsyncTask dever� ser chamado no m�todo onPreExecute(). No caso da tarefa ser cancelada, seja pelo usu�rio ou pela pr�pria aplicaç�o, o m�todo onCancel() da inst�ncia da interface dever� ser executado. Caso ocorra algum erro na requisiç�o, ou a requisiç�o seja realizada com sucesso, os m�todos a serem chamados devem ser onError() ou onSuccess(), respectivamente. O melhor momento para realizar a sincronizaç�o com a UI Thread atrav�s dos tr�s �ltimos m�todos declarados da interface Callback � no m�todo onPostExecute() da subclasse de AsyncTask.

O tipo dos par�metros das requisiç�es ir� variar de acordo com o web service. Para esse exemplo, o web service aceitar� apenas par�metros passados como POST. Em Android, para realizar uma requisiç�o HTTP, � necess�rio criar um objeto de HttpClient. Como o web service ir� ler apenas par�metros passados via POST, ser� necess�rio criar um objeto de HttpPost e adicionar o mapa de par�metros e valores nele como pode ser visto na Listagem 5.


{...
  HttpPost httpPost;
  HttpContext localContext = new BasicHttpContext();
  HttpParams httpParams = new BasicHttpParams();
  HttpConnectionParams.setConnectionTimeout(httpParams, 15000);
  HttpConnectionParams.setSoTimeout(httpParams, 15000);
   
  HttpClient httpClient = new DefaultHttpClient(httpParams);
   
  List<NameValuePair> nameValuePairs = new ArrayList<NameValuePair>();
  if (params != null) {
    for (String key : params.keySet()) {
      nameValuePairs.add(new BasicNameValuePair(key, String.valueOf(params.get(key))));
    }
  }
   
  httpPost = new HttpPost(url.replaceAll("\\s", "_"));
  httpPost.addHeader("Accept-Encoding", "gzip");
  httpPost.setHeader("Content-Type",
  "application/x-www-form-urlencoded;charset=UTF-8");
  httpPost.setEntity(new UrlEncodedFormEntity(nameValuePairs, "UTF-8"));
...}

Listagem 5. Criaç�o e configuraç�o do objeto para requisiç�o

Ap�s definir os objetos HttpClient e HttpPost, ser� obtida uma resposta a partir da execuç�o da requisiç�o feita pelo objeto de HttpClient. Essa resposta ser� lida por um objeto de BufferedReader e o conte�do ser� armazenado em um objeto de StringBuilder. Ap�s terminar a leitura, o objeto de BufferedReader � fechado e o m�todo retornar� um JSONObject, o qual ser� criado a partir do conte�do armazenado no objeto de StringBuilder como pode ser visto na Listagem 6.


{...
  HttpResponse response = httpClient.execute(httpPost, localContext);
  Header contentEncoding = response.getFirstHeader("Content-Encoding");
   
  InputStream instream = response.getEntity().getContent();
   
  if (contentEncoding != null && contentEncoding.getValue().equalsIgnoreCase("gzip")) {
    instream = new GZIPInputStream(instream);
  }
   
  BufferedReader reader = new BufferedReader(new InputStreamReader(instream, "UTF-8"), 
  BUFFER_SIZE_8K);
  StringBuilder json = new StringBuilder();
  String line = reader.readLine();
   
  while (line != null) {
    json.append(line);
    line = reader.readLine();
  }
  reader.close();
  return new JSONObject(json.toString());
  }

Listagem 6. Leitura do conte�do obtido a partir da requisiç�o ao web service

O m�todo post() da classe Request repassa diversas exceç�es para o m�todo de chamada. Algumas delas: UnsupportedEncodingException, ClientProtocolException, IOException, JSONException, SocketTimeoutException, IllegalStateException, NullPointerException. � importante lembrar de adicionar as permiss�es de acesso � internet e da leitura de conectividade mencionadas anteriormente ao AndroidManifest.xml.

Criando as classes para montagem das requisiç�es ao web service

Para facilitar a construç�o e manutenç�o das URLs e tamb�m dos par�metros a serem indexados, � �til criar uma classe para realizar a construç�o dessas URLs como pode ser visto na Listagem 7 e do mapa dos par�metros como pode ser visto na Listagem 8, este �ltimo servindo para o caso das requisiç�es serem feitas a partir de par�metros POST.


public class URLBuilder {
   
  private final String HOST = "https://www.limaogames.com.br/articles/example/methods.php";
   
  public String buildHostUrl() {
  return HOST;
}

Listagem 7. Corpo da classe URLBuilder

Para utilizar a classe URLBuilder, basta criar uma inst�ncia de URLBuilder e executar o m�todo buildHostUrl(), o qual ir� retornar a constante que representa o endereço no qual o serviço a ser consumido est� hospedado. Com a criaç�o de uma classe que sirva como construtor das URLs a serem consumidas, o desenvolvedor poder� agrupar a criaç�o das URLs em um �nico local facilitando a manutenç�o dos mesmos.


public class ParamBuilder {
   
  private final String ACTION = "action";
  private final String GET = "get";
  private final String POST = "post";
  private final String COMMENT = "comment";
  private final String LIMIT = "limit";
  private final String LOG_DATE = "log_date";
  private final String USERNAME = "username";
       
  public HashMap<String, Object> buildGetParams(int limit) {
    HashMap<String, Object> map = new HashMap<String, Object>();
    map.put(ACTION, GET);
    map.put(LIMIT, limit);
    return map;
  }
   
  public HashMap<String, Object> buildPostParams(String username, long logDate, String comment) {
    HashMap<String, Object> map = new HashMap<String, Object>();
    map.put(ACTION, POST);
    map.put(USERNAME, username);
    map.put(LOG_DATE, logDate);
    map.put(COMMENT, comment);
    return map;
  }
}

Listagem 8. Corpo da classe ParamBuilder

Para utilizar a classe ParamBuilder, basta criar uma inst�ncia de ParamBuilder e executar o m�todo desejado passando os par�metros necess�rios. Por definiç�o do web service, os valores devem ser passados como POST a fim de aumentar a segurança dos dados atrav�s da chamada de dois m�todos, get() e post(). O m�todo get(), ao ser chamado, deve receber como par�metro um inteiro com o valor do limite de feeds a serem carregados. O m�todo post() deve receber como par�metros o nome do usu�rio como uma String, o instante em milissegundos da chamada do m�todo como um long e o coment�rio como uma String, respectivamente.

Para o m�todo get(), � importante que o desenvolvedor fique atento com o limite de n�s a serem carregados. Para retornos com muitos n�s, um limite muito alto de itens carregados pode acarretar um TimeoutException pelo excesso de dados carregados.

Criando o modelo Comment

Para montar a lista de feeds que ser� utilizada na aplicaç�o, ser� constru�do um modelo chamado Comment, o qual ter� como finalidade armazenar as informaç�es resultantes da requisiç�o. As vari�veis, por padr�o, ser�o declaradas como private como pode ser visto na Listagem 9 para serem acessadas a partir de get. Neste exemplo n�o ser�o implementados os m�todos set, pois os valores do identificador do coment�rio, do tempo em milissegundos da inserç�o do coment�rio, da descriç�o e do nome do usu�rio, respectivamente, ser�o atribu�dos exclusivamente pelo construtor da classe e n�o ser�o alter�veis.

public class Comment {
  private long id;
  private long logDate;
  private String comment;
  private String name;
...}

Listagem 9. Declaraç�o das vari�veis da classe modelo Comment

Ser�o definidos dois tipos de construtores para a classe Comment. O primeiro deles ser� utilizado para instanciar um objeto de Comment j� existente, ou seja, lido a partir do serviço get como pode ser visto na Listagem 10 e outro construtor para instanciar um objeto rec�m-criado ao finalizar com sucesso o m�todo de post como pode ser visto na Listagem 11.


public Comment(long id, String name, String comment, long logDate) {
  this.id = id;
  this.logDate = logDate;
  this.comment = comment;
  this.name = name;
}

Listagem 10. Construtor da classe modelo Comment para inst�ncia j� existente

public Comment(long id, Comment c) {
  this.id = id;
  this.name = c.getName();
  this.comment = c.getComment();
  this.logDate = c.getLogDate();
}

Listagem 11. Construtor da classe modelo Comment para inst�ncia rec�m-criada

O m�todo get respons�vel por recuperar o Comment pode ser observado na Listagem 12.

public String getComment() {
    return comment;
  }
   
  public long getId() {
    return id;
  }
   
  public long getLogDate() {
    return logDate;
  }
   
  public String getName() {
    return name;
  }
}

Listagem 12. C�digo dos m�todos get() da classe Comment

Criando a tarefa de buscar feeds

A tarefa de buscar feeds deve ser executada em segundo plano para evitar que ocorra o travamento da aplicaç�o. Para isso, o m�todo ir� herdar da classe AsyncTask. Para execuç�o, ser� passado um vetor de inteiro que ser� lido no m�todo doInBackground(). Neste exemplo, o progresso da tarefa n�o ser� repassado para a UI Thread, por isso, o segundo par�metro ser� declarado como Void. O resultado enviado para o m�todo onPostExecute() ser� a lista dos feeds que foram instanciados a partir de um JSON consumido do web service como pode ser visto no c�digo:


public class GetTask extends AsyncTask> {
...}

Para realizar a comunicaç�o com a UI Thread, ser� utilizada a interface Callback, a qual foi implementada na classe Request. O contexto da aplicaç�o ser� �til para ter acesso aos recursos da aplicaç�o como as strings declaradas no arquivo strings.xml, evitando a utilizaç�o de valores comuns a aplicaç�o, mas declarados localmente e pass�veis de alteraç�es como pode ser visto na Listagem 13.

private Context context;
  private Request.Callback callback;
   
  public GetTask(Context context, Request.Callback callback) {
    this.context = context;
    this.callback = callback;
  }

Listagem 13. Declaraç�o das vari�veis e construtor da classe GetTask

Antes da tarefa iniciar, ela ir� comunicar a UI Thread que est� prestes a ser executada. Para isso, o m�todo onStart() da interface Callback ser� executado passando como par�metro o nome da classe que est� para ser executada. Dessa forma, a UI Thread saber� qual tarefa est� para ser iniciada e dar� o devido feedback ao usu�rio como pode ser visto na Listagem 14.

@Override
  protected void onPreExecute() {
    super.onPreExecute();
    callback.onStart(getClass()); 
  }

Listagem 14. C�digo do m�todo onPreExecute()

A classe GetTask � respons�vel por buscar os feeds gravados no banco de dados externo. Essa tarefa � realizada no m�todo doInBackground() passando o limit de feeds que ser�o lidos como par�metro. Uma inst�ncia da classe Request ser� criada e o m�todo post() ser� executado passando dois par�metros: a URL na qual o web service se encontra e o mapa de par�metros. A resposta vir� como uma inst�ncia de JSONObject ou nulo caso ocorra alguma exceç�o. A inst�ncia de JSONObject ser� traduzida em elementos que ser�o utilizados para instanciar novos objetos de Comment e assim adicion�-los a lista de feeds como pode ser visto na Listagem 15.

@Override
  protected List<Comment> doInBackground(Integer... params) {
    int limit = params[0];
    List<Comment> comments = new ArrayList<Comment>();
    try {
      JSONObject jsonObject = new Request().post(new URLBuilder().buildHostUrl(), 
      new ParamBuilder().buildGetParams(limit));
      JSONArray jsonArray = jsonObject.getJSONArray("List");
      for (int i = 0; i < jsonArray.length(); i++) {
        JSONObject object = jsonArray.getJSONObject(i).optJSONObject("Feed");
        Comment comment = new Comment(object.getInt("id"),
        object.getString("username"), object.getString("comment"),
        object.getLong("log_date"));
        comments.add(comment);
      }
      return comments;
    } catch (Exception e) {
    e.printStackTrace();
    }
    return null;
  }

Listagem 15. C�digo do m�todo doInBackground()

A construç�o do objeto JSONObject � feita no m�todo post() da classe Request passando como par�metros a URL do web service e o mapa de par�metros. Ap�s realizar toda a tarefa, � necess�rio sincronizar os dados com a UI Thread. No m�todo onPostExecute() ser� realizada a sincronizaç�o e o resultado ser� passado atrav�s da interface instanciada no construtor da classe GetTask conforme pode ser visto na Listagem 16.

O m�todo onPostExecute() � o respons�vel por retornar para a UI Thread o resultado da requisiç�o realizada no m�todo doInBackground(). Caso o resultado seja diferente de nulo, o m�todo de sucesso onSuccess() ser� chamado. Caso contr�rio, o m�todo de erro onError() � chamado. O tratamento, seja qual for o resultado, ser� realizado pela classe ao qual a interface est� vinculada.


@Override
  protected void onPostExecute(List<Comment> result) {
    if (result != null)
      callback.onSuccess(getClass(), result);
    else
      callback.onError(getClass(), context.getString(R.string.error_get_comments));
  }

Listagem 16. M�todo onPostExecute()

Criando a tarefa de salvar coment�rio

Para a tarefa de salvar um coment�rio no servidor externo, assim como a de buscar feeds, ser� criada uma subclasse de AsyncTask para ser executada em segundo plano a fim de evitar um poss�vel fechamento da aplicaç�o por parte do sistema operacional. Para salvar o novo coment�rio, ser� passado por par�metro uma inst�ncia do mesmo com os valores de entrada inseridos pelo usu�rio o qual retornar� um JSON com o valor do identificador da nova inst�ncia. O progresso da tarefa n�o ser� informado ao usu�rio e o resultado enviado para a UI Thread ser� a mesma inst�ncia de Comment, apenas com o identificador atualizado como pode ser visto no c�digo:


  public class PostTask extends AsyncTask<Comment, Void, Comment> {
  ...}

As vari�veis, o construtor e o m�todo onPreExecute() da classe PostTask ser�o id�nticos ao da classe GetTask. Para a tarefa de salvar um coment�rio no servidor externo, assim como a de buscar feeds, estar� definida uma vari�vel do contexto da aplicaç�o e uma interface de callback que ser�o instanciadas no construtor da classe. O m�todo onPreExecute() informar� a UI Thread que a tarefa est� prestes a ser iniciada e que um feedback deve ser enviado ao usu�rio.

O m�todo doInBackground() receber� um vetor de inst�ncias de Comment como pode ser visto na Listagem 17. A requisiç�o ser� feita a partir do m�todo post() da classe Request passando como par�metros a URL do serviço e o mapa de par�metros. Em seguida, o resultado obtido ser� lido e o valor do identificador ser� repassado para uma nova inst�ncia de Comment, a qual tamb�m contar� com os valores j� existentes da inst�ncia de Comment recebida por par�metro em doInBackground().

@Override
  protected Comment doInBackground(Comment... params) {
    Comment comment = params[0];
    try {
      JSONObject jsonObject = new Request().post(new URLBuilder().buildHostUrl(),
      new ParamBuilder().buildPostParams(comment.getName(), comment.getLogDate(),
      comment.getComment()));
      return new Comment(jsonObject.optJSONObject("Object").optJSONObject("Feed")
      .getInt("id"), comment);
    } catch (Exception e) {
    e.printStackTrace();
    }
    return comment;
  }

Listagem 17. C�digo do m�todo doInBackground()

Ao receber a inst�ncia de Comment, ser� verificado o identificador da inst�ncia. Caso o valor seja igual a -1, significa que algum erro ocorreu na inserç�o do coment�rio e por isso o valor do identificador n�o foi atualizado e o erro ser� propagado para a UI Thread. Caso contr�rio, ser� retornada a inst�ncia de Comment com o valor do identificador atualizado como pode ser visto na Listagem 18.

As classes GetTask e PostTask possuem refer�ncia para o contexto da aplicaç�o como forma de evitar definir strings dentro do pr�prio c�digo. Dessa forma se pode evitar que uma alteraç�o na mensagem de erro enviada atrav�s da interface Request.Callback precise ser alterada internamente em cada classe. Com o contexto da aplicaç�o � poss�vel carregar o recurso de strings definida em strings.xml e apenas alterar a mensagem do respectivo item.


@Override
  protected void onPostExecute(Comment result) {
    if (result.getId() == -1)
    callback.onError(getClass(), context.getString(R.string.error_post_comment));
    else
    callback.onSuccess(getClass(), result);
  }

Listagem 18. C�digo do m�todo onPostExecute()

Criando o layout da aplicaç�o

Para esse exemplo, ser�o implementados tr�s layouts, um para a Activity principal, um para os itens da lista de feeds e um para a janela de di�logo que ser� utilizada para o usu�rio informar seu nome, o mesmo que ser� enviado em cada coment�rio que for feito atrav�s da aplicaç�o.

A Activity principal ter� um cabeçalho onde ser� informado ao usu�rio a quantidade de coment�rios enviados por ele. Em seguida haver� um bloco com uma barra de progresso e uma mensagem de espera para informar ao usu�rio que a tarefa GetTask est� sendo executada. Este bloco ficar� vis�vel apenas quando a tarefa GetTask estiver sendo executada. Em seguida estar� uma ListView na qual ser�o carregados o conte�do de uma lista de feeds atrav�s de uma subclasse de BaseAdapter. Finalmente, o layout ter� um rodap� com um campo de entrada (EditText) e um bot�o para salvar o coment�rio no web service como mostra a Listagem 19.


<LinearLayout xmlns:android="https://schemas.android.com/apk/res/android"
  android:layout_width="match_parent"
  android:layout_height="match_parent"
  android:orientation="vertical">
   
  <LinearLayout
  android:layout_width="fill_parent"
  android:layout_height="wrap_content"
  android:orientation="horizontal"
  android:padding="2.5dip">
   
  <TextView
  android:id="@+id/label_welcome"
  android:layout_width="wrap_content"
  android:layout_height="wrap_content" />
   
  </LinearLayout>
   
  <LinearLayout
  android:id="@+id/loading_get"
  android:layout_width="fill_parent"
  android:layout_height="wrap_content"
  android:gravity="center"
  android:orientation="horizontal"
  android:layout_margin="5dip">
   
  <ProgressBar
  android:layout_width="32dip"
  android:layout_height="32dip"
  android:layout_marginRight="5dip"/>
   
  <TextView
  android:layout_width="wrap_content"
  android:layout_height="wrap_content"
  android:text="@string/loading_get_comments"/>
   
  </LinearLayout>
   
  <ListView
  android:id="@+id/list_comments"
  android:layout_width="fill_parent"
  android:layout_height="0dip"
  android:layout_weight="1"/>
   
  <LinearLayout
  android:layout_width="fill_parent"
  android:layout_height="wrap_content"
  android:orientation="horizontal"
  android:padding="5dip">
   
  <EditText
  android:id="@+id/input_comment"
  android:layout_width="0dip"
  android:layout_height="wrap_content"
  android:layout_weight="1"
  android:layout_marginRight="5dip"
  android:inputType="text"/>
   
  <Button
  android:id="@+id/button_post"
  android:layout_width="wrap_content"
  android:layout_height="wrap_content"
  android:text="@string/button_post"/>
   
  </LinearLayout>
   
  </LinearLayout>

Listagem 19. C�digo do arquivo de layout activity_main.xml

Ap�s criar o arquivo activity_main.xml, o resultado pode ser visto na Figura 5. Mesmo com os componentes carregados em apenas uma tela, foi poss�vel criar um layout limpo e que respeitasse as duas premissas da aplicaç�o: enviar e ler feeds de um web service.

Figura 5. Layout da Activity principal

Criando a classe PreferencesLoader

A aplicaç�o do artigo armazenar� duas informaç�es do usu�rio que ser�o mostradas no cabeçalho da MainActivity sendo que uma delas tamb�m ser� utilizada na inserç�o de um novo coment�rio no banco de dados externo. Essas informaç�es ser�o armazenadas utilizando a interface de armazenamento SharedPreferences. As operaç�es com essa interface ser�o realizadas a partir da classe PreferencesLoader a qual ser� criada e que herda da classe AsyncTaskLoader como pode ser visto no c�digo a seguir. Al�m disso, a classe PreferencesLoader tamb�m ir� implementar a interface OnSharedPreferenceChanceListener a fim de ser notificada quando algum valor armazenado em SharedPreferences for alterado:


  public class PreferencesLoader extends AsyncTaskLoader<SharedPreferences>
  implements SharedPreferences.OnSharedPreferenceChangeListener

Para que os valores inseridos ou atualizados em SharedPreferences sejam salvos, � necess�rio que os mesmos sejam aplicados a partir de uma inst�ncia de Editor como pode ser visto no c�digo:


public static void persist(final SharedPreferences.Editor editor) {
  editor.apply();
}

O carregamento dos dados armazenados em SharedPreferences ser� feito em uma Thread secund�ria a partir do m�todo loadInBackground(). O m�todo retorna a inst�ncia de SharedPreferences ativa como pode ser visto no c�digo a seguir:

public SharedPreferences loadInBackground() {
  prefs = PreferenceManager.getDefaultSharedPreferences(getContext());
  prefs.registerOnSharedPreferenceChangeListener(this);
  return (prefs);
}

Ao ser iniciada a inst�ncia de PreferencesLoader, o m�todo onStartLoading() ser� executado. Caso j� exista uma inst�ncia ativa de SharedPreferences, o m�todo entregar� como resultado a inst�ncia ativa. Contudo, pode ser que alguma alteraç�o na orientaç�o do dispositivo reinicie a aplicaç�o e com isso a inst�ncia de SharedPrerences seja perdida. Nesse caso, o m�todo onStartLoading() ir� forçar o carregamento da inst�ncia de SharedPreferences como pode ser visto na Listagem 20.

protected void onStartLoading() {
  if (prefs != null) {
    deliverResult(prefs);
  }
   
  if (takeContentChanged() || prefs == null) {
    forceLoad();
  }
}

Listagem 20. C�digo do m�todo chamado ao iniciar PreferencesLoader

Criando a classe DAO

A classe DAO servir� para agrupar algumas funcionalidades utilizadas na aplicaç�o como dos m�todos get() e post() que podem ser vistos na Listagem 21. Contudo, antes de cham�-los, � necess�rio saber se a tarefa est� sendo executada e para isso se pode verificar atrav�s dos m�todos isGetTaskRunning() e isPostTaskRunning() conforme pode ser visto na Listagem 22.



public void get(Context context, Request.Callback callback, int limit) {
  if (request.isOnline(context).equals(Request.NetworkState.None))
  callback.onError(getClass(), context.getString(R.string.error_get_comments));
  else {
    getTask = new GetTask(context, callback);
    getTask.execute(limit);
  }
}
   
public void post(Context context, Request.Callback callback, Comment comment) {
  if (request.isOnline(context).equals(Request.NetworkState.None))
  callback.onError(getClass(), context.getString(R.string.exception_no_network));
  else {
    postTask = new PostTask(context, callback);
    postTask.execute(comment);
  }
}
   
  Listagem 22. M�todos de verificaç�o do estado das Tasks.
  public boolean isGetTaskRunning() {
  return getTask != null && getTask.getStatus() != AsyncTask.Status.FINISHED;
  }
   
  public boolean isPostTaskRunning() {
  return postTask != null && postTask.getStatus() != AsyncTask.Status.FINISHED;
}

Listagem 21. C�digo dos m�todos get() e post()

Criando a Activity principal

A classe MainActivity dever� implementar tr�s interfaces de Callback, s�o elas: View.OnClickListener, Request.Callback e LoaderManager.LoaderCallbacks como pode ser visto no c�digo a seguir:

public class MainActivity extends Activity implements Request.Callback, View.OnClickListener,
LoaderManager.LoaderCallbacks<SharedPreferences>

A implementaç�o dessas interfaces por parte da Activity MainActivity, de acordo com a definiç�o da utilizaç�o de interfaces, ir� permitir � classe MainActivity sobrescrever os m�todos dessas interfaces como se herdasse de uma classe qualquer.

Para a interface Request.Callback, a MainActivity deve implementar os m�todos onStart(), onCancel(), onSuccess() e onError() como pode ser visto na Listagem 23. Com esses m�todos, as tarefas ass�ncronas poder�o sincronizar com a UI Thread sem a necessidade de criar uma inst�ncia singleton de MainActivity. Essa pr�tica costuma deixar o c�digo mais elegante e, para casos onde uma tarefa possa ser vinculada a mais de uma Activity ou Fragment, evita a necessidade de verificaç�o da exist�ncia de uma inst�ncia singleton para cada Activity ou Fragment, desde que os mesmos implementem a interface Request.Callback.


@Override
  public void onStart(Class<?> executingClass) {
  if (executingClass.equals(PostTask.class)) {
  pgLoading = new ProgressDialog(this);
  pgLoading.setMessage(getString(R.string.loading_post_comment));
  pgLoading.setCancelable(false);
  pgLoading.setCanceledOnTouchOutside(false);
  pgLoading.show();
  }
  if (executingClass.equals(GetTask.class)) {
  layoutLoading.setVisibility(View.VISIBLE);
  }
  }
   
  @Override
  public void onSuccess(Class<?> executingClass, Object result) {
  if (executingClass.equals(GetTask.class)) {
  layoutLoading.setVisibility(View.GONE);
  comments.addAll((List<Comment>) result);
  adapter.notifyDataSetChanged();
  }
  if (executingClass.equals(PostTask.class)) {
  totalPosts += 1;
  labelWelcome.setText(getString(R.string.label_welcome, name, totalPosts));
  inputComment.setText("");
  comments.add(0,(Comment) result);
  adapter.notifyDataSetChanged();
  if (pgLoading != null)
  pgLoading.dismiss();
   
  SharedPreferences.Editor editor = PreferenceManager
  .getDefaultSharedPreferences(MainActivity.this).edit();
  editor.putInt(TOTAL_COMMENTS, totalPosts);
  PreferencesLoader.persist(editor);
  }
  }
   
  @Override
  public void onError(Class<?> executingClass, String errorMessage) {
  if (executingClass.equals(GetTask.class)) {
  layoutLoading.setVisibility(View.GONE);
  }
  if (executingClass.equals(PostTask.class)) {
  if (pgLoading != null)
  pgLoading.dismiss();
  }
  Toast.makeText(this, errorMessage, Toast.LENGTH_LONG).show();
  }
   
  @Override
  public void onCancel(Class<?> executingClass) {
   
  }

Listagem 23. M�todos sobrescritos da interface Request.Callbacks

Para a interface LoaderManager.LoaderCallbacks, a MainActivity deve sobrescrever os m�todos onCreateLoader(), onLoadFinished() e onLoaderReset() como pode ser visto na Listagem 24. A implementaç�o da interface LoaderManager.LoaderCallbacks ir� permitir que a aplicaç�o acesse as informaç�es armazenadas em SharedPreferences em uma tarefa paralela, a qual ir� notificar a MainActivity assim que as informaç�es forem carregadas.


@Override
  public Loader<SharedPreferences> onCreateLoader(int id, Bundle bundle) {
  return (new PreferencesLoader(this));
  }
   
  @Override
  public void onLoadFinished(Loader<SharedPreferences> sharedPreferencesLoader, 
  SharedPreferences sharedPreferences) {
  totalPosts = sharedPreferences.getInt(TOTAL_COMMENTS, 0);
  name = sharedPreferences.getString(NAME, "");
  if (name.equals(""))
  askName();
  else
  labelWelcome.setText(getString(R.string.label_welcome, name, totalPosts));
  }
   
  @Override
  public void onLoaderReset(Loader<SharedPreferences> sharedPreferencesLoader) {
   
  }

Listagem 24. M�todos sobrescritos da interface LoaderManager.LoaderCallbacks

Ao iniciar a Activity principal, h� alguns pontos importantes para destacar no m�todo onCreate(). Nele ser� vinculado o layout activity_main.xml a Activity em execuç�o. Os objetos das views ser�o vinculados as views declaradas em activity_main.xml atrav�s do identificador das views. O LoaderManager ser� notificado para criar um novo loader caso n�o haja nenhum ativo e o m�todo get() da classe DAO ser� executado caso ele ainda n�o esteja sendo executado como pode ser visto na Listagem 25.


@Override
  protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  setContentView(R.layout.activity_main);
   
  buttonPost = (Button) findViewById(R.id.button_post);
  inputComment = (EditText) findViewById(R.id.input_comment);
  listComments = (ListView) findViewById(R.id.list_comments);
  labelWelcome = (TextView) findViewById(R.id.label_welcome);
  layoutLoading = (LinearLayout) findViewById(R.id.loading_get);
   
  buttonPost.setOnClickListener(this);
   
  getLoaderManager().initLoader(0, null, this);
   
  adapter = new CommentAdapter(this, comments);
  listComments.setAdapter(adapter);
   
  if (!commentDAO.isGetTaskRunning())
  commentDAO.get(this, this, 50);
  }

Listagem 25. C�digo do m�todo onCreate() da Activity principal

Ao carregar os dados de SharedPreferences, caso n�o exista um valor definido para NAME, o m�todo askName() ser� chamado e nele ser� aberto uma Dialog na qual o usu�rio dever� informar um nome para continuar navegando na aplicaç�o como pode ser visto na Listagem 26. Essa Dialog n�o poder� ser cancelada, sendo ela s� finalizada ap�s o usu�rio digitar um nome no campo de entrada.


private void askName() {
  final Dialog dialog = new Dialog(this);
  dialog.requestWindowFeature(Window.FEATURE_NO_TITLE);
  dialog.setContentView(R.layout.dialog_edit_name);
  dialog.setCanceledOnTouchOutside(false);
  dialog.setCancelable(false);
  final EditText inputName = (EditText) dialog.findViewById(R.id.input_name);
  Button buttonSave = (Button) dialog.findViewById(R.id.button_save);
   
  buttonSave.setOnClickListener(new View.OnClickListener() {
  @Override
  public void onClick(View view) {
  if (!inputName.getText().toString().trim().equals("")) {
  name = inputName.getText().toString().trim();
   
  SharedPreferences.Editor editor = PreferenceManager
  .getDefaultSharedPreferences(MainActivity.this).edit();
  editor.putString(NAME, name);
  editor.putInt(TOTAL_COMMENTS, totalPosts);
  PreferencesLoader.persist(editor);
   
  labelWelcome.setText(getString(R.string.label_welcome, name, totalPosts));
   
  dialog.dismiss();
  }
  else
  Toast.makeText(MainActivity.this, R.string.exception_empty_fields, Toast.LENGTH_LONG).show();
  }
  });
  dialog.show();
  }

Listagem 26. C�digo do m�todo askName()

Para enviar um novo coment�rio ao servidor externo, o campo de entrada deve ser preenchido e nenhuma outra inst�ncia de PostTask deve estar sendo executada como pode ser visto na Listagem 27. Caso as condiç�es citadas n�o sejam implementadas, um �nico usu�rio poder� causar um grande transtorno no web service ao salvar feeds sem um coment�rio ou salvar diversos feeds iguais, os quais foram armazenados atrav�s de cliques consecutivos no bot�o de salvar e a consequente inicializaç�o de m�ltiplas inst�ncias da classe PostTask.


private void post() {
  if (isCommentInputFilled()) {
  if (!commentDAO.isPostTaskRunning())
  commentDAO.post(this, this, new Comment(-1, name, getCommentInputText(), 
  System.currentTimeMillis()));
  }
  else
  Toast.makeText(this, R.string.exception_empty_fields, Toast.LENGTH_LONG).show();
  }

Listagem 27. C�digo do m�todo post()

Ao final do desenvolvimento a aplicaç�o ficar� com uma tela conforme mostra a Figura 6. A lista de feeds ser� populada ao iniciar a aplicaç�o pelos �ltimos feeds armazenados no servidor externo. Uma pequena mensagem de boas-vindas ser� mostrada ao usu�rio com o nome e a quantidade de coment�rios que foram enviados por ele. E por �ltimo, teremos um espaço no qual o usu�rio poder� escrever um coment�rio e enviar para o web service ao clicar no bot�o Enviar.

Figura 6. Aplicativo em execuç�o

A utilizaç�o de tarefas ass�ncronas na plataforma Android visa evitar que a aplicaç�o fique inoperante e consequentemente seja finalizada pelo SO. Existem diversas maneiras de desenvolver tarefas que rodem em paralelo com a UI Thread, contudo h� tamb�m cuidados a serem tomados como, por exemplo, a sincronizaç�o com a UI Thread.

Al�m de buscar alternativas para consumo de um web service ou leitura de dados armazenados internamente, o desenvolvedor pode implementar, com tarefas ass�ncronas, processos para agendar a execuç�o de m�todos em determinado hor�rio ou caso uma condiç�o seja satisfeita como o caso de Push Notifications, alarmes e download de conte�do online.

Confira tamb�m

Introduç�o ao Android

Curso

Android Toolbar