Christopher Elías
12/10/2020, 2:21 PMclass MyApp(): Application(), LoginComponentProvider, RegisterComponentProvider, RecoverPasswordComponentProvider {
// Reference to the application graph that is used across the whole app
val appComponent by lazy {
// Creates an instance of AppComponent using its Factory constructor
// We pass the applicationContext that will be used as Context in the graph
DaggerMyAppComponent.factory().create(applicationContext)
}
override fun provideLoginComponent(): LoginComponent {
return appComponent
.loginComponent()
.create()
}
override fun provideRegisterComponent(): RegisterComponent {
return appComponent
.registerComponent()
.create()
}
override fun provideRecoverPasswordComponent(): RecoverPasswordComponent {
return appComponent
.recoverPasswordComponent()
.create()
}
... On every new feature module I will have to implement its provider
}
Is any pattern or better way to improve this? Im doing this based on the official documentaton for dagger in android https://developer.android.com/training/dependency-injection/dagger-multi-moduletrevjones
12/16/2020, 10:41 PMChristopher Elías
12/17/2020, 3:09 PMtrevjones
12/31/2020, 9:13 PM(applicationContext as HasAndroidInjector).inject(this)
(applicationContext as InjectorRegistry).findInjector(this).inject(this)
interface InjectorRegistry {
fun <T : Any> findInjector(target: T): AndroidInjector<T>?
}
now you can customize/implement the lookup for YOUR needs. not just some one size fits all BS.
you can easily implement the dagger-android fragment dispatch behavior within a function that searches for an injector that works for a given instance. invent marker interfaces the registry can read to determine which implementation of a subcomponent to use based on fragtivity bundle arguments etc...