Dependency Injection Using Dagger 2 and Kotlin in Android

In my last post, i had written about using Retrofit2 in an weather application. I will be using the same application, and make use of Dependency Injection using Dagger2.

What is DI?

Wiki says, A dependency injection is a technique where in whereby one object supplies the dependencies of another object. An injection is the passing of the dependency to an dependent object.

It is a design pattern that allows us to remove the hard-coded dependencies and make our application loosely-coupled, extendable, maintainable and testable.

Basically, Dependency is when any class is dependent on another class, to perform it’s further task. And Injection is passing the dependency to the dependent class and Dependency Injection is a design pattern to provide injection such that your application is loosely-coupled, less boiler plate code, maintainable and testable.

How?

Add the Dagger2 dependencies in your app/build.gradle file.

Annotations used -

“@Inject” — Request for the required dependency.

“@Module” — Provides the dependency.

“@Component” — Connects the requesting class (where the DI has to happen) and the modules.

“@Scope” — Define the scope of the component.

“@Named” — Provide the same type of dependency with different names.

Coming back to the application. First, we need a module provider class, which will provide all the required dependency if requested from any class.

Few things to be noted here.

1. The class should be annotated with “@Module”
2. And the function which is providing the dependency creation should be annotated with “@Provides”
3. “@Singleton” means here that anytime “@Inject” gets called the singleton instance will be always provided by Dagger2. However, you can create your own custom scope as well.

Now, we need a component interface, which will be implemented by the Dagger2 and it will expose the required modules to outside world (Activities or Fragments).

This component will be implemented in Application class, and will be in the memory till application life-cycle. Basically, the common modules which are needed across the application, should reside here. Some common modules which should reside at application level are apiService, DbRepo, SharedPreference and etc.

Now, the same need to be implemented in the Application class.

In the above gist, applicationComponent is initialised and will reside in the memory until application dies. When the application is build, after creating any component, Dagger gives the concrete implementation of the same and the implemented class, is prefixed with the Dagger keyword.

So far so good..!!

Application level component is setup and the module it’s provide will be available across the application.

Now coming back to the ui module.

I have followed MVP architecture. My view is the HomeActivity and presenter is HomeActivityPresenter and the presenter communicates with the view via an interface HomeActivityView, which is implemented by the activity.

The basic idea behind MVP is that the presenter is the decision maker and it does all the logic stuff and the view just inflates the layouts. And the presenter should not hold any android specific resources, so that it can be unit tested on JVM.

In this project, the presenter will be making api calls, and on api success or failure, it will speak with the view via the interface provided.

Few things to be noted here

1. Presenter is dependent on apiService and homeActivityView without which it cannot work. (Well, we have taken care of the apiService at application level component). All, we need to do is take care of the homeActivityView interface.
2. Activity depends on presenter, as it needs presenter instance to invoke the method which initiates api call to get the weather data.

So, we need to provide apiService and homeActivity dependency to presenter and also we need to inject the required presenter in the activity.

Since, the apiService is already there in the object-graph at application level, let’s add the component which will provide the homeActivityView.

We will start with Module. Let’s create a module class, which will provide the homeActivityView.

Now, the component which will expose the same.

At this point, you need to build the project and the dagger will create the implementation of the HomeActivityComponent, with Dagger as prefix.

Now let’s initialise the component inside the activity and give it the required modules it needs.

And the homeActivityPresenter class.

Here “@PerActivity” is the custom scope for the homeActivity component and this component will get destroyed with the activity lifecycle.

And HomeActivityPresenter is injected using constructor injection.

Please check out the whole project here (dagger2 branch). I have also added the Expresso tests using Dagger and MockWebServer.

ritesh-singh/WeatherApplication

I would highly recommend to go through this presentation.

Thank you for your time..!!. Your suggestions and feedback's are welcome.

References

codepath/android_guides