Concrete Logo
Hamburger button

Desafio: Integração Contínua em Android

  • Blog
  • 10 de Outubro de 2014
Share

Ontem tivemos o prazer de fazer um evento da Concrete Solutions em parceria com a iniciativa Samsung Ocean, sobre Android! Depois de uma introdução sobre times ágeis de desenvolvimento mobile, com o Victor Lima, eu falei um pouco sobre integração contínua e apresentei uma possível solução ao desafio Android que a Concrete Solutions tinha proposto como parte do processo de admissão da empresa.

Hoje, vamos detalhar e compartilhar essa solução. O desafio era simples. Segue a descrição, na íntegra, abaixo:

[code]
# Desafio Concrete Solutions Android

### Criar um aplicativo Android de consulta de CEP

– O aplicativo deverá consultar um serviço REST público de CEP (passaremos URL e documentação).
– A interface deverá conter um campo para digitar o CEP, um botão de consulta e um botão de visualizar consultas anteriores.
– A lista de consultas anteriores deverá estar aparente
– O aplicativo deverá ter tratamento para os casos de erro (sem conexão, CEP inválido, serviço indisponível)

### Processo de submissão

O candidato deverá implementar a solução e enviar um pull request para este repositório com a solução.

### URL e Documentação de um serviço de consulta de CEP RESTful:
Documentação da API: https://correiosapi.apphb.com
Exemplo de uso da API: https://correiosapi.apphb.com/cep/76873274
[/code]

Tivemos um bom número de pull requests. Foi interessante ver como o mercado de desenvolvedores tem utilizado a plataforma Android para resolver problemas comuns de desenvolvimento. Porém, demos uma bela “incrementada” no desafio agora. Este do CEP não vale mais =/, então criamos o desafio do Dribble! Vejam a descrição aqui e participem!

O código que usei para ilustrar a solução do CEP está neste repositório. Para executá-lo, será necessário ter o Android Studio (de preferência a última versão do canal Canary) e um dispositivo ou emulador para executar o projeto.

A ideia dessa implementação era mostrar frameworks que utilizamos no dia a dia. Portanto, ao abrirem as classes do projeto verão logo de cara que elas possuem diversas anotações. São recursos do framework Android Annotations que gera o código chato do Android como preencher Views, incluir listeners de clicks e etc. Ele até te dá um framework para execução assíncrona sem usar AsyncTasks!
Tudo isso é possível porque, ao compilar o projeto, uma API do Java chamada APT (Annotation Processing Tool) é executada. Ele varre as classes por anotações e delega o processamento dessas classes para bibliotecas que implementam suas interfaces. Assim, para que o Studio não reclame que não está encontrando classes e coisas do tipo, sugiro apertarem o botão de compilar (normalmente à esquerda do tipo de execução) para que o Annotations possa gerar estas classes.

Feito isso, o projeto já poderá ser instalado no device ou emulador. Só falta UMA configuração no ambiente para poder rodar os testes pela IDE…

Como nós escolhemos a biblioteca do Google chamada Espresso para fazermos nossos testes, é necessário configurar o Studio para executar os testes usando o InstrumentationTestRunner do Espresso. O processo é simples:

  • Vá em Run -> Edit configurations
  • Ao abrir a janela de configurações, expanda “Defaults” que aparece na esquerda
  • Selecione Android Tests
  • Na opção “Specific instrumentation runner (optional)” digite com.google.android.apps.common.testing.testrunner.GoogleInstrumentationTestRunner
  • Salve e pronto!

Agora é só abrir a classe de teste (PesquisaActivity_Test), clicar direito no teste e run. Pronto!

(Qualquer dúvida sobre o projeto por favor mandem perguntas ou criem issues no próprio Github!)