https://kotlinlang.org logo
#dagger
Title
# dagger
c

Christopher Elías

12/10/2020, 2:21 PM
Hello everyone 🖐️! Question, Im getting into a feature modularization architecture with pure dagger, no dagger-android, no hilt, just dagger. While my modules grow my application class is starting to look like this:
Copy code
class 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-module
t

trevjones

12/16/2020, 10:41 PM
IMO go have a look at how dagger-android works using map multibindings to abstract the lookup of the component
the main issue in my mind with dagger android is that by default you don't have anyway to customize how the injection lookup works
c

Christopher Elías

12/17/2020, 3:09 PM
Uhm, do you have any sample?
t

trevjones

12/31/2020, 9:13 PM
basically right now dagger android does this:
Copy code
(applicationContext as HasAndroidInjector).inject(this)
which means you can only have a single way to inject a given activity. behavior is similar for fragments but that fragments will walk the fragtivity hierarchy before going for the application and requires the first HasAndroidInjector is the thing to inject it.
BUT if you instead did something like
Copy code
(applicationContext as InjectorRegistry).findInjector(this).inject(this)
damn markdown enter behavior....
Copy code
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...
I suppose it is just a more separate service location pattern split out of the call to inject
2 Views