Dagger Android, tudo que você precisa entender em português. Parte-2

Carlos Galves
Jul 21, 2020 · 6 min read
Image for post
Image for post

E ai tudo bem? Dando sequência a parte 2 sobre Dagger Android, na primeira parte vimos os conceitos básicos que você precisa saber, antes de sair usando alguma ferramenta(Você encontra a primeira parte neste blog mesmo)

Então vamos lá ao nosso menu de guia

Os links de toda a sequência você encontra aqui:

______________________________________________________________

Parte 2 — Na segunda parte deste assunto iremos ver na prática como por exemplo:

  • Configurando um modulo como exemplo.
  • Exemplo de testes unitários deste modulo.
  • Exemplo de testes integrados com Espresso.
  • Vantagens
  • Desvantagens.
  • Outros Design Patterns parecidos.
  • Outras bibliotecas disponíveis.
  • Repositório onde você encontra todos os exemplos.

______________________________________________________________

Configurando o Dagger Android

Bom, vamos agora configurar então o Dagger e usar em nosso projeto.

Adicionando lá no Build.Gradle App

e dentro do dependencies

Em nosso Application, temos que criar lá a inicialização do Dagger.

O nome DaggerAppComponent é porque meu Dagger se chama AppComponent. Então é preciso criar essa classe.

É importante notar que este nosso AppComponent tem noção do Contexto geral da aplicação. Por isso fica fácil também injetar nossos modulos. O gráfico seria assim:

Image for post
Image for post

No nosso exemplo vamos criar um LoginComponent.

Vamos visualizar ele como um Sub-componente, pois ele poderá ser usado em diversos lugares a mesma instância dos objetos.

Para usar o Dagger, precisamos sempre falar para ele quem vai usar, no nosso caso a Activity vai precisar das futuras injeções.

E ai no nosso AppComponent, temos que dizer que este é um modulo a ser visto/injetado.

A visão do gráfico de dependências ficaria assim:

Image for post
Image for post

Para nosso exemplo, vamos criar então 3 modulos.

  • ViewModel
  • Repository
  • DataSource

No DaggerAndroidActivity, injetamos nosso viewmodel

Pronto. O exemplo esta funcionando.

A visualização do gráfico hoje de nossas dependências ficaria assim:

Image for post
Image for post

______________________________________________________________

Exemplo de testes unitários deste modulo

Agora vamos implementar como testar nosso viewmodel. O modo como é feito no Repository e Datasource segue a mesma regra. Logo, vamos apenas implementar como exemplo o viewmodel agora para fins didáticos.

Bom, primeiro temos que ter em mente sobre o InstantTaskExecutorRule

para caso tenhamos tasks ele consiga enxergar isso e não trave nosso teste.

Depois vamos adicionar ao nosso exemplo a biblioteca MocKK

Essa biblioteca é bem legal. Fácil de usar e testar. Deixei comentado em casos que você não precisa saber da resposta para auxiliar você no seus testes também.

Uma vez, vamos validar então na chamada do nosso viewModel quando fizer o doLogin, responder da maneira correta.

Para isso as configurações iniciais são:

Para validar então nosso teste, temos que dizer que o repository vai nos dar uma resposta de acordo com nosso cenário de testes.

E assim nossos UnitTest ficariam:

Nosso resultado:

Image for post
Image for post

______________________________________________________________

Exemplo de testes integrados com Espresso

Chegamos em um tópico que eu gosto muito, e foi um pouco não complicado mas difícil de enxergar a primeira vista.

Para primeiro partirmos de Dagger + Espresso. Temos que ter uma pre-configuração no nosso androidTest package.

E no nosso build.gradle App também. Essa é uma sacada que não tem gloria alguma saber, na verdade acho que isso que é o que “emperra” o pessoal na minha opinião quando vai pegar esse assunto.

Primeiro, você deve criar uma base para seus testes integrados.

Com um MyCustomTestRunner que estenda AndroidJUnitRunner. E esta implemente seu MyApplication mas no caso, de testes.

Ficaria assim:

Primeiro adicione que seu compilador de AndroidJUnitRunner é o seu MyCustomTestRunner no build.gradle App.

Lá dentro do defaultConfig

Aqui é importante acertar o caminho do seu CustomAndroidJUnitRunner para o seu teste integrado funcionar.

E seu MyTestApplication que vai injetar os modulos fakes de respostas ao devido comportamento que você deseja.

Reparem que eu coloquei em destaque que nesse meu modulo de TestAppComponent eu adiciono um RepositoryFakeModule.

Então assim quando eu iniciar o meu teste integrado. Ele vai me dar o cenário de resposta falsa.

Para terminar então nosso teste de aplicação ficaria assim:

Criei um Gif para você visualizar como funciona o teste.

Image for post
Image for post

E é isso, o resto é contigo. Se precisar vai mockando seus cenários nos testes integrados.

______________________________________________________________

Vantagens

Vamos lá, meus pontos de vistas sobre usar Dagger.

  • Java/Kotlin — Podemos usar tanto em projetos Java como Kotlin. Querendo ou não ainda muita gente escreve seus projetos em Java.
  • Reusabilidade de código
  • Fácil de testar
  • Manutenção do código se feito de maneira correta tende a ser melhor que uma injeção manual ou outros Design Patterns em minha visão.
  • Time do Google pretende colocar no Jetpacket. Isso é importante sim pois mostra que vão procurar dar suporte a essa lib.
  • Uma vez entendido o assunto, o stack de erros começa a fazer sentido.

______________________________________________________________

Desvantagens

Como tudo na vida, nada bom é fácil. Então ao meu ver essas são as dificuldades encontradas:

  • A curva de aprendizado sem uma documentação em dia se torna uma dor de cabeça, agora com o Hilt novo produto do Android tá ficando mais fácil nesse ponto.
  • Anotações de processos tendem a mudar e ai seu código pode vir a quebrar se não ao menos tiver um @Deprecated para te ajudar.
  • Realmente, a parte do Espresso não achei muitos exemplos, o único bom mesmo é o codelab lançado pela google aqui neste link: https://codelabs.developers.google.com/codelabs/android-dagger/index.html?index=..%2F..index#13
  • Existem outras libs que tendem a ter uma configuração menos complexa ao que parece: Koin é uma delas. Kodein não cheguei a implementar no momento que escrevo esta artigo.
  • É necessário ter essa visualização de gráfico de dependências que ainda não é visível o que causa um certo desconforto mental no meu ver. Já vi libs que estão planejando atender a essa necessidade.

______________________________________________________________

Outros Design Patterns parecidos

Bom, como existem vários outros tipos de Design Patterns parecidos é interessante saber a diferença e como justificar sua resposta em usar ou não DI.

São eles:

  • Singleton
  • ServiceLocator

______________________________________________________________

Singleton:

Singleton é uma instância viva que vai ficar viva enquanto seu app esta funcionando. O que pode deixar ele devagar (Acúmulos de Singletons onde não precisa). Dependência de injeção temos o controle do que é uma fábrica para certos componentes, quando precisamos renovar essas fábricas e quando queremos uma única instância viva dessa classe sim com Singleton Pattern.

Para saber mais segue referências:

https://pt.wikipedia.org/wiki/Singleton

______________________________________________________________

ServiceLocator

Service Locator, também um Design Pattern e tem o problema de uma classe ficar “inchada” com muitos objetos vivos e no fim sua classe de modulo vai ver mais do que precisa. Além das constantes repetições de tipos diferentes vivas como no exemplo Ferrari, Mereces. DI é uma injeção externa, eu digo lá na config que para aquele caso vou precisar disso, disso e acabou.

Para saber mais segue referências:

https://en.wikipedia.org/wiki/Service_locator_pattern

______________________________________________________________

Outras bibliotecas disponíveis

Bom, como dito acima, existem algumas outras bibliotecas. As que eu destaco mais nesse momento seria o Koin. Mas temos também o Kodein. Segue sites deles para mais detalhes.

Link Koin:

https://doc.insert-koin.io/

Link Kodein:

https://kodein.org/Kodein-DI/?6.5/core

______________________________________________________________

Repositório onde você encontra todos os exemplos

Bom, é isso por essa parte, na próxima vou mostrar como usar isso em um projeto modularizado.

Espero que você tenha gostado, deixa seu joinha ai e vamos para o próximo passo! Valeu, abraço.

Android Dev BR

Artigos em português sobre Android, curados pela comunidade…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store