Great explanation! I am more comfortable with manual dependency injection. In future, when Hilt is deprecated, and Jetpack Jilt is introduced, I will have nothing to change in my code. I feel Hilt is polluting my code by being omnipresent with annotations everywhere.
Kotlin supports manual DI much better than Java, for example. Just think of default and named parameters, lateinit and also delegation (by). Using a well designed Factory Pattern solves most problems as well, also without too much boilerplate code. I did instrumented tests with mockk and delegation and this just required a few lines of code. Using Hilt would be more complex.
You can find more about that in developer.android.com/training/dependency-injection/hilt-multi-module and dagger.dev/hilt/migration-guide.html ; Hope it helps!
Manual DI is a really great way to get things done. Google is on a crazy journey to introduce new things every couple of months. All these libraries and most of them only provide a little improvement over the existing method and usually come at a cost of huge learning curves. Soon, hilt will be deprecated as well in the name of some other cartoon library
Can you use other than `Application` types of context? Like `Activity` or `Fragment`? I'm asking because I need to satisfy a library that needs Activity context.
Based on the @InstallIn annotation, does it mean then that higher components (e.g. SingletonComponent) in the components hierarchy can accommodate bindings or dependencies annotated with scopes (e.g. @ActivityScope) of components down the hierarchy?
No, they can only accommodate unscoped bindings (no scope annotations) or bindings scoped to its component. That is, the Application class cannot inject a type that is scoped to the ActivityComponent
Do you think it was omitted by accident? 😅The hard stuff is always the ones not talked about too much. But anyway, take a look here developer.android.com/training/dependency-injection/hilt-multi-module
@@GakisStylianos what is intended by multi module? the tree of projects matters. if it is dynamic delivery features in an aab, hilt doesn't support it and based on the github issues, they don't intend to. So was it omitted by accident? NO. they don't care about that in hilt. Hilt doesn't care about domain specific needs.
How to provide Singleton object only to a specific flows ? I.e I want to use same object in my login screen ,registration screen and forget password screen
I'm fairly new to android, kotlin and compose. I briefly tinkered with android about a decade ago, and was annoyed with the fragmented libraries, versions and documentation. Nothing has changed. It looks like it even got worse. The most absurd thing about the Android API is...that it's not the recommended way of working. You need Jetpack. Ok ..Ill install it, is it a library? Well... it's Jetpack compose ...Ah, ok, I'll install the Jetpack and the Compose library then...No, it's just Compose...Just Compose? Ok, a bit confusing, but better one library than two! Well actually, compose is a set of libraries...Ok, I'll install all of them. What's the command? No...just paste the libraries in your gradle...actually no ...paste the libraries in your versions.toml file...but it's a different syntax...no, you're not done...you now still have to add the libraries to the gradle file ... it's yet another syntax.... Are we done??? Well....did I tell you about Hilt?... Ok I'll install Hilt!! No, not just the library, also the plugin...and the kapt plugin... Seriously??? Oh and don't forget to put it in the versions.toml...and the different syntaxes ... Ok with all those extras, it better be simple to go from ScreenA to ScreenB! You need navigation... there's tutorials....
Koin is easy to learn and implement compare to Hilt but the problem is koin is not checking the satified dependencies in compile time it's only checks in run time so we face some exception in app runtime.
DI libraries are overrated and too complex to implement. And since everytime and with every project there is a new DI library, they are just not worth the effort for learning. Hell what's wrong with Spring Boot's Bean. It is too simple, you just annotate something as bean and inject it elsewhere with just one annotation. Why do all the Android libraries have to be spaghetti codes and have their own syntax? Why not make life simpler instead of making it harder for us developers?
Damn this hits home! Truthfully this can be said for the whole Android ecosystem...over engineered code everywhere and pretty hard to understand... especially if you are a newbie...
It is possible, just declare InstallIn annotation for the appropriate predefined by Hilt components for your DI Modules. If you expose Dagger component from gradle modules, then try to wrap your components with a Dagger Module (using InstallIn annotation) and provide the appropriate binding (mapping). Consider that approach as a workaround, because Hilt uses monolithic approach (versus polylithic), and pay attention, if you provide different implementations under the same interface from different modules, you should either introduce more specific different interfaces or use Dagger qualifiers, to mark the appropriate interfaces. You will see those issues during compilation if you have them.
@@ultraon83 For multi modules apps, it works like you said by using the @installIn but I cannot seem to use any other components apart from the SingletonComponent for my bindings. If I use an ActivityComponent for example, hilt returns errors of missing bindings even when those bindings exists.
Great explanation!
I am more comfortable with manual dependency injection. In future, when Hilt is deprecated, and Jetpack Jilt is introduced, I will have nothing to change in my code.
I feel Hilt is polluting my code by being omnipresent with annotations everywhere.
Kotlin supports manual DI much better than Java, for example. Just think of default and named parameters, lateinit and also delegation (by). Using a well designed Factory Pattern solves most problems as well, also without too much boilerplate code. I did instrumented tests with mockk and delegation and this just required a few lines of code. Using Hilt would be more complex.
Kotlin's 'object {}' rules, huh? 😉
@@wernerdittmann7579 Dagger and Hilt provides compile time DI Graph validation. This is a really big and important stuff, especially for big projects.
Thanks for this 👍 Can't wait for the next episode!
Remember the bad old days when when you have to do a lot of works to provide dependencies to view model. Hilt is the savior!!
It would be great if we get guide on how to interact with vanilla dagger custom components.
hilt doesn't care about custom anything. the moment you depart from the prescribed component hierarchy they abandon you.
You can find more about that in developer.android.com/training/dependency-injection/hilt-multi-module and dagger.dev/hilt/migration-guide.html ; Hope it helps!
Manual DI is a really great way to get things done. Google is on a crazy journey to introduce new things every couple of months. All these libraries and most of them only provide a little improvement over the existing method and usually come at a cost of huge learning curves. Soon, hilt will be deprecated as well in the name of some other cartoon library
Can you use other than `Application` types of context? Like `Activity` or `Fragment`?
I'm asking because I need to satisfy a library that needs Activity context.
Great, Greeting from Mexico
I would like to know how to use assisted inject with hilt and Jetpack compose.
AssistedInject works like normal regardless of compose or no compose..
Add hilt worker dependency for assistedinject
@@AnkitGupta-pn6od that's only if your using a Worker
Based on the @InstallIn annotation, does it mean then that higher components (e.g. SingletonComponent) in the components hierarchy can accommodate bindings or dependencies annotated with scopes (e.g. @ActivityScope) of components down the hierarchy?
No, they can only accommodate unscoped bindings (no scope annotations) or bindings scoped to its component. That is, the Application class cannot inject a type that is scoped to the ActivityComponent
@@manuelvicnt thanks for the clarification.
How to use multi module projects?
Have to use dagger2 way
Do you think it was omitted by accident? 😅The hard stuff is always the ones not talked about too much. But anyway, take a look here developer.android.com/training/dependency-injection/hilt-multi-module
@@GakisStylianos what is intended by multi module? the tree of projects matters.
if it is dynamic delivery features in an aab, hilt doesn't support it and based on the github issues, they don't intend to. So was it omitted by accident? NO. they don't care about that in hilt.
Hilt doesn't care about domain specific needs.
@@TrevJonez are you asking why would one modularise their application if they're not doing dynamic delivery?
How to provide Singleton object only to a specific flows ? I.e I want to use same object in my login screen ,registration screen and forget password screen
What's beomodel?
Thanks for material :)
I mostly used kodein now migrating to hilt
I'm fairly new to android, kotlin and compose. I briefly tinkered with android about a decade ago, and was annoyed with the fragmented libraries, versions and documentation. Nothing has changed. It looks like it even got worse.
The most absurd thing about the Android API is...that it's not the recommended way of working. You need Jetpack. Ok ..Ill install it, is it a library? Well... it's Jetpack compose ...Ah, ok, I'll install the Jetpack and the Compose library then...No, it's just Compose...Just Compose? Ok, a bit confusing, but better one library than two! Well actually, compose is a set of libraries...Ok, I'll install all of them.
What's the command? No...just paste the libraries in your gradle...actually no ...paste the libraries in your versions.toml file...but it's a different syntax...no, you're not done...you now still have to add the libraries to the gradle file ... it's yet another syntax....
Are we done???
Well....did I tell you about Hilt?...
Ok I'll install Hilt!!
No, not just the library, also the plugin...and the kapt plugin...
Seriously???
Oh and don't forget to put it in the versions.toml...and the different syntaxes ...
Ok with all those extras, it better be simple to go from ScreenA to ScreenB!
You need navigation... there's tutorials....
Thanks!
It's great 😇
I choose Koin :)
Same, it is more simple and easy to implement
Koin is easy to learn and implement compare to Hilt but the problem is koin is not checking the satified dependencies in compile time it's only checks in run time so we face some exception in app runtime.
@@aravindhsamidurai5300 yes it uses reflection which performance costly
👍👍👍 Спасибо
DI libraries are overrated and too complex to implement. And since everytime and with every project there is a new DI library, they are just not worth the effort for learning.
Hell what's wrong with Spring Boot's Bean. It is too simple, you just annotate something as bean and inject it elsewhere with just one annotation. Why do all the Android libraries have to be spaghetti codes and have their own syntax? Why not make life simpler instead of making it harder for us developers?
Hilt is simple and very useful.
Damn this hits home! Truthfully this can be said for the whole Android ecosystem...over engineered code everywhere and pretty hard to understand... especially if you are a newbie...
your comment makes sense to Dagger. Not Koin, not Hilt.
@@ps3gamer132 agreed
U can develop any library by saying it is modern way to do that
Hilt is not useful for multi module application, because as per documentation we have to use traditional dagger🗡️.
It is possible, just declare InstallIn annotation for the appropriate predefined by Hilt components for your DI Modules. If you expose Dagger component from gradle modules, then try to wrap your components with a Dagger Module (using InstallIn annotation) and provide the appropriate binding (mapping). Consider that approach as a workaround, because Hilt uses monolithic approach (versus polylithic), and pay attention, if you provide different implementations under the same interface from different modules, you should either introduce more specific different interfaces or use Dagger qualifiers, to mark the appropriate interfaces. You will see those issues during compilation if you have them.
@@ultraon83 For multi modules apps, it works like you said by using the @installIn but I cannot seem to use any other components apart from the SingletonComponent for my bindings. If I use an ActivityComponent for example, hilt returns errors of missing bindings even when those bindings exists.
Everything is so good, except your low voice .