Hilt and dependency injection - MAD Skills

Welcome to the first episode of the Modern Android Development Skills series on Hilt. In this episode, Android Developer Programs Engineer Manuel Vivo will introduce dependency injection (DI) and Hilt, Jetpack’s recommended solution for DI on Android.
Dependency injection in Android → goo.gle/3zcML4p
Dependency injection with Hilt → goo.gle/2W82Pq1
Hilt and Jetpack integrations → goo.gle/3ya3qo7
Hilt & Dagger Annotations → goo.gle/3B3qBSN
Dagger Hilt → goo.gle/3mo3s9v
Migrating to Hilt → goo.gle/381RV7z
Catch more videos on Hilt for MAD Skills → goo.gle/hilt-mad
Watch more MAD Skills episodes → goo.gle/madskills
Subscribe to Android Developers → goo.gle/AndroidDevs
#Featured #Latest #Hilt
product: Android - General; fullname: Manuel Vivo; re_ty: Publish;

[@amirgamil]

Thanks for this 👍 Can't wait for the next episode!

[@isamosso]

Great, Greeting from Mexico

[@witoldsienski1709]

Thanks for material :)

[@technics6215]

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.

[@NikolaDespotoski]

It would be great if we get guide on how to interact with vanilla dagger custom components.

[@TrevJonez]

hilt doesn't care about custom anything. the moment you depart from the prescribed component hierarchy they abandon you.

[@manuelvicnt]

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!

[@nadersada8453]

What's beomodel?

[@rizwansayyed7893]

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

[@adebisiyusuf436]

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?

[@manuelvicnt]

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

[@adebisiyusuf436]

@@manuelvicnt thanks for the clarification.

[@user-tg1yr1dt4n]

👍👍👍 Спасибо

[@hnim2292]

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!!

[@aseemsalim5845]

I mostly used kodein now migrating to hilt

[@endlessloverain]

I would like to know how to use assisted inject with hilt and Jetpack compose.

[@rob2theworld]

AssistedInject works like normal regardless of compose or no compose..

[@AnkitGupta-pn6od]

Add hilt worker dependency for assistedinject

[@rob2theworld]

@@AnkitGupta-pn6od that's only if your using a Worker

[@thangaduraiselvaraj9318]

How to use multi module projects?

[@nilesh8731]

Have to use dagger2 way

[@GakisStylianos]

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

[@TrevJonez]

@@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.

[@GakisStylianos]

@@TrevJonez are you asking why would one modularise their application if they're not doing dynamic delivery?

[@vazhakentchiashvili2198]

Thanks!

[@rupinderjeetsinghhans]

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.

[@wernerdittmann7579]

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.

[@gabormiklay9209]

Kotlin's 'object {}' rules, huh? 😉

[@ultraon83]

@@wernerdittmann7579 Dagger and Hilt provides compile time DI Graph validation. This is a really big and important stuff, especially for big projects.

[@hoangvinhly4842]

It's great 😇

[@arsal179]

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

[@samstoyroom]

I choose Koin :)

[@notbambang]

Same, it is more simple and easy to implement

[@aravindhsamidurai5300]

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.

[@rizwansayyed7893]

@@aravindhsamidurai5300 yes it uses reflection which performance costly

[@NeerajGupta-of9fy]

Hilt is not useful for multi module application, because as per documentation we have to use traditional dagger🗡️.

[@ultraon83]

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.

[@adebisiyusuf436]

@@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.

[@pcprincipal345]

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?

[@cularu1]

Hilt is simple and very useful.

[@ps3gamer132]

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...

[@hnim2292]

your comment makes sense to Dagger. Not Koin, not Hilt.

[@rizwansayyed7893]

@@ps3gamer132 agreed

[@rizwansayyed7893]

U can develop any library by saying it is modern way to do that

[@srikrishnanunna1]

Everything is so good, except your low voice .