Dagger 2 for Android Beginners — Dagger 2 part I
This story is the fourth part of the series, Dagger 2 for Android Beginners. If you did not read the previous one, you can start from here.
- Dagger 2 for Android Beginners — Introduction
- Dagger 2 for Android Beginners — DI part I
- Dagger 2 for Android Beginners — DI part II
- Dagger 2 for Android Beginners — Dagger 2 part I (you’re here)
- Dagger 2 for Android Beginners — Dagger 2 part II
- Dagger 2 for Android Beginners — Dagger 2 Advanced part I
- Dagger 2 for Android Beginners — Dagger 2 Advanced part II
Previously on Dagger 2..
In the previous pitstop, we understood that the class should not create or have its dependencies on it. Instead, it needs to get it from outside.
We also saw the plan of simple dependency injection in action. We took the example of the battle of bastards and tried to eliminate the hard dependency on the class via DI.
Note: If you’re not comfortable with the way of my storytelling — keeping Game of Thrones as the concept, feel free to change the name of the classes when you proceed.
How can Dependency Injection get complicated?
If the project is as simple as our previous example, then instantiating and injecting a few dependencies manually on the main method is very reasonable. Most projects, however, have dozens of classes, each with various dependencies that need to be satisfied. Instantiating and wiring everything together requires a lot of code. Even worse, this code will constantly have to change every time a new class is added to the application or any time an existing class is modified to require a new dependency.
To illustrate this problem, let’s make our small example a little more complicated. In the war —
BattleOfBastards would probably require
Allies to support. Also,
IronBank would fund the houses or something. The modified main function would look like this:
Very quickly, the entry point for our application has started to become bloated with initialization code. To build a single Class, which is the object we actually care about, we had to manually instantiate numerous others. As the application grows and more classes are added, this main method will keep growing until it becomes completely unmanageable.
Dagger 2 comes to the rescue
Dagger 2 is one of the open source DI frameworks which generates a lot of boilerplate for us. But why is it better than the others? Right now it’s the only one DI framework which generates fully traceable source code in Java which mimics the code that user may write by hand. It means that there is no magic in dependencies graph construction. Dagger 2 is less dynamic than the others (no reflection usage at all) but simplicity and performance of the generated code are on the same level as the hand-written code. In short, Dagger 2 generates all the dependency injection boilerplate for you.
In other words, manually managing the dependency injection is like, mining the dragon glass — taking permission from the dragon queen and then forging them as weapons and then to go and fight with the White Walkers (hard dependency issues). Dagger 2 framework is like the valyrian swords — it’s been created by masters and all you need is to just wield it.
Understanding Annotation Processors
Annotations are the class of metadata, that can be associated with class, methods, fields and even other annotations. Annotations in Java are used to provide additional information, so it is an alternative option for XML and Java marker interfaces. These methods can also be accessed during the runtime via reflections.
Annotation processors are the code generators that eliminate the boilerplate code, by creating code for you during the compile time. Since it’s compile time, there is no overhead in the performance.
#Why should I know about Annotation Processors?
Dagger 2 works on Annotation processor. So all the code generation is traceable at the compile time. Hence you have no performance overhead and its errors are highly traceable.
You would have seen
@Override in your classes frequently— which is an annotation. Similarly, if you have used Butterknife, then
@BindView is also an annotation, carrying few metadata, which will help in generating the code for you.
Understanding Dagger 2 Annotations
There are few annotations in Dagger 2 API. Let’s visit them when we start working on each. Right now, let’s focus on 2 annotations —
First and the most important for DI is the
@Inject annotation. Part of JSR-330 standard marks those dependencies which should be provided by Dependency Injection framework.
- Constructor Injection — is used with class constructor
- Field Injection — is used with the fields in the class
- Method Injection — is used with the functions/methods
In other words, the
@Inject annotation will tell the Dagger what all the dependencies needed to be transferred to the dependant. It’s like the field agents of the iron bank, negotiate with the house and fix the amount of loan that they can provide.
This annotation is used to build the interface which wires everything together. In this place, we define from which modules (or other Components) we’re taking dependencies. Also here is the place to define which graph dependencies should be visible publicly (can be injected) and where our component can inject objects.
@Component, in general, is a something like a bridge between
@Module(Which we’ll be seeing later) and
In other words,
@Component annotations are the agent who is in charge of approving and transferring the loan amount to the respective accounts in the iron bank.
Killing WhiteWalkers with Valyrian Sword
Let’s use Dagger 2 for our
BattleOfBastards example. In our basic example, we need two dependencies for the class
Boltons. Then we’ll make the object of the
War available to all.
#Setting up Dagger 2
For setting up Dagger in IntelliJ Idea, refer the
build.gradle file of the following project branch. Also, make sure you enable the annotation processing under Preferences -> Build, execution and deployment -> Compiler -> Annotation Processing -> Enable annotation processing (should be checked)
Also, make sure Preferences -> Build, execution and deployment -> Gradle -> Runner ->Delegate IDE build/run actions to cradle (should be checked)
Dagger-2-For-Android-Beginners - Blog coming soon..github.com
#Adding @Inject Annotation
The plan is to make the dependencies —
Boltons inject into the Class
War. So we need to tell Dagger 2 that these are the dependencies that need to be injected. So we’ll be using the @inject annotation and let the API know. Here’s how we need to add it (we’re using constructor injection).
These two dependencies, go to the Class
War. Hence we need to mark it as inject in the
War class constructor as well.
The plan is to make the dependency or the object of the Class
Waravailable to all other classes. But for the Class
Warto function, you need the dependencies of the Class
Boltons) — only then it can engage.
#Adding @Component Annotation
As we saw earlier, the component is a bridge between the generated code and the dependencies. The components also tell Dagger, on how the dependency needs to be injected. For that, let’s create the interface
BattleComponent — inside the class
BattleOfBastards (it can be created separately as well).
BattleComponent interface will be implemented by the class that Dagger 2 will generate (yes, dagger 2 will create boilerplate for us) for us and the function
getWar() is expected to return the
War object so that we can use it in the appropriate place.
Now you need to rebuild the project!
After rebuilding, the Dagger 2 would have generated the class called
DaggerBattleComponent — this will help us inject the
War object. Now, let’s use this class to get the
DaggerBattleComponent class, we’re now able to use the method
getWar(), where this method, returns the object
War, which feeds the dependencies —
Congratulations!, you’ve now created your first project using Dagger 2. I really appreciate you for taking your time and reaching this far. It’s time to celebrate.
We discussed, how using DI manually will complicate our work and increase boilerplate codes. We then discussed how dagger 2 will take all our pain and generate the boilerplate itself.
Next, we ran through annotation processing basics and Dagger 2’s basic annotations (Inject and Component). Then we applied those annotations in our example and we injected the dependencies using Dagger 2.
On the next pitstop, we’ll play around with the generated dagger component class and we’ll see little more about other annotations of Dagger 2.
This story is the fifth part of the series, Dagger 2 for Android Beginners. If you did not read the previous one, you…medium.com
Please do checkout my other stories.
Thank you for using your precious time to reading this article. Liked it? Clap your 👏 to say “thanks!” and help others find this article.