Does anybody know why they are stopping new develo...

# android

[alex.tavella]

Does anybody know why they are stopping new development on dagger-android. I personally don't like it, just want to know more about the problems community faced with it and possibly advocating against it on my company (we use it for every feature).

[rkeazor]

@alex.tavella There is nothing wrong with dagger-android. it was just an attempt to reduce boilerplate in your android classes, and give you the opportunity to create base activity and fragment classes. The reason why they stop adding new features to it, is because they are looking into a new approach to simplify the dagger set up

[rkeazor]

what would be the point in arguing agianst it at this point, when the other alternative, is to DaggerComponent boilerplate , to all your activitiy and fragment?

[alex.tavella]

From what I understand of it, it uses subcomponents which are coupled to the parent component meanwhile component dependencies are more independent. Besides that, with DFM, you can't use subcomponents since your parent component has to know the feature components which is not possible on DFM modules.
Some ex-employee started to use it in our company and it does so much for us that no1 knows how to work with dagger anymore, we have only a single component which contains every feature module which is injected in every fragment/activity through a lifecycle observer.
This is really painful because we have everything being injected everywhere and if I want to create a new module for demoing a specific feature within a reduced scope I actually don't know which dependencies I have to provide for that feature.

[trevjones]

AndroidInjector is the main win, just an interface that you can use as a way to dependency intert and invert control. if your app arch and delivery allow for subcomponents @ContributesAndroidInjector can be great and really cut down the amount of public api you have to write when doing component dependencies.

subcomponents are not coupled to the parent in any way initially. the subcomponent implementation is a detail of the parent implementation but the sub doesn't know about the parent in anyway unless you really get to work making it happen. because of this you can have multiple implementations of the subcomponent that all depend on the attach point. (if you use the default AndroidInjection.inject behavior)

[alex.tavella]

But the parent has to declare the subcomponent and it's dependencies are not explicit since as you said it's an implementation detail of the parent

[alex.tavella]

Anyway, I will dive into it more. What we really want in the end is to have every feature having its components encapsulated in its @Component (or @Subcomponent) which might be scoped and its contained within its own gradle module. If I can do that with dagger-android without leaking anything to the parent @Component then I'm fine with it.

[trevjones]

yea you could have a base component per module that includes the contrib modules.

even though the parent declares the sub in the annotation is it that much worse than the parent listing a sprawl of things on its public API because some uncoupled component that depends on it needs things?

end of the day subcomponents usually result in enough IoC opportunity and less code for me to write. so I usually choose them