I’m sure that you put a lot of effort and thought into this article. This should be respected. However, I don’t think that effort and good intentions compensate for technical inaccuracy.
What you called “Kagger” is in fact a very old concept called “Pure Dependency Injection”. It predates Kotlin and can easily be implemented…
I’d say that Dagger is suitable for the vast majority of Android applications if done the right way.
It is just
dagger.android package which promotes excessive coupling and boilerplate that should be avoided.
We had very interesting and deep discussion (well, sort of discussion) with Jake Warthon on…
As Android developer, I would like to ask the following questions:
What I also like is that the constructor is the only part of my classes that knows about the component
Yes, but it is still a dependency. Make this technique widespread in the codebase and you’re on the verge of “service locator”.
At the very least, this was an interesting read.
I recently demonstrated how to implement dependency injection in Android without any frameworks at all, and then showed how Dagger fits into this picture.
This post does basically the opposite — takes a specific way to structure Dagger code in the app…
Well, not sure I would call this “minimal”. It might be just lower than the other approach, but Dagger is obviously bad in respect to testing.
I’m very interested in your experience because I’m trying to figure out a better approach right now. Hopefully it will not involve excessive complexity and compromising dependency…
You managed to answer my next question without me asking. Thanks a lot.
For a very long time I looked for at least one single advantage of AndroidInjector approach, and, from what you say, looks like it might be it.
Just to make sure — do you think this approach is better than what you previously…