Ease up Android Dependency Injection with Dagger 2.22.1(tips and tricks) — Kotlin

5 min readApr 17, 2019

Recently I went through an app upgrade which internally manages dependencies with Dagger 2.10. I’ve upgraded it to Dagger 2.22.1 where many life saver annotations are added to minimize boiler code and managing components and modules. Here, we go through implementing the latest Dagger from scratch with live coding in Kotlin

First, the dependencies for Dagger(versions.gradle):

def versions = [:]
versions.dagger = "2.22.1"def dagger = [:]
dagger.dagger = "com.google.dagger:dagger:$versions.dagger"
dagger.compiler = "com.google.dagger:dagger-compiler:$versions.dagger"
dagger.android = "com.google.dagger:dagger-android:$versions.dagger"
dagger.androidsupport = "com.google.dagger:dagger-android-support:$versions.dagger"
dagger.processor = "com.google.dagger:dagger-android-processor:$versions.dagger"
deps.dagger = dagger

I manage all versions through versions.gradle(you can google it and see how it works, much cleaner and better from common version management in Gradle)

The best way to understand how Dagger works is, to draw the dagger graph(tree), The graph is simply a representation of your app structure.

The application node is the main node of the graph, it’s a starting point which your graph will be drawn(don’t worry about black spots, they born soon like “a Star is born”).

So for having “Application” node we need to have the following class(recommend in the root of java src folder)

The 1, the application which here I called it “EmployeeApp”, it should be inherited from “DaggerApplication”.

Technically you can just inherit from android “Application” but you need to implement all methods that Dagger needed on it. You can have a look into “DaggerApplicaiton” and see how much Dagger is nice to us!

The 2, This is the “Component” that Dagger graph MUST have as a second node as shown before

We need to the following interface(again, Kotlin is cool)

The 1, “AndroidSupportInjectionModule::class” module should be installed, it is part of Dagger deal to have the android framework. (copy from the docs, ”Contains bindings to ensure the usability of {dagger.android} framework classes.”)

why “::” class, well it called metaprogramming which is the same as an “AndroidSupportInjectionModule.class” in java world.

The 2, it will inject the component to “Application”. in other words, it connects the “Application” circle into the “Component” circle in our graph image.

The abstract class name can be any name that you want but in the older version, it should be exactly the same name as annotation name.

be mindful that it will be a Singelton(“@Singelton”) and just only one instance of it will be available
This is it was a devil before in version 2.21, believe me, I fixed and it just was a matter of the luck. So you can find it more on the release version notes. Luckily they fixed it by this annotation “@Component.Factory”.

We now have the first two main nodes and press the build and lets the Dagger generated all necessary classes.

Then you will see the red “DaggerEmployeeAppComponent” to white which means it resolved

any name that you have for your app component it will be append by “Dagger” as a prefix(I know why, well show-off ;) )

Hopefully so far so good at your IDE. Let's go and can move our torch on next black spot.

Our app just will show employee information on the first activity in the ugliest way.

So we need to have our app first module like this:

The 1, this is a module and it should be annotated by “@Module”, the naming convention, follow app name plus module in the suffix.

The 2, It will provide context and it should be ”@Singleton” as we have one only one and one context for our app( it’s totally different activity context, this is in the app level)

then we can update our graph by adding the app module on it

We almost there and we need to add other nodes in the graph to handle dependencies for having employee information on the app.

So let’s create a module that related to the activity that we want to shows our employee info.

The 1, “@ContributesAndroidInjector” that as it says lets your activity module contributes with the injector, in simple words, it let your activity module generate a provider for the main activity.

The 2, “Main Activity” is just an activiy but with a big difference, it inehrit from “DaggerAppCompatActivity” instead of typical “AppCompatActivity” like the following(bear in mind the “Inject” part :) )

why “DaggerAppCompatActivity”? have a look at it and you will see how nice it is. It implemented all Dagger config for an activity(Dagger prime goal for each version reduces the boiler code)

Let’s update our app module with this new module(MainActivityBuilder)

The only one spot left in our graph and let's discover what is it.

Now, we need to lets our activity module knows how can get an employee info object. To do this, we create a module just return back us a fresh instance of our employee class as shown below