Binding interface and implementation without module

There’re cases when module provides only one object:

class BroadcastModule {
  @Provides
  open fun provideBroadcastBus(inst: BroadcastBusImpl): BroadcastBus = inst
}

And this seems like an overkill: create a module class to bind one implementation with interface for only one object.

Is there any plan to introduce some way to bind interface with implementation?

For instance annotation to generate such kind of modules:

class BroadcastBusImpl @Inject constructor():BroadcastBus {
  //methods
}

@Implementation(BroadcastBusImpl.class)
interface BroadcastBus{
  //methods
}

Or even better: if there is only one implementation then use it, so no need to have annotation or module declaration. And this behaviour could be probably used to replace modules which provide multiple objects, but still have one interface and implementation.

ps I don’t mean cases when interface is not needed. If it’s possible to use implementation then of course there is no problem.

[sczerwinski]

@JavierSegoviaCordoba yes, but it will take a few days before it’s ready. I can post a link when it’s ready.

EDIT: If anyone is still looking for an existing annotation processor generating Hilt modules, I’ve released an open source library that does that: https://github.com/sczerwinski/android-hilt#generating-hilt-modules

[bcorso]

It’s not feasible in Dagger, but it is definitely possible in Hilt (which is more similar to Anvil). However, we’ve been hesitant because the APIs for this aren’t great. We’ve had people write annotation processors on top of Hilt for this type of feature (internally) but even to handle only a subset of the use cases it ends up looking like this:

// Equivalent to:  @Binds @FooQualifier Foo<Bar> bind(FooImpl impl);
@ContributesTo(
  to = Foo.class,
  typeParameter = Bar.class,
  qualifier = FooQualifier.class,
  components = ApplicationComponent.class,
)
class FooImpl extends ... {...}

It looks like Anvil has intentionally left the API simple – it only handles cases where the class extends a single type that is the exact type you want to bind to. This might be fine for the majority of use cases though.

FWIW, we’re not opposed to someone else writing an annotation processor on top of Hilt to do this. It would be a pretty trivial annotation processor to replicate @ContributesTo. For example

@ContributesTo(ApplicationComponent.class)
class FooImpl implements Foo {...}

The annotation processor just needs to generate the module:

@Module
@InstallIn(ApplicationComponent.class)
interface FooImpl_ContributesTo {
  @Binds Foo bind(FooImpl impl);
}