Runtime swap implementation for Dagger provided dependency [duplicate] - dagger-2

Question

This question already has answers here:
How do I tell Dagger 2 which implementation to instantiate based on X?
(3 answers)
Closed 5 years ago.
Using Dagger 2, I have a domain object that I provide to presenters. That domain object has a dependency on a repository. That repository has two implementations, but both implement the same interface. I need to be able to setup dagger somehow to swap between the two implementations of the repository at runtime based on a user selecting a "Demo Mode" option.
So I have the following domain object:
public class SomeAwesomeBusinessLogic {
Repository repository;
#Inject
public SomeAwesomeBusinessLogic(Repository repository) {
this.repository = repository;
}
//awesome stuff goin down
}
And the two repositories:
public RemoteRepository implements Repository {
#Inject
public RemoteRepository() {
//setup
}
}
public DemoRepository implements Repository {
#Inject
public DemoRepository() {
//setup
}
}
Any ideas on how to structure my modules and components to get this to work?

Answer 1

A couple of ideas come to my head. Depending on how and when you want to exchange this. One possibility is to instantiate your module with a configuration. Can be a simple boolean:
#Module
public class RepositoryModule {
private final boolean isDemo;
public RepositoryModule(boolean isDemo) {
this.isDemo = isDemo;
}
#Provides
public Repository providesRepository() {
return isDemo? new DemoRepository() : new RemoteRepository();
}
// Other providers
}
I'm not a fan of this approach, but it fits your use case. I believe it's quite restrictive and doesn't allow for easy maintainability. I would perhaps choose to use a factory and provide the factory instead of the repo itself.
public interface RepositoryFactory {
Repository getRepository(Configuration configuration);
}
public class RepositoryFactoryImpl implements RepositoryFactory {
#Inject
public RepositoryFactoryImpl() {}
// The implementation
}
#Module
public class RepositoryModule {
#Provides
public RepositoryFactory providesRepositoryFactory(
RepositoryFactoryImpl factory) {
return factory;
}
// Other providers
}
Configuration would be a simple POJO where you can specify several attributes to configure your repo. Say for example:
public class Configuration {
private final boolean isDemo;
// all the POJO stuff you need
}
You can then make your domain object depend on the factory:
public class SomeAwesomeBusinessLogic {
private final RepositoryFactory repositoryFactory;
#Inject
public SomeAwesomeBusinessLogic(
RepositoryFactory repositoryFactory) {
this.repositoryFactory = repositoryFactory;
}
//awesome stuff going down
}
You can then do repositoryFactory.getRepository(new Configuration(true/false)); in your business logic.
I prefer this approach because it's easier to extend to new types of repos. You can also test if the factory logic is correct. No one usually tests dagger modules, that's why I'm not so keen on the first approach.
Another good thing is that this approach allows you to keep the same module instance if there's a possibility to change the app's configuration and suddenly change to a demo repo, by providing a different Configuration object to the factory.
A third possibility might be Producers. However, this really depends on your use case and how you want to handle this runtime dependency exchange. I find this approach quite good, but it might be a bit overkill.
Hope this helps