Probably this is more a workaround that proper support for test module overriding, but it allows to override production modules with test one. The code snippets below shows simple case when you have just one component and one module, but this should work for any scenario. It requires a lot of boilerplate and code repetition … Read more
Usage in dependent components In the context of a hierarchy of dependent components, such as in this example, provision methods such as Foo foo() are for exposing bindings to a dependent component. “Expose” means “make available” or even “publish”. Note that the name of the method itself is actually irrelevant. Some programmers choose to name … Read more
Use @Singleton if you rely on singleton behavior and guarantees. Use @Reusable if an object would only be a @Singleton for performance reasons. @Reusable bindings have much more in common with unscoped bindings than @Singleton bindings: You’re telling Dagger that you’d be fine creating a brand-new object, but if there’s a convenient object already created … Read more
@Binds can be perfectly equivalent to a @Provides-annotated method like this: @Provides public HomePresenter provideHomePresenter() { return new HomePresenterImp(); } …though you’d probably prefer a variant that takes HomePresenterImp as a method parameter, which lets Dagger instantiate HomePresenterImp (assuming it has an @Inject constructor) including passing any dependencies it needs. You can also make this … Read more
Support for this use-case was removed in Retrofit2. The recommendation is to use an OkHttp interceptor instead. HostSelectionInterceptor made by swankjesse import java.io.IOException; import okhttp3.HttpUrl; import okhttp3.Interceptor; import okhttp3.OkHttpClient; import okhttp3.Request; /** An interceptor that allows runtime changes to the URL hostname. */ public final class HostSelectionInterceptor implements Interceptor { private volatile String host; public … Read more
@Module public class MainActivityModule { private final Context context; public MainActivityModule (Context context) { this.context = context; } @Provides //scope is not necessary for parameters stored within the module public Context context() { return context; } } @Component(modules={MainActivityModule.class}) @Singleton public interface MainActivityComponent { Context context(); void inject(MainActivity mainActivity); } And then MainActivityComponent mainActivityComponent = DaggerMainActivityComponent.builder() … Read more
Run your application with ./gradlew clean build command to see what’s exactly wrong with your code. Just paste it into the Terminal in Android Studio.
You can use an Application context which is provided by the AndroidViewModel, you should extend AndroidViewModel which is simply a ViewModel that includes an Application reference.
As for your question What determines the lifecycle of a component (object graph) in Dagger 2? The short answer is you determine it. Your components can be given a scope, such as @Scope @Retention(RetentionPolicy.RUNTIME) public @interface ApplicationScope { } @Scope @Retention(RetentionPolicy.RUNTIME) public @interface ActivityScope { } These are useful for you for two things: Validation … Read more
AppModule.kt: Provide the application context. No need to write @singleton @provides for your Test* classes (will see why) @Module class AppModule { @Provides @Singleton fun provideApplication(app: App): Context = app.applicationContext } AppComponent.kt: @Component.Builder is deprecated IIRC. Use @Component.Factory. And replace AndroidInjectionModule::class with AndroidSupportInjectionModule::class since we are using dagger-android-support and android’s *Compat* stuff. Refer a new … Read more