Personally I don’t like when library exposes any kind DI framework and would prefer to build manually (hate what Glide does for example)

Probably use it internally for the library is kinda fine, but I would try to avoid it personally (but of course it depends on scale, on very big library DI may require for scalability)

you get the best of two worlds - publish your library without DI specifics to the outside and still use DI in your internal projects

The nice thing about Magnet is that it is pretty unobstrusive, no

Module

definitions, no `Component`s, just annotations on the instances you need. It then automatically puts things into the highest scope by default, unless you say otherwise.

Say, e.g. you have an application scope and an activity scope and some

UseCase

class. Now if this use case class only depends on the

Application

context, it is put there upon injection and gets an application-wide singleton.

If your use case class references an

Activity

(or anything else that is just bound in a child scope of another scope), then the instance is bound there and then there could be multiple instances of this class if multiple scopes on that level exist. Pretty neat.

I went from Roboguice to Dagger1 and Dagger2, now with Magnet I don't want to look back at anything else.

Sadly, if people ask for DI, most hear Dagger2 and even Google references it, so people think that it is the best, because most natural choice. But there are alternatives to it.