Full Guide to Manual Dependency Injection + Removing Dagger
HTML-код
- Опубликовано: 29 авг 2023
- In this video you'll learn how you can get rid of Dagger-Hilt and start manually injecting your dependencies to have the same advantages while minimizing build time and errors.
Secure your EARLY BIRD discount for my new testing course bundle! (just a few more days)
pl-coding.com/testing
Initial branch with Dagger:
github.com/philipplackner/Man...
Final branch with manual DI:
github.com/philipplackner/Man...
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.
Now I agree 👍 good clarification
My question is how are these singletons released after they go out of scope and no longer necessary?
And what about scopes?
@@paulsoja2732 this when manual DI fails
@@ChrisAthanas a jvm singleton is never released
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!
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!
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
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.
Ths simple approach works also for other languages and contexts, I'll be using it! Thanks!
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.
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 😄
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 ;)
🇱🇹
Thank you Philipp you are the best 🙏🔥
i really enjoy your videos. thanks!
Thanks, nice approach !
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
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.
always make usefull content 🤝
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.
Awesome, thank you 😀
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?
Would have been nice to speak about singletons and factories in this
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
Great video thank you Philipp
What about objects that should survive a configuration change, but should not be singletons? Use some class container with onRetainNonConfigurationInstance?
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!
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 ;)
Hi Philip this is good stuff now
Thank you!
I can hear Vasiliy applauding in the back of the room 😀
Did you ever find a way to reset or clear the ViewModel instance without Hilt?
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
Just yesterday solving dagger-hilt errors,,,,,Thank you aloot
Naaah, no way, I never give up on Dagger, it is been almost 3 years and I just finally understood all his power
What about Koin, it would be an alternative for you or def not?
@PhilippLackner Please tell how to create viewModel without hilt annotation but still with dependencies provided by hilt? Please please please!
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?
@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.
Great video!!! But after learn manual DI, think again Hilt and Dagger is a good library.
Does this work only on android apps or can it also work on KMM projects?
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 :)
Nice trick
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".
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
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.
KSP is coming, soon will have a faster processor 😉
Video is already planned :D
Great
how can i pass arguments now ?
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!
I wasn't a big fan of koin, but koin-annotation made Hilt stop appealing to me - it's all about the configuration.
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 🙂
NICE!!!!!
Don’t we need dagger for compose navigation?
Why would you?
I think Kotlin should come up with a DI framework *as a part of the standard library* or a kotlinx library like Coroutines.
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
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.
goat
Thank you very much! But, how do you know, what I need right now? 😊
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
👏
🎉
This is service locator not dependency injection
Koin for the win
is Dagger or Hilt free?
Yes it’s free
Just very steep learning curve and difficult to work with
Thats why i perfer KOIN its a great balance and simpler approach than dagger
It's Wednesday again!
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?
Manual DI?
Hey Philipp, make a project on jetpack media3. Please, consider this.
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?:)
😱😱
Koin is better for small or kmp projects than manual DI
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
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.
I prefer koin over dagger. Dagger seems massively overcomplicated to me.
You should not be passing the AppModule itself to the ViewModel, even with manual DI. Other than that, great video.
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
Koin ☝
Okay, thank you, but I will still use Dagger😂😂
Finally someone saved us from dagger's sharpness
There’s koin
I totally disagree, I'm working on real world apps that have millions of users and more than 20 Android developers
Using Hilt in Android development offers several advantages such as simplified configuration, reduced boilerplate code, and ease of maintenance. It automatically handles the complexities associated with component lifecycles, allowing for more streamlined and readable code. Hilt also provides compile-time validation, which makes it easier to catch errors early in the development process. By using annotations, it makes dependency injection more declarative and easier to understand, improving code readability and reducing the likelihood of mistakes. On the other hand, manual dependency injection, while offering more control, can become increasingly complex and error-prone as your project grows. Manually managing component lifecycles and dependencies can lead to a fragmented and less maintainable codebase. Additionally, the lack of compile-time validation in manual dependency injection means errors may only become apparent at runtime, making debugging more challenging.
Then you got wrong what I wanted to show with this video, see my pinned comment :)
In the video, you mentioned that you're unsure why dependency injection in Android is complicated, suggesting that perhaps Dagger Hilt solves a "mysterious problem." The complexity arises from Hilt's capability to manage dependencies using a Directed Acyclic Graph (DAG) that also takes care of the lifecycle management of the components your class relies on. This becomes increasingly challenging to handle manually in larger apps, and mistakes can lead to runtime errors. While it's true that for smaller, tutorial-level apps, you might be able to sidestep these issues, they become critical in real-world applications. These complexities not only pose a risk in terms of application stability but also contribute to productivity issues and technical debts, especially when new developers join the team. All these challenges can pose significant risks for a company.
This is a lot of words to say effectively nothing..
I’m sorry but it’s true. You’re just repeating over and over how it makes the code mor maintainable, scalable but you never mention why you think that?
Also I am not sure what compile time safety you think you get with dagger hilt that you don’t get with manual DI?
You have all the safety with manual DI. Your app will not compile if you don’t provide all dependencies since you’re the one calling the constructors.
Dagger / hilt is easier to understand and maintain then plain Kotlin code? I’m sorry but if you don’t understand Kotlin code then how will you understand any other part of your code base?
@@skullkrum20 I'm so sorry for you if you didn't understand the meaning, and sorry it's really obvious what does it mean scalability and maintanabilty when you have experience.
When you write less code you get less errors so better maintenance.
@@skullkrum20 with manual DI you are never safe. And especially when you have a lot of contains in the app, while you are trying to resolve memory problems related to the lifecycle of your app
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
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.
goat