Hilt was promoted to stable in v2.35 :clap: <https...

# dagger

[Manuel Vivo]

Hilt was promoted to stable in v2.35 👏
https://github.com/google/dagger/releases/tag/dagger-2.35

[Colton Idle]

Hilt doesn't have any section in the readme on how to use it, right? Or am I just missing something. I see this though

Gradle

// Add Dagger dependencies
dependencies {
  implementation 'com.google.dagger:dagger:2.x'
  annotationProcessor 'com.google.dagger:dagger-compiler:2.x'
}

If you're using classes in dagger.android you'll also want to include:

implementation 'com.google.dagger:dagger-android:2.x'
implementation 'com.google.dagger:dagger-android-support:2.x' // if you use the support libraries
annotationProcessor 'com.google.dagger:dagger-android-processor:2.x'

[Colton Idle]

Only reason why I ask is because I currently have this

implementation("com.google.dagger:dagger:2.34.1")
implementation("com.google.dagger:hilt-core:2.34.1-beta")
implementation("com.google.dagger:hilt-android:2.34.1-beta")
kapt("com.google.dagger:hilt-android-compiler:2.34.1-beta")

root build.gradle

id("dagger.hilt.android.plugin")

and I want to make sure that I'm actually using the right dependencies as I feel like some thing changed since I first started using hilt.

[Manuel Vivo]

https://dagger.dev/hilt/gradle-setup

[Manuel Vivo]

It’s in dagger.dev

[Jeremy]

Awesome, congrat to team on big milestone

[Manuel Vivo]

What do you mean exactly? Extend from the SingletonComponent? or contribute to the SingletonComponent from a different module?

If it’s the former, you can use the @DefineComponent annotation, see: https://medium.com/androiddevelopers/hilt-adding-components-to-the-hierarchy-96f207d6d92d

If it’s the latter, you should be able to install all the modules in the SingletonComponent directly.

[ultraon]

My question was about the item #2 (`Contribute to the SingletonComponent from a different Gradle module using dependencies attr in @Component annotation`). Thank you for your answer @Manuel Vivo. I have impression that using DI Module approach with InstallIn annotation library internal entities may leak into SingletonComponent accidentally, but using interface contract (library Component) I can control what exactly entities will be available in SintletonComponent.

[ultraon]

Let me share a bit code

[ultraon]

Comments:
So we have 2 modules:
- library module that provides some CarEngine (under public interface)
- application module that uses library above and builds Car with CarEngine

Library exposes only interface CarEngine, all internal details (Turbine, EngineTurbine, TurbinedCarEngine) are closed,
so application module can't use them directly.

Untitled.cpp

[ultraon]

The main question:

- Is it possible to have a similar dependency encapsulation using Dagger Hilt?

[Manuel Vivo]

I understand your concern but that’s actually how monolithic components work. When you install something in a Hilt component, it’ll be seen by everyone that has access to it. The rationale about why the team made that decision is here: https://dagger.dev/hilt/monolithic.html

[ultraon]

Thank you very much!