Wrt Hilt: how does the `@InstallIn` work inside gr...

# dagger

[rattleshirt]

Wrt Hilt: how does the @InstallIn work inside gradle submodules? Would you need a sub component per module? I couldn’t find anything in the official doc regarding this.

[Javier]

You don't need to create components, just modules

[rattleshirt]

What if that module is inside a gradle submodule? @InstallIn requires access to the ApplicationComponent::class

[Manuel Vivo]

If @InstallIn is in the transitive dependencies of the module that contains the @HiltAndroidApp, that module will be automatically picked up and installed in the component you specified.

[rattleshirt]

Without actually specifying the ApplicationComponent?

[Manuel Vivo]

You need ApplicationComponent

[rattleshirt]

Ah, my bad. ApplicationComponent is actually provided by Hilt. 🤦

[rattleshirt]

So just adding the hilt-android dependency to the submodule would be enough

[rattleshirt]

But only android submodules I guess?

[Manuel Vivo]

Correct

[rattleshirt]

Alright, thank you

[Javier]

I think so, because that I have a specific android module for di

[rattleshirt]

Yeh, makes sense since it is android focused

[rattleshirt]

@Module(includes=) would do the trick for non-android submodules

[Javier]

I have to try, I like your idea if it works

[Manuel Vivo]

The only problem I see with that is that in tests, you cannot uninstall a module that is included in other module. If you don’t need to uninstall it, that sounds great

[Javier]

But you just uninstall the module which has the InstallIn annotation no? You don't need to uninstall the module inside the kotlin module no?

[wasyl]

So what’s recommended alternative for non-android modules? Having a separate component? A module and a separate module somewhere where I already have android framework dependency? (*I haven’t tried Hilt yet, so I might not know something obvious)

[Manuel Vivo]

Including Dagger modules that are in non-Android gradle modules from a Hilt module (that is in an Android module) installed in the right component is the best practice we found so far. There are some downsides like not being able to uninstall those Dagger modules from tests but... If you don't need that, it should be enough. You could also have scoping working using the @AliasOf annotation

[Manuel Vivo]

Relevant issue: https://github.com/google/dagger/issues/1908

[wasyl]

Gotta say this is highly disappointing. I understand Hilts goal was making android development easier, but ignoring common and useful use case of having non-android modules is not that helpful, and will only introduce inconsistency in the project. And once Hilt is stable and it’s not addressed (and I don’t have any hopes at this point) it’s gonna be same thing as with https://issuetracker.google.com/issues/123071304, so “it’s too late now, let’s make this change never”

[Javier]

I tried Kotlin Multiplatform libraries and I think they can be a nice way to solve this problem. For example I want to create a library called "core". Al Kotlin pure code will be in commonMain, the JVM in the jvmMain and the android in androidMain. Then if I add this core to a kotlin JVM module implementation("...:core") I don't need to put -jvm to get the jvm, and if I write the same snippet in an Android module, I don't need to add the -android (or another suffix) to get it. So using the same implementation(...:core) in all modules is easier than having to think if I have to add multiple implementation or just one.