Dependency injection with Hilt in Android Kotlin - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to annotate the Application class for Hilt.

Android Kotlin

@[1]
class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
    }
}

Drag options to blanks, or click blank then click option'

A@Inject

B@HiltAndroidApp

C@AndroidEntryPoint

D@Module

Attempts:

3 left

💡 Hint

Common Mistakes

Using @Inject instead of @HiltAndroidApp on the Application class.

Forgetting to annotate the Application class at all.

The @HiltAndroidApp annotation tells Hilt to generate components for dependency injection in the Application class.

2fill in blank

medium

Complete the code to inject a dependency into an Android Activity using Hilt.

Android Kotlin

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    @[1]
    lateinit var repository: UserRepository

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
    }
}

Drag options to blanks, or click blank then click option'

A@Module

B@Provides

C@Inject

D@Singleton

Attempts:

3 left

💡 Hint

Common Mistakes

Using @Provides instead of @Inject for field injection.

Not annotating the Activity with @AndroidEntryPoint.

The @Inject annotation tells Hilt to provide the dependency instance into the field.

3fill in blank

hard

Fix the error in the Hilt module by completing the annotation to provide a singleton instance.

Android Kotlin

@Module
@InstallIn(SingletonComponent::class)
object AppModule {
    @Provides
    @[1]
    fun provideDatabase(@ApplicationContext context: Context): AppDatabase {
        return Room.databaseBuilder(context, AppDatabase::class.java, "app_db").build()
    }
}

Drag options to blanks, or click blank then click option'

ASingleton

BProvides

CInject

DBinds

Attempts:

3 left

💡 Hint

Common Mistakes

Using @Provides alone without @Singleton for shared instances.

Using @Inject on provider functions.

The @Singleton annotation ensures that Hilt provides a single instance of the database throughout the app.

4fill in blank

hard

Fill both blanks to create a Hilt module that binds an interface to its implementation.

Android Kotlin

@Module
@InstallIn(SingletonComponent::class)
abstract class RepositoryModule {
    @Binds
    abstract fun bindUserRepository(
        [1]: UserRepositoryImpl
    ): [2]
}

Drag options to blanks, or click blank then click option'

AuserRepositoryImpl

BUserRepository

CuserRepository

DUserRepositoryImpl

Attempts:

3 left

💡 Hint

Common Mistakes

Using the interface name as the parameter name.

Swapping the parameter and return types.

The function parameter name is usually camelCase of the implementation class, and the return type is the interface to bind.

5fill in blank

hard

Fill all three blanks to create a Hilt module that provides a Retrofit instance with a base URL.

Android Kotlin

@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {
    @Provides
    @Singleton
    fun provideRetrofit(): Retrofit {
        return Retrofit.Builder()
            .baseUrl([1])
            .addConverterFactory([2])
            .client([3])
            .build()
    }
}

Drag options to blanks, or click blank then click option'

A"https://api.example.com/"

BGsonConverterFactory.create()

CScalarsConverterFactory.create()

DOkHttpClient()

Attempts:

3 left

💡 Hint

Common Mistakes

Using a wrong URL format without quotes.

Using the wrong converter factory.

Confusing client creation with converter factory.

The baseUrl is a string URL, the converter factory is GsonConverterFactory, and OkHttpClient is often used but here the blank is for the client setup (though not shown in code, the third blank is for client).

Practice

1. What is the primary purpose of using @HiltAndroidApp annotation in an Android application?

easy

A. To inject dependencies into a ViewModel

B. To mark an Activity as injectable by Hilt

C. To trigger Hilt's code generation and setup the application-level dependency container

D. To define a module that provides dependencies

Solution

1. Step 1: Understand the role of @HiltAndroidApp

   This annotation is placed on the Application class to start Hilt's code generation and create the application-level dependency container.

2. Step 2: Differentiate from other annotations

   @AndroidEntryPoint marks Activities or Fragments, @Module defines providers, and @Inject is for injection points, so they do not setup the application container.

3. Final Answer:

   To trigger Hilt's code generation and setup the application-level dependency container -> Option C

4. Quick Check:

   @HiltAndroidApp = Setup app container [OK]

Hint: Remember: @HiltAndroidApp is only on Application class [OK]

Common Mistakes:

• Confusing @HiltAndroidApp with @AndroidEntryPoint
• Thinking @HiltAndroidApp is for Activities
• Using @HiltAndroidApp on modules

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 lateinit var for the dependency

B. Use @Module annotation on the Activity and call inject() manually

C. Add @HiltAndroidApp on the Activity and initialize dependencies in onCreate()

D. Declare dependencies as constructor parameters without annotations

Solution

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

   Using @AndroidEntryPoint on the Activity allows Hilt to generate necessary code for injection.

2. Step 2: Inject dependencies inside Activity

   Use @Inject lateinit var to declare dependencies that Hilt will provide automatically.

3. Final Answer:

   Annotate the Activity with @AndroidEntryPoint and use @Inject lateinit var for the dependency -> Option A

4. Quick Check:

   @AndroidEntryPoint + @Inject lateinit var = Activity injection [OK]

Hint: Use @AndroidEntryPoint on Activity and @Inject lateinit var inside [OK]

Common Mistakes:

• Trying to use @Module on Activity
• Forgetting @AndroidEntryPoint annotation
• Injecting dependencies via constructor in Activity

3. Given the following Hilt module code, what will be the output when repository.getData() is called?

@Module
@InstallIn(SingletonComponent::class)
object DataModule {
    @Provides
    fun provideData(): String = "Hello Hilt"
}

class Repository @Inject constructor(private val data: String) {
    fun getData() = data
}

medium

A. "DataModule"

B. Compilation error due to missing @Inject on Repository

C. NullPointerException at runtime

D. "Hello Hilt"

Solution

1. Step 1: Understand the provided dependency

   The module provides a String "Hello Hilt" via the provideData() function.

2. Step 2: Check Repository injection

   Repository constructor is annotated with @Inject and receives the String dependency correctly.

3. Final Answer:

   "Hello Hilt" -> Option D

4. Quick Check:

   Provided String = "Hello Hilt" [OK]

Hint: Look for @Provides return value matching injected type [OK]

Common Mistakes:

• Assuming @Inject missing on Repository causes error (it is present)
• Confusing module name with provided value
• Expecting runtime null error without reason

4. Identify the error in the following Hilt setup:

@Module
@InstallIn(ActivityComponent::class)
object NetworkModule {
    @Provides
    fun provideRetrofit(): Retrofit {
        return Retrofit.Builder().baseUrl("https://api.example.com").build()
    }
}

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    @Inject lateinit var retrofit: Retrofit

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
    }
}

medium

A. Retrofit cannot be provided in ActivityComponent scope because it should be Singleton

B. Missing @Inject constructor in Retrofit class

C. MainActivity must be annotated with @HiltAndroidApp

D. Retrofit instance must be created manually, not with @Provides

Solution

1. Step 1: Check the component scope for Retrofit

   Retrofit is usually a singleton because it is expensive to create and shared across app.

2. Step 2: Analyze the module's @InstallIn scope

   The module is installed in ActivityComponent, which creates a new instance per Activity, not singleton.

3. Step 3: Identify the mismatch

   Providing Retrofit in ActivityComponent scope causes multiple instances, which is incorrect for Retrofit.

4. Final Answer:

   Retrofit cannot be provided in ActivityComponent scope because it should be Singleton -> Option A

5. Quick Check:

   Retrofit = Singleton scope needed [OK]

Hint: Provide expensive objects in SingletonComponent scope [OK]

Common Mistakes:

• Thinking Retrofit needs @Inject constructor
• Confusing @HiltAndroidApp with @AndroidEntryPoint
• Believing manual creation is required with @Provides

5. You want to inject two different implementations of an interface Logger using Hilt in your Android app. Which approach correctly distinguishes these implementations for injection?

hard

A. Provide both implementations in the same module without qualifiers and inject List<Logger>

B. Use @Qualifier annotations with different names on each provider and injection site

C. Use @Singleton on both implementations and inject Logger directly

D. Create separate modules for each implementation without any annotations

Solution

1. Step 1: Understand multiple implementations injection

   When multiple implementations of the same interface exist, Hilt needs a way to distinguish them.

2. Step 2: Use @Qualifier annotations

   Custom @Qualifier annotations with different names allow Hilt to know which implementation to inject where.

3. Step 3: Reject other options

   Injecting List<Logger> is possible but does not distinguish single injection points; @Singleton does not differentiate implementations; separate modules without qualifiers cause ambiguity.

4. Final Answer:

   Use @Qualifier annotations with different names on each provider and injection site -> Option B

5. Quick Check:

   Multiple implementations = use @Qualifier [OK]

Hint: Use @Qualifier to name different implementations [OK]

Common Mistakes:

• Injecting interface without qualifiers causes errors
• Assuming @Singleton differentiates implementations
• Not using qualifiers when multiple providers exist