Dependency injection on Android: Dagger (Part 1)

On this new series I will explain what dependency injection is, what its main purpose is and how to use it on an Android project by using Dagger, the best know implementation designed with Android in mind.

It will be a follow-up from my previous post about MVP for Android, because I know some of you are quite interested in see them implemented in the same project, and I think they work quite well together.

This first part is going to be only a little theory to settle the basis. It’s important to understand what it is and why it exists, because if not we will think the benefits are not enough for the effort.

What is a dependency?

If we want to inject dependencies, we first need to know what a dependency is. In short, a dependency is a coupling between two modules of our code (in oriented object languages, two classes), usually because one of them uses the other to do something.

Why dependencies are dangerous?

Dependencies from high to low level are dangerous because we couple both modules in a way that if we need to change one module with another, we necessarily need to modify the code of the coupled module. That’s really bad if we want to create a testable app, because unit testing requires that when we are testing a module, it is isolated from the rest of modules in our app. To do this, we need to substitute dependencies with mocks. Imagine a code like this:

public class Module1{
private Module2 module2;

public Module1(){
module2 = new Module2();

public void doSomething(){



How do we test ‘doSomething’ without testing ‘doSomethingElse’? If test fails, what method is the one that is failing? We can’t know. And things get worse if this ‘doSomethingElse’ method saves something in database or performs an API call.

Every ‘new’ we write is a hard dependency we probably need to avoid. And no, writing less modules isn’t a solution, don’t forget single responsibility principle.

How to solve it? Dependency inversion

If we can’t instantiate modules inside another module, we need to provide those modules in another way. Can you imagine how? Exactly, via constructor. That is basically what dependency inversion principle means. You shouldn’t rely on concrete module objects, only on abstractions.

Our previous example code would be something like this:

public class Module1{
private Module2 module2;

public Module1(Module2 module2){
this.module2 = module2

public void doSomething(){



So what’s dependency injection?

You already know! It consists of passing dependencies (inject them) via constructor in order to extract the task of creating modules out from other modules. Objects are instantiated somewhere else and passed as constructor attributes when creating the current object.

But here it comes a new problem. If we can’t create modules inside modules, there must be a place where those modules are instantiated. Besides, if we need to create modules with huge constructors including lots of dependencies, code will become dirty and hard to read, with objects travelling around the inmensity of our app. That’s what a dependency injector solves.

What is a dependency injector?

We can consider it as another module in our app that is in charge of providing instances of the rest of modules and inject their dependencies. That is basically its duty. The creation of modules is localized in a single point in our app, and we have full control over it.

And finally… What is Dagger?

Dagger is a dependency injector designed for low-end devices. Most dependency injectors rely on reflection to create and inject dependencies. Reflection is awesome, but is very time consuming on low-end devices, and specially on old android versions. Dagger, however, uses a pre-compiler that creates all the classes it needs to work. That way, no reflection is needed. Dagger is less powerful than other dependency injectors, but it’s the most efficient.

Is Dagger only for testing?

Of course not! It makes easier to reuse your modules in other apps, or even change them in the same app. Think for example in an app which takes its data from some local files on debug and from an API service on release. That’s perfectly possible by injecting one module or another on each case.


I know this post it’s a bit hard, but I think it’s very important to establish the terms we are going to deal with on next episodes. We already know what dependencies are, what we improve with dependency inversion and how we can implement it by using a dependency injector.

On next episode we will get our hands dirty. so stay tuned!

24 thoughts on “Dependency injection on Android: Dagger (Part 1)”

  1. Excellent blog post. I am using dagger in a new project but sometimes it is difficult to hang it all together. These posts will help me with the new paradigm

    1. You made dependency injection understandable. Thank you. I tried learning it just by reading Dagger’s documentation but it wasn’t clicking.

  2. Great! I was one of those people interested in see a MVP example with Dagger, so I will pay close attention to the nexts posts 😉 Thanks!

  3. RandomAndroidGuy

    Good job! I have a hope that next parts will be this same clear for users which doesnt have big experience in programming.

  4. In your example of testing doSomething without testing doSomethingElse, how does injecting module2 not still test doSomethingElse? The call to doSomethingElse is still there inside doSomething.

    1. When you unit test Module1, you will construct an instance of it with a mocked version of Module2. The doSomethingElse method in this mocked version of Module2 will return a value you would expect from the implementation of doSomethingElse but without going through the process of computing it. So you would be testing Module1 under the assumption that Module2#doSomethingElse returns what its documentation says it would. Whether Module2#doSomethingElse works correctly or not would be tested separately in a unit test for Module2.

  5. very good.
    I have one question, is it have an impact regarding proguard(LineNumberTable) using Dagger? Because it uses pre-compiler, after compiling, I think the line numbers are different from what it looks like in source code, is it?

    1. Antonio Leiva

      It creates some support classes to work, but won’t touch yours, so you shouldn’t have any problems with proguard.

  6. Great post. Easy to understand and right to the point. Still not sure when to use it though. MVP is a much needed design pattern for any Android app. I understand now from your post why I should be aware of dependencies, I was not even thinking of this before. But I feel like I could avoid this problem with better coding rather than learning Dagger… which means I probably still don’t understand fully what you’ve written. I guess I will read the post again!

  7. Okay now I fully understand and am using the MVP dagger framework in my app!! Thanks this is so helpful to the android community. Truly a blessing to have well documented projects ! Suggestion for your next project would be unit testing the presentation or model layer with Mockito or something like that.

Comments are closed.