Closed realityforge closed 4 years ago
After converting all of our applications we only found one reasonable place where this would be used so it is no longer considered of value. The main reason is that most services that have a single implementation are better off being modeled as a single @Injectable
without a service interface. When we integrate #10 into the auto-discovery there will be even potential motivation to support this functionality.
As this approach does increase the complexity and surface area of the library with limited return on complexity increase we have decided not to implement
In several scenarios we split the implementation and the interface and the dependencies depend upon the service interface. This typically means we need to define the implementation via:
And explicitly add the
MyImpl.class
to the set of includes for the injector or an included fragment. This means altering this global injector file which can be laborious. Another alternative is to define the interface via:When a component attempts to inject
MyService
, the annotation processor would auto-discover the injectable and add the binding to the injector. You could still override this auto-discovery process by explicitly binding a fragment or injectable that provides the service but it would simplify the default scenario.This should be added to the list of pros of Sting over Dagger