Thread
#dagger
    Jovan

    Jovan

    2 years ago
    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, 😮nboarding, :core as features, where :app depends on 😮nboarding and :core.😮nboarding 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?
    I read a lot and you can’t find one proposal, everyone have a different approach which is, I guess, ok.
    t

    trevjones

    2 years ago
    thats how i've always done it, works fine in my experience.
    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.
    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

    Jovan

    2 years ago
    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

    wasyl

    2 years ago
    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
    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

    Jovan

    2 years ago
    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

    wasyl

    2 years ago
    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

    Jovan

    2 years ago
    Got it, thanks. 🙂