Dagger Android with multiple levels of (Sub)Components

[manuelvicnt]

I wonder if it's possible to have different levels of Components or Subcomponents using Dagger Android.

The idea is to abstract common Subcomponents data out to a common Component or Subcomponent.
Something like: ApplicationComponent -> CommonLoginSubcomponent -> LoginActivitySubcomponent

CommonLoginSubcomponent could be either a Subcomponent or a Component.

I tried implementing something like that and Dagger couldn't generate the Subcomponent Builder of LoginActivitySubcomponent from the CommonLoginSubcomponent that should've been used in the generated code of ApplicationComponent to inject the LoginActivity with the LoginActivitySubcomponent.

I assume this is not possible to do with Dagger Android right now. It seems like it only allows a level in the subcomponent hierarchy and doesn't allow having other Components including ApplicationComponent.

Is there any plans on implementing this solution in the future?
Ideally, an intermediate Component or Subcomponent would also be able to support the @IntoMap bindings between Activities and Subcomponent Builders.

[jhowens89]

I don't use Dagger Android and I have no idea if this solution will meet your needs, but I'll share a semi-similar setup I use in my project and you can determine if it's useful.

@Singleton
@Component
interface ApplicationComponent 

@SharedLogic
@Component(dependencies = arrayOf(ApplicationComponent::class).....)
interface XxxxxxxxSharedComponent {
	fun xxxxxx1Builder(): XxxxxxxxxComponent1.Builder()
	fun xxxxxx2Builder(): XxxxxxxxxComponent2.Builder()
	fun xxxxxx3Builder(): XxxxxxxxxComponent3.Builder()
}

@Feature
@Subcomponent
interface XxxxxxxxxComponent1

@Feature
@Subcomponent
interface XxxxxxxxxComponent2

@Feature
@Subcomponent
interface XxxxxxxxxComponent3

I have an intermediate XxxxxxxxSharedComponent that has ApplicationComponent as a dependency and only contains items that need to be shared across my other subcomponents and exposes the builders for them. Previously I used to have XxxxxxxxSharedComponent be a sort of parent component that had similar responsibilities as the subcomponents + more, but I found that this lead to the excess of @ParentXxxxxxXxxx and @ChildXxxxxxXxxxx like qualifiers. Now I leverage the encapsulation of the subcomponents and only provide instances in XxxxxxxxSharedComponent that I truly mean to share.

I hope that's somewhat helpful and I'd be happy to listen to others' thoughts and/or ideas for successful setups.

[manuelvicnt]

@jhowens89 that's definitely the type of approach I was expecting from Dagger Android. That's what I had in mind if I had to implement a custom solution. However, instead of SharedLogic, I'd group them by features: e.g. registration, login, feature1, feature2...

Thanks for commenting

[manuelvicnt]

Hi @ronshapiro

Do you know if this is possible with the current version or if you have some plans to add support to this in future versions of Dagger Android?

Thank you.

[arekolek]

To me, this gtihub repo looks like it implements what's described in this issue.

[ronshapiro]

Here's a snippet I recently wrote up about this: #1267