Some clarification: I'm neither against Dagger nor completely pro manual DI. In most more complex projects Dagger provides functionality you can't easily achieve with manual DI. But in simpler projects, it's overkill in most cases. The main thing I want to show with this is that DI on Android != Dagger. DI is often overcomplicated and people think it can only be achieved with Dagger which is simply not true.
@@ChrisAthanasSingletons are not released. That's why they are singletons. Once the app is killed, the process is dead, the JVM is down, they are released.
Don’t think you needed to clarify to the generally sane about alternates or how it was done before bloated libraries. For beginners it is very helpful to understand the manual procedures.
I haven't seen such a useful and well explained solution in a long time. I think most Android developers will use this approach because everything is visible and clear. For small projects written in pure Kotlin, I think it is unnecessary to use Dagger/Hilt. Thank you so much!
Thanks for video! I didn't understand why everyone was constantly using Dagger (or Hilt). After all, for small projects it would be more efficient to do it manually. This video shows where to start and how to build architecture
For small projects build time isn't an issue, so I don't know what we're optimizing here. With Dagger+Hilt the video would have ended in minute 2, all the other 10 minutes was due to manually injecting the objects.
Thank you so much for this insightful video! I was really struggling to wrap my head around Dagger and its complexities. Your video brilliantly showcases alternative ways to achieve manual dependency injection on Android, offering a fresh perspective and a sense of relief. Your clear explanations and demonstrations have made the concept crystal clear, and I'm now more confident in navigating these challenges. Your effort in simplifying this topic is truly appreciated. Keep up the great work!
Good video. As mentioned, there are some cases where third party DI makes sense. Multi module apps for example, where most modules don't have access to the Application subclass.
Got used to Dagger 2 / Dagger Hilt :) This manual DI also great! I'd rather say that it is very useful for beginners to understand how Dagger works under the hood ;) 🇱🇹
I'm not sure if you mentioned this in your video, but it should be noted that this pattern is an example of the Service Locator Pattern. It is an alternative for Dependency Injection for sure, and the "drawback" is that this is runtime, but it is very useful nonetheless.
No do not move backwards :D Use Dagger + Hilt if you know how to use it. It just makes your life so much easier in every possible way. Manual Dependency is actually more complicated than Dagger + Hilt at this time. Dagger + Hilt allows you to easily inject into Activity, Fragment, Compose, ViewModel, Workers, View, Service, BroadcastReceivers, Alarms, Tests, where you'd need custom factories / implementations / huge singletons or god classes to do it manually.
While I agree that using Dagger has some advantages over manual DI, I think it by no means belongs in every project out there. Most people think you have to use Dagger in order to achieve DI and forget about what DI is really about
1. Dagger may be an overkill for small projects - and it's very complex (true), even intimidating. 2. But if you find yourself creating an "AppModule" by hand... you should ask yourself: is my project really small enough not to use an industry-standard solution? 3. It's not unlike writing your own ORM. It's easy for trivial cases, but it's dangerously close to reinventing the wheel, and the infamous NIH (Not Invented Here) syndrome. 4. There are simpler ready-to-use alternatives if Dagger is too complex for your needs. Koin, for example. Very easy to set up, much more beginner-friendly than Dagger, and, well, battle-tested. There is a much greater chance of having a hidden bug, or an unhandled edge-case in your custom DI, than in Koin. 5. All this being said, here is great educational value in writing a simple DI framework yourself. It really helps to understand how DI truly works, including the concepts behind Dagger. In this sense I'm fully on board. PS. I haven't watched the full video (yet). If some of my points are acknowledged in the video, simply treat my comment as a non-polemical summary
Just because a framework is "Google-supported" doesn't mean it's technically "industry standard". Uber has Motif, Deliveryhero has Whetstone, then there's Koin, Kodein, Toothpick, Anvil. All of these predated by Guice (which "was industry-standard" and look where it is now). In the grand scheme of things, use a library because you need it, not because "it's there".
I respectfully think that when it comes to Android in particular, NIH syndrome isn't really a thing. In my experience, the vast majority of 3rd party libraries, even the so-called 'industry standards' for Android aren't just bad, they're a crime against humanity - poorly written with nonsensical APIs, wasteful, presumptive, bug-laden and worst of all, constantly changing. The Android SDK contains literally 30 years of bad ideas all lumped on top of each other. I'd recommend every Android developer intentionally adopt NIH syndrome. In fact, I think it's a requirement for maintaining sanity.
@@Zhuinden 1. I didn't say it must be "Google supported". E.g. Retrofit isn't, RxJava (arguably obsolete now, but it had its heyday) wasn't either. 2. More likely than not, your company is NOT like Uber, Netflix, Airbnb etc., and doesn't have the same resources 3. You have to think of learning curve as well. It's much easier to find a developer who can PROFICIENTLY use a widespread library "X" than someone proficient in the use of your custom-made "Y" (10% better than X... assuming the same level of know-how).
No matter how you style it, Java is the World of Overengineering. When I started learning Kotlin I thought it was something like Python or at least Javascript but it was just a shadow of Java: patterns over patterns, libraries over libraries. Look at the DI history in Android: Manual Dependency Injection (pre-frameworks era) RoboGuice (2010) Dagger 1 (2012) Dagger 2 (2015) Google's Dagger Android (2017) Koin (2017) Hilt (2020) Koin 3 (2021) Want more? :) Here they are: Kodein ButterKnife DINJ Toothpick KodeGo Needle Guys, is this normal?:)
That's about as true as saying that a modern car wheel with TPMS sensors, self-healing tires and carbon fiber is a "reinvention" of the original stone age wheel.
Hello Philip, would you consider selling the course prices more affordable in countries like turkey as steam does? I want to take your courses but as a student it is quite difficult for me to afford.
Even better would be to access an application instance in the create method which accepts extras. This way we may move context-dependent dependencies provider to application (non companion). While the ViewModel.Factory instance could be declared as a stateless object.
Cool idea for a video! Also nice, for better understanding of what happens behind the scenes. Whether to really use this approach, maybe if the projcet is really small. Because once you've got more things to Inject, like 10 useCases for your viewmodel, you wouldn't want to do so every time you refer to that viewmodel. It's also not good for seperation of concerns, because it's not the screen's/activity's business what use case its viewmodel is using... But nice idea ;)
nice video, but it would be also nice if you would use the latest stable android studio version with default settings, I initially always have problems to get your example projects running
Hmm for me it looks like the manual DI is more work then hilt. Pure Dagger is really too much, but hilt already extracted the minimum need and you just have to add these small annotations. In this example philipp showed us you could see, that you have to write more code (at least the double), especially when you have viewModels with a lot of parameters for the constructor. Even for very small projects its still less work using hilt then doing it manually^^ Also it is not necessary to use an interface.. for testing you can just use "mockk" for the objects. The only advantage for using manual DI is in my opinion the very bad compiler error messages of dagger/hilt. But when you have a bit experience, then even this errors are at some point usefull :D edit: As far as I know, its also not an good idea to use companion object for singletons. The Garbage Collector can garbage collect the static objects anytime. The chances are may not high, but this can happen. In Dagger/Hilt, the singletons are not static singletons, so they are also cannot randomly get garbage collected. Also when you really want to improve your build time, dont do manually DI but split your projects into modules. These modules can get build in parallel in really speed up you building a lot!
Thanks for this, it was really helpful but I have a query regarding this. How to use app module to inject dependency that are async like room database. The problem is this I have used the same code for this but as soon I access that database from AppModule in my view model it throws null pointer exception. Any suggestions for that?
What this video boils down to is that DI is a pattern, not a library. Hilt is an implementation and there are other. You can also write your own. My question is: If your app is so simple that you can write your own DI solution, then maybe you don't need it at all. Just lazyinit what you need in the application class and be done with it.
Hi, Philipp! A question about your Testing course: in UI testing module do you explain how to test Compose UI or only traditional views? Thank you for the answer in advance! ❤
Whole idea is to use Dagger or DI framework is to develop faster and build scalable solution also you wont know when your business gets complicated and your so called lagecy code becomes a problem to maintain. Phillip just want us to understand the DI concept but he is not discouraging you to use dagger or hilt. I would say if your build time is bothering you try to use service locator based DI framework (Koin) instead annotation processor based Dagger. Both have pros and cons but dont go with manual dependency injection for production code
Just as I'm porting my java app to flutter then finding flutter isn't a great fit for what I want and moving to compose instead 😂 I hated dagger hilt and am looking for a better way
What about objects that should survive a configuration change, but should not be singletons? Use some class container with onRetainNonConfigurationInstance?
this manual solution will work only on simple examples like in this video store VM-scoped modules in companion object of ViewModel? forget about simultaneous usage of VMs of this type
so we reinvent the wheels? Ain't that was an ordinary stuff before dependency injection were introduced? I definitelly can't call this a simplier solution, unless we work on a very simple application itself
So, you just made a service locator. Which we already have a solid solution, Koin. Even in a "small" project it's not worth to implement a manual service locator as the simplest project will scale at some point. And then you have to struggle between adapting the architecture for the new set of features or refactors and migrating your service locator to another more solid solution... Reinventing the wheel in this area is not worth it in my opinion.
So you are telling me that a line removed in a project with QA tests, automated tests, unit tests (I'm assuming), PR reviewers and yourself testing the feature or change is going live like nothing and it's a Koin / Service locator problem? You should rethink or talk with your peeps about the current state of your project... It looks like there is space for improvement there.@@dreewr
And let me tell you by my experience that you are wrong. I'm currently working in a very large bank app with multi country support and modular presentation layers (different UIs per countries) and Koin works awesome@@dreewr
As I've mentioned in the video, you could initialize a module inside of your viewmodel for example for viewmodel scoped dependencies. For activities it's a bit trickier if the dependencies should survive config changes
@@PhilippLackner I mean how we can create an object which can not be collected by GC only on two screens, for example. We have scopes in Dagger for that purpose, but how can you do it manually?
If you need this, better use Dagger haha. You'd need to tie the creation of the module to the back stack entry (in that case of a nav sub graph) and set it to null when the back stack entry is destroyed
@@DJOrangeJoe lol no..superb intellisense and you can code them in c# as well and biggest of all no gradle bullshit incompatible bla..bla.., plus are you not catching why DI is important and why dagger is needed back then, lol?
I don't recommend using manual DI. It can become cumbersome and error-prone as your project grows in complexity. This is not recommended for larger projects or projects where maintainability and testability are more important than build time and gradle errors.
Thank you for the video. But please... 9:56 do no leave warnings in your video code. People need to know that they should not leave warnings. I really hate it when i get into someones code and all i see i yellow color
@@dreewragree This is what the DI is doing under the hood anyway Dagger/Hilt is an overcomplicated mess and often causes more problems than it solves and the documentation is TERRIBLE Thermosiphon this! Lol
So, providing the appContext to AppModuleImpl was not really necessary, was it? At least in those examples. Neither the -Api nor the -Repository classes need a Context. This is especially true for KMP projects where shared code shouldn't use Android-specific classes.
Thanks for showing us how DI works. But why bother to write all this boiler plate code? Hilt is stupidly easy to set up and use. Build time is not an issue for small projects. For bigger projects, you can go multimodule to slash down build times to almost nothing. I would not go with manual DI setup for any production app. And small comparison between Koin vs Dagger2/Hilt: during runtime Dagger2/Hilt has only ~third of memory footprint of Koin. Everything has pros and cons. Choose wisely :)
Only because you have trudged up the mountain and are confiable with its methodology Can you remember your first encounter with hilt/dagger and how it felt This approach is a better step before full blown hilt implementation
@@Dibyendu.M exactly The technique given here is a very useful in-between step Shows the reason why a DI library is necessary but only after you fully understand it Deploying the solution with Kotlin is a great way to introduce the DI concept, because it's very clear what's going on, so adding a DI library will be much less confusing
Some clarification:
I'm neither against Dagger nor completely pro manual DI. In most more complex projects Dagger provides functionality you can't easily achieve with manual DI. But in simpler projects, it's overkill in most cases.
The main thing I want to show with this is that DI on Android != Dagger. DI is often overcomplicated and people think it can only be achieved with Dagger which is simply not true.
My question is how are these singletons released after they go out of scope and no longer necessary?
And what about scopes?
@@ChrisAthanasSingletons are not released. That's why they are singletons. Once the app is killed, the process is dead, the JVM is down, they are released.
Don’t think you needed to clarify to the generally sane about alternates or how it was done before bloated libraries.
For beginners it is very helpful to understand the manual procedures.
I just know I had already do some DI code manually after your explaination. Thanks for your great example and look forward for the new topics :)
I think learning Manual DI helps you understand what is going on under the hood when you use Hilt or Koin. Very helpful video as usual. Thank you!
I haven't seen such a useful and well explained solution in a long time. I think most Android developers will use this approach because everything is visible and clear. For small projects written in pure Kotlin, I think it is unnecessary to use Dagger/Hilt. Thank you so much!
Thanks for video! I didn't understand why everyone was constantly using Dagger (or Hilt). After all, for small projects it would be more efficient to do it manually. This video shows where to start and how to build architecture
For small projects build time isn't an issue, so I don't know what we're optimizing here. With Dagger+Hilt the video would have ended in minute 2, all the other 10 minutes was due to manually injecting the objects.
It's about learning and understanding how things work@@rcgonzalezf
Dagger hilt is made by Google for Google, just like Angular.
Thank you so much for this insightful video! I was really struggling to wrap my head around Dagger and its complexities. Your video brilliantly showcases alternative ways to achieve manual dependency injection on Android, offering a fresh perspective and a sense of relief. Your clear explanations and demonstrations have made the concept crystal clear, and I'm now more confident in navigating these challenges. Your effort in simplifying this topic is truly appreciated. Keep up the great work!
Good video. As mentioned, there are some cases where third party DI makes sense. Multi module apps for example, where most modules don't have access to the Application subclass.
Got used to Dagger 2 / Dagger Hilt :) This manual DI also great! I'd rather say that it is very useful for beginners to understand how Dagger works under the hood ;)
🇱🇹
I liked the way you use companion object cause I always run in problem of needing a singletone with a constructor, New great idea THANKS BRO 😄
I'm not sure if you mentioned this in your video, but it should be noted that this pattern is an example of the Service Locator Pattern. It is an alternative for Dependency Injection for sure, and the "drawback" is that this is runtime, but it is very useful nonetheless.
No do not move backwards :D
Use Dagger + Hilt if you know how to use it. It just makes your life so much easier in every possible way.
Manual Dependency is actually more complicated than Dagger + Hilt at this time.
Dagger + Hilt allows you to easily inject into Activity, Fragment, Compose, ViewModel, Workers, View, Service, BroadcastReceivers, Alarms, Tests, where you'd need custom factories / implementations / huge singletons or god classes to do it manually.
While I agree that using Dagger has some advantages over manual DI, I think it by no means belongs in every project out there. Most people think you have to use Dagger in order to achieve DI and forget about what DI is really about
Koin
Honestly though don’t be completely shutout from any other solution. Dagger is not the only way to do it
Well, Koin is runtime di, just for this reason my choice is dagger/hilt
I think it depends. It’s even more complicated for tiny projects, modules and features.
1. Dagger may be an overkill for small projects - and it's very complex (true), even intimidating.
2. But if you find yourself creating an "AppModule" by hand... you should ask yourself: is my project really small enough not to use an industry-standard solution?
3. It's not unlike writing your own ORM. It's easy for trivial cases, but it's dangerously close to reinventing the wheel, and the infamous NIH (Not Invented Here) syndrome.
4. There are simpler ready-to-use alternatives if Dagger is too complex for your needs.
Koin, for example.
Very easy to set up, much more beginner-friendly than Dagger, and, well, battle-tested. There is a much greater chance of having a hidden bug, or an unhandled edge-case in your custom DI, than in Koin.
5. All this being said, here is great educational value in writing a simple DI framework yourself. It really helps to understand how DI truly works, including the concepts behind Dagger. In this sense I'm fully on board.
PS. I haven't watched the full video (yet). If some of my points are acknowledged in the video, simply treat my comment as a non-polemical summary
Just because a framework is "Google-supported" doesn't mean it's technically "industry standard". Uber has Motif, Deliveryhero has Whetstone, then there's Koin, Kodein, Toothpick, Anvil. All of these predated by Guice (which "was industry-standard" and look where it is now). In the grand scheme of things, use a library because you need it, not because "it's there".
I respectfully think that when it comes to Android in particular, NIH syndrome isn't really a thing. In my experience, the vast majority of 3rd party libraries, even the so-called 'industry standards' for Android aren't just bad, they're a crime against humanity - poorly written with nonsensical APIs, wasteful, presumptive, bug-laden and worst of all, constantly changing. The Android SDK contains literally 30 years of bad ideas all lumped on top of each other. I'd recommend every Android developer intentionally adopt NIH syndrome. In fact, I think it's a requirement for maintaining sanity.
@@Zhuinden 1. I didn't say it must be "Google supported". E.g. Retrofit isn't, RxJava (arguably obsolete now, but it had its heyday) wasn't either.
2. More likely than not, your company is NOT like Uber, Netflix, Airbnb etc., and doesn't have the same resources
3. You have to think of learning curve as well. It's much easier to find a developer who can PROFICIENTLY use a widespread library "X" than someone proficient in the use of your custom-made "Y" (10% better than X... assuming the same level of know-how).
Oh that's great! I really have a hard time setting up dagger-hilt.
The best Android related videos on RUclips 👌
Philip shows the google android team how to explain their goofy technology so people outside the company can understand
I wasn't a big fan of koin, but koin-annotation made Hilt stop appealing to me - it's all about the configuration.
Ths simple approach works also for other languages and contexts, I'll be using it! Thanks!
No matter how you style it, Java is the World of Overengineering. When I started learning Kotlin I thought it was something like Python or at least Javascript but it was just a shadow of Java: patterns over patterns, libraries over libraries. Look at the DI history in Android:
Manual Dependency Injection (pre-frameworks era)
RoboGuice (2010)
Dagger 1 (2012)
Dagger 2 (2015)
Google's Dagger Android (2017)
Koin (2017)
Hilt (2020)
Koin 3 (2021)
Want more? :)
Here they are:
Kodein
ButterKnife
DINJ
Toothpick
KodeGo
Needle
Guys, is this normal?:)
Seems like a good way to add DI to a KMM project.
Dagger/Hilt worshippers keeps saying you're reinventing the wheel, not knowing this is actually the wheel that was reinvented
😂
That's about as true as saying that a modern car wheel with TPMS sensors, self-healing tires and carbon fiber is a "reinvention" of the original stone age wheel.
I can hear Vasiliy applauding in the back of the room 😀
haha buut he still has a course on DI with Dagger and Hilt
Hello Philip, would you consider selling the course prices more affordable in countries like turkey as steam does? I want to take your courses but as a student it is quite difficult for me to afford.
Even better would be to access an application instance in the create method which accepts extras. This way we may move context-dependent dependencies provider to application (non companion). While the ViewModel.Factory instance could be declared as a stateless object.
what a timing, just before alpha KSP support for dagger released :D
Annotations are so confusing and messy
Cool idea for a video! Also nice, for better understanding of what happens behind the scenes. Whether to really use this approach, maybe if the projcet is really small. Because once you've got more things to Inject, like 10 useCases for your viewmodel, you wouldn't want to do so every time you refer to that viewmodel. It's also not good for seperation of concerns, because it's not the screen's/activity's business what use case its viewmodel is using...
But nice idea ;)
Great video!!! But after learn manual DI, think again Hilt and Dagger is a good library.
Would have been nice to speak about singletons and factories in this
nice video, but it would be also nice if you would use the latest stable android studio version with default settings, I initially always have problems to get your example projects running
This is the latest stable version. You might need to select the correct jdk used in the project
@@PhilippLackner and room version too, your clean architecture app works only on ver 2.4.1 for me :)
@PhilippLackner May I know the IDE theme you are using? Thanks!
Android studio with new ui active
The default theme in the new ui in AS
@@ChrisAthanas Thank a lot bro.
Naaah, no way, I never give up on Dagger, it is been almost 3 years and I just finally understood all his power
Did you ever find a way to reset or clear the ViewModel instance without Hilt?
Can you please do a video or a paid course where you use Dagger 2? It's still relevant to this day and is often asked in interviews
@PhilippLackner Please tell how to create viewModel without hilt annotation but still with dependencies provided by hilt? Please please please!
KSP is coming, soon will have a faster processor 😉
Video is already planned :D
Great
Hmm for me it looks like the manual DI is more work then hilt. Pure Dagger is really too much, but hilt already extracted the minimum need and you just have to add these small annotations. In this example philipp showed us you could see, that you have to write more code (at least the double), especially when you have viewModels with a lot of parameters for the constructor. Even for very small projects its still less work using hilt then doing it manually^^
Also it is not necessary to use an interface.. for testing you can just use "mockk" for the objects.
The only advantage for using manual DI is in my opinion the very bad compiler error messages of dagger/hilt. But when you have a bit experience, then even this errors are at some point usefull :D
edit: As far as I know, its also not an good idea to use companion object for singletons. The Garbage Collector can garbage collect the static objects anytime. The chances are may not high, but this can happen. In Dagger/Hilt, the singletons are not static singletons, so they are also cannot randomly get garbage collected.
Also when you really want to improve your build time, dont do manually DI but split your projects into modules. These modules can get build in parallel in really speed up you building a lot!
Thanks for this, it was really helpful but I have a query regarding this. How to use app module to inject dependency that are async like room database. The problem is this I have used the same code for this but as soon I access that database from AppModule in my view model it throws null pointer exception. Any suggestions for that?
What this video boils down to is that DI is a pattern, not a library. Hilt is an implementation and there are other. You can also write your own. My question is: If your app is so simple that you can write your own DI solution, then maybe you don't need it at all. Just lazyinit what you need in the application class and be done with it.
Hi, Philipp! A question about your Testing course: in UI testing module do you explain how to test Compose UI or only traditional views?
Thank you for the answer in advance! ❤
It's all focused on compose 💪🏻
@@PhilippLackner great, than I will buy!
How about the lifetime issue, where dependencies are allowed to be released when not needed?
Not all singletons are used everywhere in the app, how is this handled with this technique?
I see lazy init but what about release?
i really enjoy your videos. thanks!
Whole idea is to use Dagger or DI framework is to develop faster and build scalable solution also you wont know when your business gets complicated and your so called lagecy code becomes a problem to maintain. Phillip just want us to understand the DI concept but he is not discouraging you to use dagger or hilt.
I would say if your build time is bothering you try to use service locator based DI framework (Koin) instead annotation processor based Dagger.
Both have pros and cons but dont go with manual dependency injection for production code
On point
I would add this is fine for apps up until around 30,000 lines
At that point you will likely need a solution like hilt or koin
Thank you Philipp you are the best 🙏🔥
Thanks, nice approach !
I think Kotlin should come up with a DI framework *as a part of the standard library* or a kotlinx library like Coroutines.
Just as I'm porting my java app to flutter then finding flutter isn't a great fit for what I want and moving to compose instead 😂 I hated dagger hilt and am looking for a better way
Nice video! How does the create() method in retrofit know it should return AuthApi? How does it read the return type of the enclosed function?
The type is specified by the function return type
What about objects that should survive a configuration change, but should not be singletons? Use some class container with onRetainNonConfigurationInstance?
I thought the whole time I was crazy for thinking dagger was overcomplicated coming from a .NET where injection is baked in
Hi Philip this is good stuff now
always make usefull content 🤝
Just yesterday solving dagger-hilt errors,,,,,Thank you aloot
What about Koin, it would be an alternative for you or def not?
Awesome, thank you 😀
this manual solution will work only on simple examples like in this video
store VM-scoped modules in companion object of ViewModel? forget about simultaneous usage of VMs of this type
so we reinvent the wheels? Ain't that was an ordinary stuff before dependency injection were introduced?
I definitelly can't call this a simplier solution, unless we work on a very simple application itself
Technically speaking, dagger was the reinvention of the wheel
yeah, just was scarried a little bit that we going wrong way :P @@PhilippLackner
Thats why i perfer KOIN its a great balance and simpler approach than dagger
So, you just made a service locator. Which we already have a solid solution, Koin. Even in a "small" project it's not worth to implement a manual service locator as the simplest project will scale at some point. And then you have to struggle between adapting the architecture for the new set of features or refactors and migrating your service locator to another more solid solution... Reinventing the wheel in this area is not worth it in my opinion.
Koin is very error prone in large production apps...
One line of code removed in a merge and your app goes to production with a crash - happened with me after QA tests, automated tests etc etc
So you are telling me that a line removed in a project with QA tests, automated tests, unit tests (I'm assuming), PR reviewers and yourself testing the feature or change is going live like nothing and it's a Koin / Service locator problem? You should rethink or talk with your peeps about the current state of your project... It looks like there is space for improvement there.@@dreewr
And let me tell you by my experience that you are wrong. I'm currently working in a very large bank app with multi country support and modular presentation layers (different UIs per countries) and Koin works awesome@@dreewr
No, these dependencies are all defined at compile time
Service locators resolve at run time, which can easily cause problems in production
Does this work only on android apps or can it also work on KMM projects?
Looks like service provider, but how you can create scopes for lifecycles for objects with your manual "di'?
As I've mentioned in the video, you could initialize a module inside of your viewmodel for example for viewmodel scoped dependencies. For activities it's a bit trickier if the dependencies should survive config changes
@@PhilippLackner I mean how we can create an object which can not be collected by GC only on two screens, for example. We have scopes in Dagger for that purpose, but how can you do it manually?
If you need this, better use Dagger haha.
You'd need to tie the creation of the module to the back stack entry (in that case of a nav sub graph) and set it to null when the back stack entry is destroyed
@@PhilippLackner 🙂
You should not be passing the AppModule itself to the ViewModel, even with manual DI. Other than that, great video.
This is service locator not dependency injection
Thank you!
mean while MAUI or xamarin is way leap ahead and this kind thing is just standard
But MAUI xaml UI + viewmodel is a pain in the ass compared to jetpack compose :D
@@DJOrangeJoe lol no..superb intellisense and you can code them in c# as well and biggest of all no gradle bullshit incompatible bla..bla.., plus are you not catching why DI is important and why dagger is needed back then, lol?
Hey Philipp, make a project on jetpack media3. Please, consider this.
Koin is better for small or kmp projects than manual DI
I don't recommend using manual DI. It can become cumbersome and error-prone as your project grows in complexity. This is not recommended for larger projects or projects where maintainability and testability are more important than build time and gradle errors.
how can i pass arguments now ?
goat
It's Wednesday again!
Don’t we need dagger for compose navigation?
Why would you?
I prefer koin over dagger. Dagger seems massively overcomplicated to me.
goat
Nice trick
Thank you for the video. But please... 9:56 do no leave warnings in your video code.
People need to know that they should not leave warnings.
I really hate it when i get into someones code and all i see i yellow color
Manual DI?
NICE!!!!!
is Dagger or Hilt free?
Yes it’s free
Just very steep learning curve and difficult to work with
Finally someone saved us from dagger's sharpness
There’s koin
Okay, thank you, but I will still use Dagger😂😂
Koin for the win
Thank you very much! But, how do you know, what I need right now? 😊
I hate dagger with a passion but reinventing the wheel is not the way.. however k..k..koin ? ;))
It's not reinventing the wheel, it's the wheel itself. The pattern is agnostic of the tools that implement it.
@@dreewragree
This is what the DI is doing under the hood anyway
Dagger/Hilt is an overcomplicated mess and often causes more problems than it solves and the documentation is TERRIBLE
Thermosiphon this! Lol
👏
🎉
So, providing the appContext to AppModuleImpl was not really necessary, was it? At least in those examples. Neither the -Api nor the -Repository classes need a Context.
This is especially true for KMP projects where shared code shouldn't use Android-specific classes.
😱😱
Koin ☝
Thanks for showing us how DI works. But why bother to write all this boiler plate code? Hilt is stupidly easy to set up and use. Build time is not an issue for small projects. For bigger projects, you can go multimodule to slash down build times to almost nothing. I would not go with manual DI setup for any production app.
And small comparison between Koin vs Dagger2/Hilt: during runtime Dagger2/Hilt has only ~third of memory footprint of Koin.
Everything has pros and cons. Choose wisely :)
I don't understand why this much work for simple work, just use objects that will solve most of your singleton problems
I feel like Hilt is easier than this. 😅
Only because you have trudged up the mountain and are confiable with its methodology
Can you remember your first encounter with hilt/dagger and how it felt
This approach is a better step before full blown hilt implementation
@@ChrisAthanas Indeed, it was not easy for me until I implemented this in my projects.
@@Dibyendu.M exactly
The technique given here is a very useful in-between step
Shows the reason why a DI library is necessary but only after you fully understand it
Deploying the solution with Kotlin is a great way to introduce the DI concept, because it's very clear what's going on, so adding a DI library will be much less confusing
I disagree with this, especially when you're working with big Android team.
Great video thank you Philipp