Dagger (in a simplified way) is for exactly one thing.
If you have a class that takes a constructor parameter, it provides that parameter.
Now you may wonder why we'd a library for that. It's because you'd want to handle:
- The object you need in the parameter, also needs objects in its construct that also need objects and so on. Which means you'd sit building up this object everytime you needed it. If you change what parameters it has, you now have some awful refactoring to do.
- Maybe you want to RealDb() as a parameter one place and FakeDb() as a parameter in your Android Tests.
- You may want to reuse some of these objects and don't want to carefully manage when each one gets sent where.
If you want to get the full benefits that are involved with this, you could use an interface for the db.
As you go deeper into how it's used, you'll really appreciate something that creates your constructor parameters for you.
Another term for these constructor parameters, since the class that takes them, depends on them, is dependencies.
Dagger therefore provides your "dependencies" and when dependencies are just put into whatever class needs them, we call it "dependency injection".
A mouthful of a phrase which just means "gives you objects where you want them".
In the next article, we'll be looking into Setting up Dagger-Android and why it's easier than you think, and tremendously useful.
Comment if you have any questions! I'll re-write, clarify and simplify based on your feedback.
Top comments (7)
It would be good if you do what Google never cared to do, which is to explain that using dependency intention is the important part.
Should you use Dagger or Koin or manual dependency injection?
the right answer here is: it depends on your context, there is a trade-off involved.
Through my and other's experiences I've found that dependency injection makes things simpler when you have an architecture that is well separated.
Which means that you've got interfaces and classes that do one thing each and they need to be created and passed into other classes to enable progressively larger parts of a feature.
That's a bit further ahead but I'll try to think of how to explain it that doesn't involve a whole lot of cognitive load for the reader, thanks!
I totally agree on dependency injection.
I just added that the pattern was more important that the particular framework you are using.
And that once you know the pattern, picking up the framework is easy.
but not the other way around: struggling with Dagger annotations doesn't do much to help the reader understand the DI pattern.
also Dagger documentation is crap.
Bonus: if you explain the pattern, with Dagger as a mere illustration for Android devs, your future article will be useful for much more Dev.to readers than just for people doing Dagger on Android.
Dagger for Android is deprecated.
So you shouldn't care.
@aniketsmk any comment on this.
It's covered in the article, deprecation doesn't mean much if there's nothing to replace it with.
I do talk about a tradeoff of what exists currently that you might want to take that tradeoff with, also in the article.
True, deprecated not replaced. Good Article. Thanks for sharing. :)