Injeção de Dependência Com a lib Dagger 2 no Android

Opa, blz?

Nesse vídeo apresento uma maneira de implementar o design pattern Injeção de Dependência no Android, utilizando a lib Dagger 2 que é mantida pelo Google. Logo no ínicio do vídeo explico o que é o design pattern Injeção de Dependência (simples de entender), as vantagens ao uso desse pattern ao invés de outras abordagens para obtenção de objetos, como: Construtores de classes e Factory design pattern, por exemplo. Vantagens (maximização da reutilização de código, testes e manutenção) citadas na documentação do package javax.inject, que também é necessário no trabalho conjunto com a lib Dagger 2 na implementação da Injeção de Dependência.

Importante ressaltar que o Dagger é para o Java, a Injeção de Dependência é um design pattern de programação, para qualquer linguagem.

Para finalizar o post e tentar explicar de uma maneira mais fácil o pattern, pense em sua classe A que tem uma variavel de instancia do tipo classe B, no momento sua classe A está instanciando a classe B dentro do construtor dela, isso é um exemplo de uma dependência forte e forte acomplamento entre as entidades, ocasionando maior quantidade de código alterado quando somente a entidade B precisa sofrer atualização (perdendo em manutenção), perda de reuso de código, onde somente a entidade A era necessária e a perda de eficiencia em testes unitários, tendo em mente que a criação de entidades fakes de testes será ainda mais complexa devido a forte dependência. Porém modificando um pouco a classe, digo, permitindo que a classe A apenas receba uma entidade B já construída fora da classe A, já é um grande ganho no código, implementando assim a Injeção de Dependência. Porém mesmo com o design pattern implementado ainda há "n" outros problemas a serem resolvidos, isso é o que o Dagger vem também resolver. Sem mais delongas vou deixar você assistir ao vídeo. Note que a principal vantagem do Dagger 2 em relação ao Dagger 1 é não utilização de Instrospection e Reflection que causam perda de eficiencia.

Segue link do project no GitHub: https://github.com/viniciusthiengo/dagger-2-example

Segue link do post comentado no vídeo:

ButterKnife Lib, Simplificando Acesso a Views no Android

Segue links dos resursos utilizados para construir o vídeo:

Página oficial da lib Dagger 2

Página oficial do package javax.inject

Post "Tasting Dagger 2 on Android" do Blog Fernando Cejas

Post "Dagger 2.0 Android migration tips" do Blog Siphon9

Primeiro post (de três) da série "Dependency Injection on Android: Dagger" do Blog Antonio Leva

Post resposta no stackoverflow sobre o que é Reflection (não esqueça de ler o comentário com mais up votes)

Post "Dependency Injection With Dagger 2 on Android" do Blog do portal Tuts+

Bitbucket do android-apt plugin

Post "Dependency Injection With Dagger 2" em Codepath

Vídeo "Dependency Injection With Dagger 2" em SlideNerd YouTube channel

Post "Dependency Injection" no blog Jenkov.com

Vídeo "Dependency Injection" Anthony Ferrara YouTube channel

Vlw

Relacionado

GCM Cloud Connection Server (XMPP). Push Message Android - Parte 5Android

GCM e AWS SNS. Push Message Android - Parte 6Android

Parse Notification. Push Message Android - Parte 7Android

Infográfico - Mercado de T.I. Brasil e Expectativas Sobre TrabalhoEmpreendedorismo

Comentários Blog (10)

Para código / script, coloque entre [code] e [/code] para receber marcação especifica.

Forneça seu nome válido.

Forneça seu email válido.

Forneça o comentário.

Enviar

Enviando, aguarde...

Felipe Rohde (1) (0)

27/02/2016

Ola, estou estudando injação de dependencia. algumas coias no seu video eu nao entendi.
por exemplo, fizemos tudo isso pra eleiminar a dependencia forte que no "new car()" exercia na nossa activity, mas acabamos tendo que ter a dependencia forte de um "new carComponent()"

Responder

Vinícius Thiengo (0) (0)

06/03/2016

Fala Felipe, blz?
Realmente parece um pouco confuso, na verdade esse é um modelo de implementação do padrão Injeção de Dependência, mais precisamente a implementação do padrão utilizando o Dagger 2.

Os métodos do ciclo de vida de uma Activity, em nosso exemplo o método onCreate(), podem ser considerados com a mesma importância de um método main() em um projeto Java convencional.

Ou seja, na classe Activity não podemos tratar as entidades vinculadas a ela (variáveis de instância, por exemplo) com o mesmo problema de dependência forte que teríamos na utilização de classes do domínio do problema. O mesmo para Fragments, Services, Applications e BroadcastReceivers quando estão sendo utilizados.

No main() do Java dev convencional lá era o local das principais inicializações, até mesmo se fosse a entidade que permitisse a utilização do DI posteriormente. Nesse exemplo nosso main() é o onCreate() da MainActivity. São componentes que vc não pode considerar sendo parte do domínio do problema, código especifico de seu projeto.

Resumo, o carComponent é implementação de um componente da library Dagger, ele permite que os objetos sejam criados somente quando necessário, que é a proposta do padrão Injeção de dependência. Sem o componente, no contexto de utilização do Dagger, não seria possível a criação dos objetos.

Provavelmente não consegui passar isso mt bem no vídeo, mas é essa a ideia. Dê uma estuda mais em DI somente, sem o Dagger. Abraço

Responder

Rafael (1) (0)

23/02/2016

Fala Thiengo, blz?
Primeiro queria te agradecer pelo video que explica muito bem a questão de DI com Dagger2.
Minha dúvida é quanto a aplicação de Dagger2 em BroadcastReceivers e Services sem forte dependência. Como aplicar DI e dagger2 nesse caso?

Responder

Vinícius Thiengo (1) (0)

27/02/2016

Fala Rafael, blz?
O Dagger2 faz com que utilizemos o padrão DI dentro da Application, não cheguei a testar se a Applicaition é tb executada quando o Service ou Broadcast apenas estão inicializados, provavelmente não.

Nesse caso, para manter o fraco acoplamento recomendo a utilização de um Factory, mas se o Factory for utilizado somente ali não sei se seria jogo, logo eu optaria por manter a base do DI, sem criar dependência forte entre objetos, inicializando os mesmos fora e atribuindo via métodos ou construtores... e não utilizaria o Dagger2. Mas nesse caso o forte acoplamento com o Service e o Broadcast em si é inevitável. Abraço

Responder

João Arthur (1) (0)

02/11/2015

Fala Thiengo blz ? o que você acha da RoboGuice ? ela também é mantida pelo google ?

Responder

Vinícius Thiengo (0) (0)

03/11/2015

Fala João, blz?
Não conheço o RoboGuice, o que vi dele foi na apresentação do Dagger 2, logo assumi que é uma espécie de library concorrente. Se estiver certo, então provavelmente o Dagger é melhor opção, ambos foram comparados na apresentação do Dagger 2. Abraço

Responder

Alessandro Barreto (2) (0)

08/10/2015

Boa Thiengo, Teria como você fazer um vídeo falando sobre a lib okhttp http://square.github.io/okhttp/ e suas vantagens/desvantagens ou comparando com a lib volley qual seria a melhor

Responder

Vinícius Thiengo (2) (0)

09/10/2015

Vlw a dica Alessandro, vou estudar a possibilidade. Abraó

Responder

lukascordeiro.pord (2) (0)

07/10/2015

ótimo post Thiengo. Só seu van cara!

Responder

Mario Feles Dos Santos Ju (1) (0)

06/10/2015

Parabéns pelo post ... Material bem didático

Responder