Dependency injection with Hilt

The problem

A ViewModel needs a repository; the repository needs an API client and a database; the API client needs an HTTP client with settings. If each class creates its own dependencies with constructors inside, everything is tightly glued together: you cannot test the ViewModel with a fake repository, and the app may accidentally create three database instances.

The idea: pass dependencies in

// Hard to test: creates its own dependency
class OrdersViewModelBad : ViewModel() {
    private val repo = OrderRepository(RealApi(), RealDatabase())
}

// Easy to test: receives it (constructor injection)
class OrdersViewModel(private val repo: OrderRepository) : ViewModel()

This is dependency injection: dependencies are injected (given) from outside. You can do it by hand, by creating objects in one place (an AppContainer class) and passing them down. That is perfectly fine for small apps. As apps grow, a library like Hilt writes this wiring code for you.

Hilt setup in brief

// 1. The Application class
@HiltAndroidApp
class ShopApp : Application()

// 2. Activities that need injection
@AndroidEntryPoint
class MainActivity : ComponentActivity() { /* ... */ }

// 3. ViewModels
@HiltViewModel
class OrdersViewModel @Inject constructor(
    private val repo: OrderRepository,
) : ViewModel()

// 4. Classes Hilt can build itself
class OrderRepository @Inject constructor(
    private val api: OrderApi,
    private val dao: OrderDao,
)

An @Inject constructor tells Hilt how to create a class: by calling that constructor with the dependencies it needs. In Compose, get a Hilt ViewModel with hiltViewModel() instead of viewModel(). Register the Application class in the manifest with android:name=".ShopApp".

Modules for things you cannot annotate

Some objects come from libraries (Retrofit, Room), or are interfaces. You cannot add @Inject to their constructors, so you tell Hilt how to provide them in a module: an object with @Module and @InstallIn, containing @Provides functions (or @Binds for interfaces).

@Module
@InstallIn(SingletonComponent::class)        // lives as long as the app
object NetworkModule {
    @Provides
    @Singleton                               // one instance for the whole app
    fun provideOrderApi(): OrderApi =
        Retrofit.Builder()
            .baseUrl("https://api.example.com/")
            .addConverterFactory(/* JSON converter */)
            .build()
            .create(OrderApi::class.java)
}

Hilt checks the whole dependency graph at compile time. If something is missing, for example a repository needs an OrderApi that no module provides, the build fails with an error naming the missing type, instead of the app crashing later on a user's phone.

When to use Hilt

• Small learning app or a few screens: manual DI with a simple container is enough.
• Medium to large app, several developers, many repositories: Hilt saves a lot of wiring code and mistakes.
• Job interviews: Hilt (and the idea of DI) is commonly asked about in Android roles.

Common mistakes

• Forgetting @HiltAndroidApp or the manifest android:name entry: the app crashes at start.
• Forgetting @AndroidEntryPoint on the activity that hosts Hilt ViewModels.
• Using viewModel() instead of hiltViewModel() for a @HiltViewModel.
• Making everything @Singleton. Only share objects that really should be app-wide.