Setup, Modules & Scopes

Dagger Underneath, Android-Shaped on Top

Hilt is Android's officially recommended DI library, built on top of Dagger — it uses Dagger's compile-time dependency graph generation while providing a standardized component hierarchy matching Android's own lifecycle (Application, Activity, Fragment, ViewModel), so typical apps no longer hand-design their own Dagger components.

Entry Points

@HiltAndroidApp
class MyApp : Application()

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

@HiltAndroidApp on the Application class triggers Hilt's code generation, setting up the root dependency container. @AndroidEntryPoint opts an Activity/Fragment into DI — necessary because the OS (not app code) instantiates these classes, so Hilt needs a hook into their lifecycle to inject dependencies.

Modules: @Provides vs. @Binds

@Module
@InstallIn(SingletonComponent::class)
abstract class RepositoryModule {
    @Binds
    abstract fun bindUserRepository(impl: UserRepositoryImpl): UserRepository

    companion object {
        @Provides
        fun provideRetrofit(): Retrofit = Retrofit.Builder()...build()
    }
}

Constructor injection (@Inject on a constructor) works for classes you own. A module bridges the gap for what you don't: @Binds tells Hilt which implementation satisfies an interface without writing a method body; @Provides manually constructs something requiring real logic (a third-party class, a configured builder). @InstallIn ties a module's bindings to a specific component/scope in the hierarchy.