Hi guys. Recently I started working on new project...

# dagger

[Jovan]

Hi guys.
Recently I started working on new project and I wanted to start with mudularization right away.
So far so good, however, I had a hard time implementing Dagger. Here is the thing.
I have :app, :onboarding, :core as features, where :app depends on :onboarding and :*core*.
:onboarding depends only on :core. :core doesn’t have any dependency.

Regarding Dagger I have the following implementation.

@Module
class CoreModule {

    @Provides
    @AppScope
    fun provideLogger(): Logger {
        ...
    }

    @Provides
    @AppScope
    fun provideApiService(serviceHolder: ServiceHolder, OkHttpClientBuilder: OkHttpClientBuilder): APIService {
        ...
    }
}

@Component(
    modules = [
        AndroidSupportInjectionModule::class,
        CoreModule::class,
        MainActivityModule::class
    ]
)
@AppScope
interface AppComponent: AndroidInjector<MainApplication> {
    @Component.Factory
    interface Factory {
        fun create(@BindsInstance applicationContext: Context): AppComponent
    }
}

@Module
abstract class MainActivityModule {
    @ContributesAndroidInjector(modules = [OnBoardingModule::class])
    @ActivityScope
    abstract fun mainActivity(): MainActivity
}

@Module
abstract class OnBoardingModule {
    @ContributesAndroidInjector(modules = [SignInModule::class])
    abstract fun signInFragment(): SignInFragment
}

Am I breaking rules doing it like this?

[Jovan]

I read a lot and you can’t find one proposal, everyone have a different approach which is, I guess, ok.

[trevjones]

thats how i've always done it, works fine in my experience.

[trevjones]

although be weary of a module called 'core'. over time it can/will grow and become a bottleneck in your build. IMO: better to have lots of little focused modules always up-to-date/from-cache rather than one change to core and everyone needs to recompile. minimize visibility I guess.

[trevjones]

turns out lots of small focused libs ends up being a good way to start modularizing a monolith anyway so just try to set up for good splits, otherwise you end up with something like guava

[Jovan]

Thanks Trevor. I am aware of what you are saying(regarding modularization). :core is just an example here. I do have 3 “core” modules for now.
Thank you once again.

[wasyl]

My approach is to create a component per module. This way you have to define all dependencies to a subproject in the component factory and it leads to less accidental leaking of classes across projects

[wasyl]

And you will define everything that a subproject exposes. So you end up with a clear API of sorts for subprojects, where inputs are parameters in dagger components, and outputs are provisions declared in the components

[Jovan]

Lukasz if I understood you, I will have CoreComponent and OnBoardingComponent where OnBoardingComponent will depend on CoreComponent, right? If that is the case whouldn’t I then create CoreComponenet several times?

[wasyl]

No, you would create core component once (in app) and both use it directly and also pass the same instance to the onboarding component, if I understand correctly

[Jovan]

Got it, thanks. 🙂