Dependency Injection With Hilt

Hi Guys !! in this article, we will achieve an abstract structure by using Hilt Dependency Injection for Database, Remote Data Source and Repository Classes that are dependent on each other.

Scenario

You are developing an android application. While the application, which was initially thought to be small in size, continues to develop, it starts to grow as each new feature is added. This growth makes it very difficult to work in interdependent Classes. This is where Dependency Injection comes to your aid. In this article, we will use Hilt, an important member of the Android Jetpack Library, as we will do automatic Dependency Injection.

Dependency Injection

Let’s make a short definition of the dependency injection example.

class Car {

    private val engine = Engine()

    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.start()
}

Let’s look at the flaws in this approach

• Car and Engine are tightly coupled
• Car is constructing its own engine, hence using different engine implementation is not easily possible
• Testing is difficult, as using a test double of engine for different use cases is not possible

Simple Solution

We can solve all the problems we mentioned above by doing Constructor Dependency Injection.

class Car(private val engine: Engine) {
    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val engine = Engine()
    val car = Car(engine)
    car.start()
}

Advantage of Dependency Injection Approach

• Now the car can be easily reused, as we can easily pass different implementations of the Engine While constructing the Car.
• Testing becomes easy, as now we can pass test doubles for testing Car.

However, we still do the Dependency Injection manually. Hilt comes into play here, and we can now do the operations we used to do with dagger2 automatically and easily.

While doing this project, I will continue on the Github repository in my previous article. Because you can see the OrderRepository dependency there, especially in the BasketFragmentViewModel. Now let’s abstract this dependency by Dependency Injection.

Preparation

We implement the necessary libraries in the Project Gradle file

plugins {
...
id 'dagger.hilt.android.plugin' version '2.40.5' apply false
}

App Gradle file

plugins {
...
id 'dagger.hilt.android.plugin'
}
...
dependencies {
...
implementation "com.google.dagger:hilt-android:2.40.5"
kapt "com.google.dagger:hilt-compiler:2.40.5"
}

Note: If you are using Gradle 7.1 if you get the error “id: ‘dagger.hilt.android.plugin’, version: ‘2.40.5’, apply: false] was not found in any of the following sources:” you can fix the problem by editing the setting.Gradle in this link. Don’t forget to change the version :)

This is what our Basket Fragment ViewModel Class looks like now before we do Dependency Injection with Hilt.

First, we need to create the Custom Application Class.

We need to declare it in the Application Androidmanifest we created. We attach the AppApplication by “name” in the <application> tag.

Now we say to the ViewModel Class “Hey you will be Dependency Injection with the constructor Inject method” because we are using the repository in the ViewModel Class. We declare this with @Inject annotation. Here we should also point out that the ViewModel is the Hilt ViewModel.

We do this in the Repository Class. Because we will do API and Database Dependency Injection.

Note: Here, API and DAO are used as interfaces. If you are DAO or API Class, you need to make @Inject constructor for them.

We create an AppModule Object. This Object is of type Singleton and will be in the scope of the whole application. You can do both Api and Room Database Inject operations in AppModule. Today we will see Room Database Inject. We create a Database instance in the Provide Product Database function here. Thanks to the annotation we created, Hilt automatically creates the rest for us.

Finally, we add @AndroidEntryPoint annotation to Fragment and Activity Classes where we will use the ViewModel.Now we can define our ViewModel inside the Basket Fragment.

That’s how easy it is to get rid of Repository dependencies. If you want to review the whole project, you can go to my GitHub repository. Thanks for reading, I hope I helped. See you next articles!