Don't know if here is the correct thread to ask, b...

# android

[zokipirlo]

Don't know if here is the correct thread to ask, but anyway.... for a new project (which will be 100% kotlin) we (team) are discussing regarding dependency injection framework and which one to use, if any... the more I'm looking into that, the more I don't see any reason to use it, because kotlin supports default parameter (constructor or method). Even looking into the description of Koin or Kodein I don't see any text regarding why, benefit of using DI framework. Can someone with more experience (I never tried any) tell me some benefits of using one please?

[ghedeon]

Does your team write tests? Because I'm wondering how 🙂

[ghedeon]

If not, than your confusion is understandable, singletons will do the trick without any DI framework.

[Mika Puhakka]

Testability is one but even without that consideration, it is a useful abstaction when you don’t have to worry about initialization.

I’ve been using koin on android and it has been dead simple to use and it has improved reasoning about the project tremendously

[LeoColman]

With #mockk tests can be written with singletons, because you can mock the singleton object. If that's the only reason, there's a way to mock it without needing DI

[Jay]

I prefer doing DI by passing interfaces into constructors. Unfortunately many Android classes don’t follow the dependency inversion principle, which means you need to use concrete classes in lots of places, and factories to construct them and it’s a big mess, so using a DI framework helps.

[LeoColman]

I don't like doing DI when it's not necessary. Creating an interface that's only implemented by one class and than passing that interface is very redundant, IMO. For all effects, it is the concrete class, but you're pretending it's not, because you're passing the """"interface""""

[Casey Brooks]

I find that, even without testing or mocking, DI is still a good pattern, especially when using Multibindings. Being able to register and use multiple implementations of an interface/abstract class from different modules does wonders for keeping the codebase clean and extensible.

To that end, Kodein supports multibindings while Koin does not. Unfortunately, it looks like Kodein is having trouble with their docs site right now so I cannot link it to you. However, Guice’s docs can give you an idea of what multibindings are useful for https://github.com/google/guice/wiki/Multibindings

[LeoColman]

Yes, in the cases that you're using multiple implementations, DI is amazing! But I don't think it's always the pattern to-go

[starke]

@LeoColman I’m not sure if you have a full understanding of what dependency injection means. It’s completely possible to use DI without interfaces

[starke]

It’s more about inversion of control where dependencies are supplied externally

[Jay]

I’ve yet to learn much about the DI frameworks, but it sometimes seems like a workaround for bad OO design. Instead of making a nice pluggable architecture, DI to the rescue. Instead of using composition (of small interfaces)… etc.

[Jay]

Maybe I’m totally wrong, but I see horrible chains of builders and factories and ultimately some DI object providing them all. But if you design well and only ever rely on interfaces, you just don’t need all that stuff. Even when it’s a single class with no other implementations, using an interface to depend on only the APIs of that class that you actually use makes it easily mockable.

[starke]

DI doesn’t necessarily require the use of a framework. Frameworks just make it easier and do the boilerplate work for you. It’s definitely good design to inject dependencies rather than creating them inside of a class

[rkeazor]

@ghedeon Singleton will do the trick if you want to write bad code 😂 . Dependency Injection is a good coding design pattern .If your trying to write clean uncoupled than use DI. If your trying write a jungle code ,than use none Di…

[rkeazor]

Global State leads to anti patterns lol. Anyway to answer the question, my vote is always Dagger for production apps. it supported by Google,has the most documentation, and is pure DI. The only downside might be build times might be abit slower, and there is a learning curve to learn Dagger. but if your starting a new Project, you should always aim for the best practices..

[LeoColman]

Singleton can be a good pattern and lead to a good organization if you do it right

[LeoColman]

DI can also lead to spaghetti code if you let it

[LeoColman]

Not using DI doesn't necessarily means bad code

[starke]

anything can lead to spaghetti code

[starke]

DI helps decouple code

[ghedeon]

@rkeazor I'm all in for DI, Dagger user from the version one. But "good pattern" or DI == good code is just a weak argument. Many people blindly jump in but can't explain why they need Dagger. I can't help but have more respect for those who don't use a framework and understand why they don't need it, then for the bandwagon simple smile.

[ghedeon]

It also doesn't help that Dagger is overcomplicated and... uhm, confusing in multimodule setup.

[rkeazor]

@ghedeon you do know dependence injection is a design pattern not a framework 😊

[rkeazor]

@ghedeon, no one is jumping on the bandwagon, but if you understand clean code principles, than you will understand the importance of dependency injection. Di code leads to decoupled code..There is no two ways about it lol... As a professional dev people should aim for the best practices in the industry. .. A codebase full of singletons is a codebase on it's way to being not maintainable 😏😏 and is destined to be refactored..

[LeoColman]

I don't know if a codebase of singletons is bad. Mainly small code bases, in which you don't need the amount of hassle for DI. One of the main reasons for DI is being able to mock something in a test. If you can mock it in another way, perhaps DI isn't that beneficial

[rkeazor]

Devs always complain about complexity , but never take there time to learn new things ... People complain about Databinding but have never tried it. Complain about Rx java, "ooo it's too hard" because they never took the time to try it. A dev will tell you "unit test are not useful" but has never written an test in his life. The truth is, everything is complicated until you learn how to use it lol.

[rkeazor]

@LeoColman I think the reason you think that is because of mock. I've tried mockk, it's very intresting and the devs constantly contributing to that project are awesome...But Mockk is also a bit too Powerful , and can lead to Anti Patterns and bad coding principles

[LeoColman]

I don't think Singleton is a bad coding principle. Kotlin even supports it out of the box

[rkeazor]

Singletons, and Global State is never a good thing. The reason being is because , it can cause unwanted side effects when tampered with. And it can also couple your code together.. . Gl

[rkeazor]

Yes and java supports static objects. But you dont want to base your applications on static objects and singletons all over the place. At least not a production app. If it's a app your doing by yourself no problem. Hell make the whole app in one class.

[rkeazor]

But if your at a company and they tell you to architecture a app. If you start creating singletons everywhere, your just setting up the devs in the future for failure lol

[ghedeon]

you know that you create tons of singletons in Dagger, right? The annotation is called @Singleton, lol. Don't fool yourself, that you don't have them. Injection instead of hidden usage makes the difference, not the singleton itself. Yeah.. global state is awful... now, tell that to redux guys 🙂. The point is, apparently it's not black and white, as long as you know what are you doing.

[ghedeon]

and sometimes it's ok to not be ashamed of giving up on a bad framework. Adoption of Databindings is low not because people are lazy to learn. It's because they didn't like it, after they learned it.

[rkeazor]

@ghedeon Redux follows a different design theory and usecase. Redux creates a store if immutable states.... have you ever seen the source behind the @Singleton lol? Or how it actually works? I mean for each his own... if you would rather work in a code base that has a hugh singleton than feel free

[rkeazor]

That's not true, most of the time devs see something , they look a little bit into the source and it's different from what they are accustom to and give up and call it bad. Like I have devs tell me Kotlin isnt useful, only because they never wanted to learn another language. I have seen devs say, that Constraint Layouts are to complex , and instead use the fundamental view group's they learned from day one lol.... All that is just devs not wanting to take the time out to learn new things😂