Hello everyone :raised_hand_with_fingers_splayed:!...

# dagger

[Christopher Elías]

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:

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

[trevjones]

IMO go have a look at how dagger-android works using map multibindings to abstract the lookup of the component

[trevjones]

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

[Christopher Elías]

Uhm, do you have any sample?

[trevjones]

basically right now dagger android does this:

(applicationContext as HasAndroidInjector).inject(this)

[trevjones]

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.

[trevjones]

BUT if you instead did something like

(applicationContext as InjectorRegistry).findInjector(this).inject(this)

[trevjones]

damn markdown enter behavior....

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...

[trevjones]

I suppose it is just a more separate service location pattern split out of the call to inject