Thomas Kioko

Thomas Kioko

Android Architecture Components Part 2 – Dependency Injection

As promised, part two is here. ? Before we get our hands dirty, let’s do a quick recap. In the previous post, we created a simple app that displays a list of user names using Android architecture components library. We divided our app into the following layers for better code responsibility and separation of concerns:

View/UI layer

ViewModel layer

This worked pretty well but our data was hard coded. In this series, we will setup Retrofit for API Calls & Dagger 2 to add Dependency Injection to our app and use TMDB API to get some data. With that said, our new architecture will look like below.

Before We Begin …

Who the hell is Dagger and what is Dependency Injection? Worry not we will walk through this first. So let’s define some terms.

Dependency: This is when a class has a dependency on another class, if it uses an instance of this class. We call this a _class dependency.

Dependency Injection: Also known as DI. Dependency Injection is a technique whereby one object supplies the dependencies of another object. This means an object creating its dependendencies via new operator is strictly prohibited.

AppModule

Now that we have the Network module created, we can create an app module that will now ensure we have a singleton for our API service interface. If you’ve not used Retrofit, the interface defines API endpoints. It simply looks like this.

Here’s how the NetworkModule looks like. We’ve added the NetworkModule and ViewModelModule to the AppModule.

Note:
The method names for the providers, such as provideTmdbService(), provideRetrofitClient(), are not important and can be named anything you like. Dagger only looks at the return type.

Create Components

We only have one component at the moment AppComponent.

We’ve specified the modules we want to be used with the component inside the @Component annotation.

Boom. We are done setting up our dagger. ?

Let The @Injection Begin

Now that we have all our dependencies set up, let’s use them.

1. Application Class

We need to initialize the dependency graph for our application by using the Component. This is pretty simple in Dagger 2.

AppInjector.init(this);

Don’t forget to add property android:name=".TmdbApp" to the tag in AndroidManifest.xml file.

2. TmdbRepository Class

I’ve created a class TmdbRepository in the repository package that is responsible for making API requests and returning data to our ViewModels.

We’ve used @Inject annotation on TmdbRepository constructor which in turn tells Dagger that to use the constructor to create an instance of TmdbService. This adds this class to the Dependency Graph.

3. MainActivityViewModel Class

As discussed earlier, using @Inject annotation on MainActivityViewModel constructor which in turn tells Dagger that to use the constructor to create an instance of TmdbRepository.

By doing so, the ViewModel does not care how we get out data. It just wants data from our repository.

Wrapping it up

Dagger can be a bit of a pain when starting but don’t let it get to you. Dependency injection becomes useful when implementing proper testing into your app, allowing mock implementations of back-end APIs and data repositories to be used in testing.

There’s much more to learn about in Dagger 2 and its usage, including:

Scopes

Subcomponents

Testing with Mockito

In the next series, well look at setting up the UI and maybe writing some tests. In the meantime, happy injecting.