Hilt – Jetpack’s recommended DI solution for Android developers

Benefits of using Hilt in Android application development

Why Hilt? Hilt is an Android dependency injection (DI) library built on top of Dagger to make use of Dagger’s compile-time correctness, runtime efficiency, scalability, and Android Studio support. However, it provides a simpler way to integrate Dagger dependency injection into Android applications.

That’s why right now many companies are starting to take advantage of Hilt in their Android application development for it is more stable and easier to use.

Here are some benefits of using Hilt:

Jetpack integrations.

• Inject ViewModel objects with Hilt
• Integration with the Jetpack navigation library
• Integration with Jetpack Compose
• Inject WorkManager with Hilt

Very easy to set-up.

Developers can just add these dependencies to the app level gradle file

// Hilt implementation "com.google.dagger:hilt-android:2.38.1" kapt "com.google.dagger:hilt-compiler:2.38.1" implementation 'androidx.hilt:hilt-navigation-fragment:1.0.0'

// Hilt tests testImplementation 'com.google.dagger:hilt-android-testing:2.38.1' kaptTest 'com.google.dagger:hilt-android-compiler:2.38.1'

// Hilt UI tests androidTestImplementation 'com.google.dagger:hilt-android-testing:2.38.1' kaptAndroidTest 'com.google.dagger:hilt-android-compiler:2.38.1'

Then they will be able to use these annotations, and Hilt will be ready to get used:

Compile time DI (Dependency Injection). It has NO instantiation during runtime.

Easy for tests with only 1 annotations: @HiltAndroidTest

…But there are still some disadvantages found:

• It does not support FragmentScenario. UI testing still necessitates some boilerplate, however (solution provided by Google already)

• Because of Unclear logs, it is getting harder to debug.

How Hilt works under the hood

So how do the Hilt annotations work together to generate code?

Coming to the component lifetimes, there is a significant relation between the lifetimes of the components and the lifetimes of the bindings. For the reason that in the creation and destruction process of the components, it will limit the lifespan of scoped bindings. Besides it will show the proper time to use the members’ injected values.

In the table below, you can see what each component’s scope annotation and bounded lifetime are.

Simply adding Hilt modules

Hilt module is a class annotated with @Module that uses an additional @InstallIn annotation for determining which Hilt components will be in the installation process of the module.

Steps to add modules are uncomplicated. Fundamentally, developers need to annotate their module class with @Module and specify the component name where they want to install the module into. Let’s look at Interfaces for an example.

If you use repositories, you can use @Binds annotation. On the other hand for Providers, if you have some builders from other libraries like Retrofit, or Moshi, you can use @Provides annotation.

Testing set-up

Next thing to do is to set up to perform testing. In order to use the HiltTestApplication, developers need to configure a new test runner. This will consequently make Hilt work for all of the instrumented tests in the project.

Firstly, create a CustomTestRunner class that extends AndroidJUnitRunner. Then, override the newApplication function and pass the name of the HiltTestApplication that was generated. Further step, configure the test runner in the Gradle file to make sure that the full classpath is used.

How to deal with FragmentScenario

FragmentScenario provides an API to test fragment user’s interface. It works systematically with arbitrary fragments across various versions of Android framework.

There are a few easy steps to follow when implementing FragmentScenario:

Step 1: Add empty HiltTestActivity (debug) AndroidManifest.xml (debug)

Step 2: Use HiltExt with launchFragmentInHiltContainer extension function to launch fragment in container

Step 3: Run your test!