A modern programming language that makes developers happier.

kotlinlang

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)

I feel like if a library really needs DI then probably the library is too big and should perhaps be split in to multiple libraries. There are of course exceptions

Take a look at Magnet for cross-library DI <https://github.com/beworker/magnet>

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

That looks pretty interesting ! I'll have a look thanks <@U3MA5LH0U>

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.