Hi Philipp. Ever since I watched your first tutorial on Manual DI, I started to use that. I never regretted it. As you mention: it comes with boiler-plate-code, but you are completely in control.
You can have complelty control with dagger 2 as well, an is much more less prone to errors and has proven and well tested patterns, never back to manual DI unless it is a toy project
Me too! I was actually looking to move away from Koin after so many crashes for forgetting to add dependencies during development. I really think that the boilerplate overhead of manual DI is not as bad as people make it to be. Also I think Koin requires a lot of boilerplate when working with Preview components in Compose, requiring managing mock dependencies for database or datastore modules. But I'm not sure if the latter can be done more easily.
@FricoRico1337 You shouldn't pass that kind of dependencies to a composable, that should go inside the viewmodel, and the preview has to be from a composable without the viewmodel.
@@braiso_22You only need to create a stateful and stateless versions for your composable(s) and you are good with preview. That has nothing to do with manual DI.
Just learn the @Inject annotation deeper, and you'll be surprised that you don't need to declare modules for every class. That's a big pro of Dagger, unlike Koin. In my large projects, the module (the only one) contains only a few lines for classes that cannot be instantiated via a constructor or third-party classes, so the module is used for them. In Koin, however, you have to manually declare even your own classes, which results in a lot of boilerplate.
Love your channel, really. 1 slight difference you could have spotted is the runtime impact. Hilt is a little faster, but I 100% agree with you. Koin wins on so many other topics, like simplicity and multi modules, Koin is clearly a no-brainer.
Hi Philipp, I never used Koin or manual DI but in my experience working on a project with millions lines of code and hundreds of feature modules for several years, Hilt has saved us countless times from possible runtime crashes with its compile time checks that I think is still a great choice if you don't plan to use KMP. I know that Hilt errors are a little bit verbose and can scare a lot of people at first but personally I think that if you read the Hilt documentation (which is not that long BTW) and you take a little bit of time to read the error, you can perfectly understand what is going on. As you also said, build times increases a little bit but not by much compared to the rest. For manual DI, I would say it can be the go to solution if you need to develop SDKs where the less dependencies you have the better it is because there are less chances of conflicts with different project configurations or constraints.
Suggestion, perhaps for your paid course, bootcamp or a SprintPlay, a series of 10 classes, two weeks, going through all the stages of a Sprint, backlog, refinement, planning (feature flag), daily, entr
I used to work with Hilt, but because of KMP I changed to Koin. So much easier and faster to deploy. I avoid manual today, for now, time is one of the financial factors and if you correctly understand the concept Koin is a massive gain.
I agree about dependency injection that there are just tools. They help us to reduce boilerplate code against to Manual DI. So, it's just easier to replace dependencies during testing. About using Koin or Dagger Hilt, I think the main reason why some developers prefer Hilt over Koin is just for compile time checks, that all dependencies are provided. So, you can find earlier any issues, especially in large projects it could be beneficial. But of course with any tool you can make a mess
But when you create a new feature or adjust something, you should test it yourself first. If you forget to add a dependency, you should notice it immediately. And if you make changes but dont test whether they work, then you are a bad developer.
Whats missing for me in this video: I use Hilt for a single reason. You don't need to declare these modules for all classes. Sure, creating a database instance of room, etc. You need a provides function. But for most of your classes your can just annotate the class itself with Inject, Singleton, etc. Hilt will generate the same code. This is what I love about it. And also that 99% of the errors are thrown at compile time (if you don't start to do crazy shit)
I have tried the old Dagger DI in a big real world project and ended up spending a week to find out we missed an annotation (found by installing another plugin). That's why I generally don't use any DI frameworks these days and just stick to manual. You can follow whats happening and will just not compile and show you the problem (in general). I see why people like using them but just adds confusion layer.
You can have completely control with dagger 2 as well (of you know how to use it), an is much more less prone to errors and has proven and well tested patterns, never back to manual DI unless it is a toy project
Hi Phillip, thanks for your video My scenario is what will help in reducing our sdk size what would you suggest between between koin vs service locator vs manual dependency to reduce the size ?
If your goal is to minimize build times and maintain full control, Manual DI is a valid choice. But if you're working on a complex, multi-module project, Hilt (or even Koin) is still a great tool.
You can have completely control with dagger 2 as well (of you know how to use it), an is much more less prone to errors and has proven and well tested patterns, never back to manual DI unless it is a toy project, you can turn off the annotation review for debug to improve the build times
@@Rajmanov makes a great point about Dagger 2 providing control without sacrificing reliability. While manual DI might seem like an attractive option for smaller projects due to its simplicity and build speed, Dagger (or Hilt) still shines for large and complex projects. It not only ensures compile-time safety but also prevents common DI pitfalls like missing or cyclic dependencies. Additionally, as you mentioned, Dagger allows you to optimize build times by turning off annotation processing for debug builds, meaning you don't have to compromise on performance during development. With well-tested patterns and automatic lifecycle management, Dagger and Hilt provide a level of stability and scalability that manual DI can’t offer, especially in multi-module, enterprise-grade applications. Ultimately, Dagger strikes the right balance between control, flexibility, and safety, making it the go-to solution for most medium-to-large projects.
suppose you're working with a team and you have multiple modules. Your teammate provide a factory for a repository interface while you also provide another implementation of that same interface in another module. Now how would koin know which implementation to provide while injecting with koin? Since both of you tested your feature and pushed to git. When merged and released, how would you notice? Wouldn't it crash the app?
You don't really need to always create a view model factory to use manual DI. Just add default initializers to view model's constructor arguments, and that's it.
@@enginegl and how do you pass your dependencies then with default initializers? If you can always default initialize your viewmodel, you probably don't need a constructor in the first place
@@PhilippLackner Our approach is a little bit different from the one shown in the video. If we need a "factory," we simply write `private val foo: Foo = Foo()`, as the Foo class follows the same convention. Additionally, we store singletons inside the companion objects of their respective classes: `private val foo: Foo = Foo.instance`. This way, all dependencies of all classes are injected, making it easy to write tests for them. Anyway, we use Koin as a service locator for selected dependencies that are not accessible from the given module (like `private val foo: Foo = get()`. Pros: we don’t need to declare every possible class inside Koin modules-only those that are declared in one module and implemented in another. Not trying to convince anyone, but this is what we came up with after working on a real project for more than eight years. All tools are great if they solve your problem. By the way, thanks for your work for the community!
Hola mi amigo como estas, te hago una pequeña pregunta porque no dejas el doblaje automático que te ofrece UA-cam? Sería genial para tu audiencia que hablas otros idiomas 😃
Great video! I had the same experience-Dagger Hilt errors were overwhelming at first, but Koin made it so much easier for me. I’ve been using koin ever since
As Kotlin Multi platform is still in new and not mature enough for production apps. Can you please consider making videos on Flutter or React Native for cross platform apps. I would love to see those videos also with android native. btw love your videos ❤
Hi Philipp. Ever since I watched your first tutorial on Manual DI, I started to use that. I never regretted it. As you mention: it comes with boiler-plate-code, but you are completely in control.
You can have complelty control with dagger 2 as well, an is much more less prone to errors and has proven and well tested patterns, never back to manual DI unless it is a toy project
Me too! I was actually looking to move away from Koin after so many crashes for forgetting to add dependencies during development. I really think that the boilerplate overhead of manual DI is not as bad as people make it to be. Also I think Koin requires a lot of boilerplate when working with Preview components in Compose, requiring managing mock dependencies for database or datastore modules. But I'm not sure if the latter can be done more easily.
@FricoRico1337 You shouldn't pass that kind of dependencies to a composable, that should go inside the viewmodel, and the preview has to be from a composable without the viewmodel.
@@braiso_22You only need to create a stateful and stateless versions for your composable(s) and you are good with preview. That has nothing to do with manual DI.
When I told interviewer that DI is not just using dagger hilt we can create manually.
He was arguing with me. Lol, I got rejected
Don't argu just say you are great 😂🤣
For a senior+ role I might argue the point, but not a mid or lower lol.
You go dey teach your interviewer, you never easy.
Just learn the @Inject annotation deeper, and you'll be surprised that you don't need to declare modules for every class. That's a big pro of Dagger, unlike Koin. In my large projects, the module (the only one) contains only a few lines for classes that cannot be instantiated via a constructor or third-party classes, so the module is used for them. In Koin, however, you have to manually declare even your own classes, which results in a lot of boilerplate.
This is what I've been searching for days!! Thank you so much for this beautifull video.
Love your channel, really. 1 slight difference you could have spotted is the runtime impact. Hilt is a little faster, but I 100% agree with you. Koin wins on so many other topics, like simplicity and multi modules, Koin is clearly a no-brainer.
Hi Philipp, I never used Koin or manual DI but in my experience working on a project with millions lines of code and hundreds of feature modules for several years, Hilt has saved us countless times from possible runtime crashes with its compile time checks that I think is still a great choice if you don't plan to use KMP. I know that Hilt errors are a little bit verbose and can scare a lot of people at first but personally I think that if you read the Hilt documentation (which is not that long BTW) and you take a little bit of time to read the error, you can perfectly understand what is going on. As you also said, build times increases a little bit but not by much compared to the rest.
For manual DI, I would say it can be the go to solution if you need to develop SDKs where the less dependencies you have the better it is because there are less chances of conflicts with different project configurations or constraints.
And as always, thank you very much for your work, good health to you and all the best
THANKS FOR CLEARING ALL THIS STUFF IN SIMPLE WAY 💯
Suggestion, perhaps for your paid course, bootcamp or a SprintPlay, a series of 10 classes, two weeks, going through all the stages of a Sprint, backlog, refinement, planning (feature flag), daily, entr
I used to work with Hilt, but because of KMP I changed to Koin. So much easier and faster to deploy. I avoid manual today, for now, time is one of the financial factors and if you correctly understand the concept Koin is a massive gain.
Love your videos man. The Android goat 🐐
This is great! Please do a similar video with ktor vs retrofit
Great videos! Can you also please make a video about the build-logic convention plugin?
I agree about dependency injection that there are just tools. They help us to reduce boilerplate code against to Manual DI. So, it's just easier to replace dependencies during testing. About using Koin or Dagger Hilt, I think the main reason why some developers prefer Hilt over Koin is just for compile time checks, that all dependencies are provided. So, you can find earlier any issues, especially in large projects it could be beneficial. But of course with any tool you can make a mess
But when you create a new feature or adjust something, you should test it yourself first. If you forget to add a dependency, you should notice it immediately. And if you make changes but dont test whether they work, then you are a bad developer.
Our experience of DI in android dev is almost identical and I would also take your advice to use a service locator
Toothpick a hidden gem 💎❤❤❤
Thanks for this. Very good comparison
Whats missing for me in this video: I use Hilt for a single reason. You don't need to declare these modules for all classes.
Sure, creating a database instance of room, etc. You need a provides function. But for most of your classes your can just annotate the class itself with Inject, Singleton, etc.
Hilt will generate the same code. This is what I love about it. And also that 99% of the errors are thrown at compile time (if you don't start to do crazy shit)
I won't touch dagger/hilt if I have the choice. Reckon they will deprecate it eventually as it seems like way too much overhead for no real gain.
I have tried the old Dagger DI in a big real world project and ended up spending a week to find out we missed an annotation (found by installing another plugin). That's why I generally don't use any DI frameworks these days and just stick to manual. You can follow whats happening and will just not compile and show you the problem (in general). I see why people like using them but just adds confusion layer.
You can have completely control with dagger 2 as well (of you know how to use it), an is much more less prone to errors and has proven and well tested patterns, never back to manual DI unless it is a toy project
What about the best choise for Kotlin Multi platform ? should we use an specific Di for each platform ? what about the commons?
Hi Phillip, thanks for your video My scenario is what will help in reducing our sdk size what would you suggest between between koin vs service locator vs manual dependency to reduce the size ?
If your goal is to minimize build times and maintain full control, Manual DI is a valid choice. But if you're working on a complex, multi-module project, Hilt (or even Koin) is still a great tool.
You can have completely control with dagger 2 as well (of you know how to use it), an is much more less prone to errors and has proven and well tested patterns, never back to manual DI unless it is a toy project, you can turn off the annotation review for debug to improve the build times
@@Rajmanov makes a great point about Dagger 2 providing control without sacrificing reliability. While manual DI might seem like an attractive option for smaller projects due to its simplicity and build speed, Dagger (or Hilt) still shines for large and complex projects. It not only ensures compile-time safety but also prevents common DI pitfalls like missing or cyclic dependencies.
Additionally, as you mentioned, Dagger allows you to optimize build times by turning off annotation processing for debug builds, meaning you don't have to compromise on performance during development. With well-tested patterns and automatic lifecycle management, Dagger and Hilt provide a level of stability and scalability that manual DI can’t offer, especially in multi-module, enterprise-grade applications.
Ultimately, Dagger strikes the right balance between control, flexibility, and safety, making it the go-to solution for most medium-to-large projects.
Hey, which theme are you using?
just suggestion, maybe u can create a video about how to manual DI in multi modules structure next time?
All what you said is true, but u know hilt is hilt is a part of community family 🤣
Would love to see a similar video using DI in KMP, esp. Koin. It is confusing all the packages and variations just within Koin...
suppose you're working with a team and you have multiple modules. Your teammate provide a factory for a repository interface while you also provide another implementation of that same interface in another module. Now how would koin know which implementation to provide while injecting with koin? Since both of you tested your feature and pushed to git. When merged and released, how would you notice? Wouldn't it crash the app?
You don't really need to always create a view model factory to use manual DI. Just add default initializers to view model's constructor arguments, and that's it.
@@enginegl and how do you pass your dependencies then with default initializers? If you can always default initialize your viewmodel, you probably don't need a constructor in the first place
@@PhilippLackner Our approach is a little bit different from the one shown in the video. If we need a "factory," we simply write `private val foo: Foo = Foo()`, as the Foo class follows the same convention. Additionally, we store singletons inside the companion objects of their respective classes: `private val foo: Foo = Foo.instance`. This way, all dependencies of all classes are injected, making it easy to write tests for them.
Anyway, we use Koin as a service locator for selected dependencies that are not accessible from the given module (like `private val foo: Foo = get()`. Pros: we don’t need to declare every possible class inside Koin modules-only those that are declared in one module and implemented in another.
Not trying to convince anyone, but this is what we came up with after working on a real project for more than eight years. All tools are great if they solve your problem.
By the way, thanks for your work for the community!
Ayoo. So I've been doing manual di without knowing😅😅 Now, it's time to try koin, let's go!!
Thankyou mentor😊 for this❤
I always start any project with manual DI. However, I didn't created any such big project where I can feel the need of Dagger or Koin.
super helpful, thank you good sir
Hola mi amigo como estas, te hago una pequeña pregunta porque no dejas el doblaje automático que te ofrece UA-cam?
Sería genial para tu audiencia que hablas otros idiomas 😃
porque no es su audiencia
Pero igual es gratis te lo UA-cam.
Do you have any tips for using compose preview with Koin ?
Can you make video for koin annotation??? 😊
do you have a repo for the manual di code? i wanna start by implementing it in a KMP project! Thanks
I used Koin Annotation in my KMP project and it works but it was difficult to get working.
I should have chosen Dagger Hilt before it was too late and too deep into Koin
How about kotlin inject or kotlin inject anvil?
It's an interesting topic. Thank you
I think I hear Vasiliy smiling 🙂
Great video! I had the same experience-Dagger Hilt errors were overwhelming at first, but Koin made it so much easier for me. I’ve been using koin ever since
Same for me.
i love to learn by your tutorial but i can't pay about 30000000 Iranian rial for that
can i have some discount or else i don't know
Cooking for beginners!!!
MANUAL!!! the rest gets abused always at some point
❤❤❤❤❤
14:05 - 27910 unread mails? Wow :)
kotlin-inject is the best
As Kotlin Multi platform is still in new and not mature enough for production apps. Can you please consider making videos on Flutter or React Native for cross platform apps. I would love to see those videos also with android native. btw love your videos ❤
Kmp is production ready, do your research man
Many companies are using kmp
Manual DI is my choice