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...
For further actions, you may consider blocking this person and/or reporting abuse
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. :)