Dependency injection with Hilt in depth in Android Kotlin

Introduction

Dependency injection helps you manage and provide objects your app needs without creating them manually. Hilt makes this easy and organized in Android apps.

When you want to share a single instance of a class across your app.

When you want to make your code easier to test by providing mock dependencies.

When you want to reduce boilerplate code for creating and passing objects.

When you want to manage complex object graphs automatically.

When you want to improve app modularity and separation of concerns.

Syntax

Android Kotlin

1. Add Hilt dependencies in build.gradle
2. Annotate Application class with @HiltAndroidApp
3. Use @AndroidEntryPoint on Activities/Fragments
4. Create @Module classes with @Provides or @Binds
5. Inject dependencies with @Inject constructor or @Inject fields

@HiltAndroidApp triggers Hilt code generation and should be on your Application class.

@AndroidEntryPoint allows Hilt to inject dependencies into Android components.

Examples

This sets up Hilt in your app by generating necessary components.

Android Kotlin

@HiltAndroidApp
class MyApp : Application()

Hilt injects UserRepository into MainActivity automatically.

Android Kotlin

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    @Inject lateinit var repository: UserRepository

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // repository is ready to use here
    }
}

This module tells Hilt how to create UserRepository using ApiService.

Android Kotlin

@Module
@InstallIn(SingletonComponent::class)
object AppModule {
    @Provides
    fun provideUserRepository(api: ApiService): UserRepository {
        return UserRepositoryImpl(api)
    }
}

Constructor injection lets Hilt provide ApiService automatically.

Android Kotlin

class UserRepository @Inject constructor(private val api: ApiService) {
    // Use api to get data
}

Sample App

This example shows a full setup: Hilt initializes in Application, provides ApiService, injects UserRepository into MainActivity, and prints data.

Android Kotlin

package com.example.hiltdemo

import android.app.Application
import android.os.Bundle
import androidx.activity.ComponentActivity
import dagger.Module
import dagger.Provides
import dagger.hilt.InstallIn
import dagger.hilt.android.HiltAndroidApp
import dagger.hilt.android.AndroidEntryPoint
import dagger.hilt.components.SingletonComponent
import javax.inject.Inject
import javax.inject.Singleton

// 1. Setup Hilt in Application
@HiltAndroidApp
class MyApp : Application()

// 2. Define a simple service
class ApiService {
    fun fetchData() = "Data from ApiService"
}

// 3. Create a repository that depends on ApiService
class UserRepository @Inject constructor(private val apiService: ApiService) {
    fun getUserData() = apiService.fetchData()
}

// 4. Provide ApiService in a module
@Module
@InstallIn(SingletonComponent::class)
object AppModule {
    @Provides
    @Singleton
    fun provideApiService(): ApiService = ApiService()
}

// 5. Inject UserRepository into Activity
@AndroidEntryPoint
class MainActivity : ComponentActivity() {
    @Inject lateinit var userRepository: UserRepository

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Use the injected repository
        println(userRepository.getUserData())
    }
}

Important Notes

Always annotate your Application class with @HiltAndroidApp to start Hilt.

Use @Singleton scope to share one instance across the app.

Use @Inject on constructors for automatic dependency provision.

Summary

Hilt simplifies dependency injection in Android by generating code for you.

Use @Module and @Provides to tell Hilt how to create dependencies.

Inject dependencies with @Inject in constructors or fields for easy access.

Practice

1. What is the primary purpose of using @Module and @Provides annotations in Hilt?

easy

A. To tell Hilt how to create and supply dependencies

B. To mark an Android Activity for injection

C. To automatically generate UI components

D. To define navigation between screens

Solution

1. Step 1: Understand the role of @Module

   @Module is used to group methods that provide dependencies to Hilt.

2. Step 2: Understand the role of @Provides

   @Provides annotates methods inside a module to tell Hilt how to create specific dependencies.

3. Final Answer:

   To tell Hilt how to create and supply dependencies -> Option A

4. Quick Check:

   @Module + @Provides = supply dependencies [OK]

Hint: Remember: @Module groups, @Provides creates dependencies [OK]

Common Mistakes:

• Confusing @Module with @AndroidEntryPoint
• Thinking @Provides creates UI elements
• Assuming @Module is for navigation

2. Which of the following is the correct way to inject a dependency into an Android Activity using Hilt?

easy

A. Annotate the Activity with @AndroidEntryPoint and use @Inject on the field

B. Use @Module on the Activity class

C. Call Hilt.inject(this) inside onCreate()

D. Add @Provides on the Activity constructor

Solution

1. Step 1: Identify how to enable injection in Activity

   Hilt requires the Activity to be annotated with @AndroidEntryPoint to generate necessary code.

2. Step 2: Inject dependencies with @Inject

   Fields or constructor parameters annotated with @Inject receive dependencies automatically.

3. Final Answer:

   Annotate the Activity with @AndroidEntryPoint and use @Inject on the field -> Option A

4. Quick Check:

   @AndroidEntryPoint + @Inject field = inject Activity dependency [OK]

Hint: Use @AndroidEntryPoint on Activity, then @Inject fields [OK]

Common Mistakes:

• Trying to use @Module on Activity
• Calling non-existent Hilt.inject() method
• Adding @Provides on constructors

3. Given the following code snippet, what will be the output when MyViewModel is injected?

class MyRepository @Inject constructor() {
    fun getData() = "Data from repository"
}

@HiltViewModel
class MyViewModel @Inject constructor(private val repo: MyRepository) : ViewModel() {
    fun fetch() = repo.getData()
}

medium

A. "fetch() method not found"

B. NullPointerException at runtime

C. Compilation error due to missing @Provides

D. "Data from repository"

Solution

1. Step 1: Understand constructor injection in MyRepository

   MyRepository has an @Inject constructor, so Hilt can create it automatically.

2. Step 2: MyViewModel receives MyRepository via constructor injection

   Hilt injects MyRepository instance into MyViewModel, so calling fetch() returns repo.getData() string.

3. Final Answer:

   "Data from repository" -> Option D

4. Quick Check:

   Constructor injection returns data string [OK]

Hint: If constructor has @Inject, Hilt creates instance automatically [OK]

Common Mistakes:

• Assuming @Provides is always needed
• Expecting runtime null errors with constructor injection
• Confusing method names in ViewModel

4. Identify the error in this Hilt module code:

@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {
    @Provides
    fun provideHttpClient(): OkHttpClient {
        return OkHttpClient()
    }

    @Provides
    fun provideRetrofit(client: OkHttpClient): Retrofit {
        return Retrofit.Builder()
            .client(client)
            .baseUrl("https://api.example.com")
            .build()
    }
}

medium

A. Missing @Singleton annotation on provider methods

B. Retrofit.Builder() requires a converter factory

C. OkHttpClient cannot be provided without parameters

D. NetworkModule should be a class, not an object

Solution

1. Step 1: Review Retrofit.Builder usage

   Retrofit requires a converter factory (like GsonConverterFactory) to parse responses; missing here causes runtime error.

2. Step 2: Check other options for correctness

   @Singleton is optional but recommended; object is valid for modules; OkHttpClient can be created without parameters.

3. Final Answer:

   Retrofit.Builder() requires a converter factory -> Option B

4. Quick Check:

   Retrofit needs converter factory to build properly [OK]

Hint: Retrofit always needs a converter factory to avoid errors [OK]

Common Mistakes:

• Thinking @Singleton is mandatory for all providers
• Confusing object vs class for modules
• Assuming OkHttpClient needs parameters

5. You want to inject two different implementations of an interface Logger using Hilt. How can you distinguish them during injection?

hard

A. Use @Singleton on one implementation and omit on the other

B. Create two separate modules with the same provider method name

C. Use @Named qualifiers with different names on provider methods and injection points

D. Inject both implementations into a list automatically

Solution

1. Step 1: Understand multiple implementations injection

   When multiple bindings exist for the same type, Hilt requires qualifiers to distinguish them.

2. Step 2: Use @Named qualifiers

   Annotate provider methods and injection points with @Named("name") to specify which implementation to inject.

3. Final Answer:

   Use @Named qualifiers with different names on provider methods and injection points -> Option C

4. Quick Check:

   Multiple implementations need @Named qualifiers [OK]

Hint: Use @Named("tag") to differentiate implementations [OK]

Common Mistakes:

• Assuming module separation alone distinguishes implementations
• Using @Singleton to differentiate implementations
• Expecting automatic list injection without setup