New Android Injector with Dagger 2 — part 3
If you didn’t read part 1 and part 2, I suggest you to read them first. You can find links at the bottom.
You can use DaggerActivity, DaggerFragment, DaggerApplication to reduce boilerplate in your Activity/Fragment/Application.
Also you can use AndroidInjector<T> in your dagger components to reduce boilerplate too.
DaggerAppCompatActivity and DaggerFragment
Remember that we call AndroidInjection.inject() every activity or fragment that we wanted to use dagger. And also, If you want to use Injection in your fragment, you should also implement HasSupportFragmentInject interface and override fragment injector in your activity.
Recently, I moved that code to my base activity and base fragment. Why should I need to declare that for every single activity? I think moving them to base class is acceptable.
Then I see some classes in dagger project while researching, DaggerAppCompatActivity and DaggerFragment. These classes does exactly what I did. Android loves inheritance. So we can pretend it like we love that too 😛
Let’s see what is happening inside these library classes.
Nothing different actually. We can reduce boilerplate code in our activity by extending our activity from DaggerAppCompatActivity.
Our DetailActivity class was like following;
Let’s extend it from DaggerAppCompatActivity and remove HasSupportFragmentInjector and overrided method from our activity.
Now, It is better.
DaggerApplication, AndroidInjector, AndroidSupportInjectionModule
Let’s see what else we can do to reduce boilerplate code. AndroidInjector helps us to simplify our App Component. You can check AndroidInjector documentation from here.
Let’s see our app component and application class.
build() and seedInstance() is already defined in AndroidInjector.Builder class. So we can get rid of them and extend our Builder from AndroidInjection.Builder<Application>.
And also, AndroidInjector interface has inject() method in it. So we can remove inject() method and extend our AppComponent interface from AndroidInjector<Application>
So, our updated and boilerplate-reduced AppComponent interface will be look like following
Did you realise that we changed our modules too. I removed AndroidInjectionModule.class in component modules and added AndroidSupportInjectionModule.class. This is added because we used support Fragment. AndroidInjectionModule binds your app.Fragment to dagger. But If you want to use injection in v4.fragment then you should add AndroidSupportInjectionModule.class to your AppComponent modules.
We changed to way we inject into our AppComponent. So let’s see what is changed in our Application class.
Just like in the DaggerActivity and DaggerFragment, we also need to extend our Application class from DaggerApplication.
Our Application class was look like following;
We changed it to..
You can find this simplified implementation as a branch in my github page. I am not merging that into master because I want to show the old school way to use dagger in every branch. So readers can follow up a road from old-school way to simplified way.
dagger-android-injection - Sample project explains Dependency Injection in Android using dagger-android framework.
New Android Injector with Dagger 2 — part 1
Dagger 2.10 released with android support module and android compiler. I think this was a huge change for us and all…
New Android Injector with Dagger 2 — part 2
I tried to explain dagger-android injection in my previous blogpost. I got some review and people say that it is too…
I am not saying this is the “best practice”. This is just the way I implement dagger to my projects. So You can keep your dagger implementation as is. Maybe you don’t want to put some third party implementation to your application class hierarchy. It is up to the developer. I am open for any suggestion and please don’t hesitate to comment!