Modules, @Provides et @Binds

You cannot add @Inject to a constructor you do not own, like a Retrofit or OkHttp instance. Hilt needs another way to learn how to build those.

A module is a class that teaches Hilt how to create types it cannot construct on its own. Mark it with @Module to register it.

Every module declares where it lives with @InstallIn. SingletonComponent makes its bindings available app-wide for the whole process.

@Provides marks a function whose return value Hilt will use as a dependency. The function body shows exactly how to build it.

A @Provides function can ask for other dependencies as parameters. Hilt supplies them first, then runs your function to assemble the result.

When you just need to map an interface to an implementation, @Binds is leaner than @Provides. It tells Hilt which class satisfies the interface.

Because @Binds methods are abstract, their module must be an abstract class, not an object. The implementation must already be injectable.

Use @Binds for a simple interface-to-class mapping, and @Provides when you must run code to build the object. Binds generates less code.

Add @Singleton to a provider so Hilt creates the object once and reuses it. Perfect for heavy clients like a shared OkHttp instance.

If two providers return the same type, a @Qualifier annotation tells them apart. Hilt then knows which binding each injection point wants.

Together your modules form the dependency graph. Hilt reads them at compile time and wires every type into a connected, verified tree.

You saw that modules teach Hilt how to create types it cannot construct, using @Provides for code and @Binds for interface mappings. 🧩