Hacker News Reader

Comment by parmesan | Hacker News Reader

Dagger2 is great when you have it setup, generating the dependency graph during compilation makes it lightning fast during execution. I also like the error messages, as long as you can read Java stack traces all the info for solving errors are in there - I've never seen an unsolvable situation this far.

Kapt does bump the clean build time to about 2min, incremental builds take between 10-60s - although actually launching the app on an emulator/device adds another 20s.

The cons of Dagger2 that I've experienced since it's launch are; The documentation and support is useless. You're on your own of you don't use a 3rd party sample project as a template. No one understands scopes and subscopes, subcomponents etc. The new Android dagger api is arcane and weird, no one wants to use it.

The Dagger2 team should (if they aren't already) create a Kotlin extension for it, I believe there are some syntactic optimizations to be offered.

View on HN

I wrote a semantics doc to try to help on the documentation front:

https://google.github.io/dagger/semantics/

It's not intended as a tutorial, so perhaps it won't quite meet your needs, but if you're curious how all the pieces fit together, it may help.

Interesting, will check this and see what i could add to my blog. But yeah, if there is an official example of how to use dagger-android, it will be much helpful. Took me a day to figure it out the whole things and 2 different types of dagger...

> No one understands scopes and subscopes, subcomponents etc

I think there are two reasons for this. First, is how scopes interact with Android component lifecycles, which make everything harder (like RxJava, etc) since they are a complexity multiplier.

Second, there are seemingly bizarre design decisions. For example, if you use dependent components (aka component dependencies), the syntax is pretty straightforward:

  @Component { }
  interface AppComponent { X,Y,Z }

  @Component { dependencies = AppComponent.class }
  interface LoginComponent { }

So the natural order of things is, components use modules, and components can depend on other components. Pretty simple.

Subcomponents turns this relatively simple schema around. The documentation for subcomponents say:

> "To add a subcomponent to a parent component, add the subcomponent class to the subcomponents attribute of a @Module that the parent component installs."

I find is truly strange, now we have modules depending on (sub)components which is the inverse relationship as above.

You get it totally right, I just knew that there are 2 ways to implment DI with dagger, dagger 2 or dagger-android.... And the official docs are indeed useless... And before you learn some dagger basic, some online tutorial just can't be understandable... because either they mixed up the 2 plugin or they just all have their different setup.

Reply on news.ycombinator.com