Hello, is there a guideline how to use

launchInHiltContainer

from the

architecture-samples

with ViewModels that have an @AssistedFactory ?

If I have missing bindings, could I use https://dagger.dev/dev-guide/spi to find out what those missing bindings are and generate new dagger modules which will fix those?

Dagger/Hilt is throwing an error during build that's making me confused:

BookStoreNotesApplication_HiltComponents.ViewModelC repeats modules with scoped bindings or declarations:

More details in thread!

What is going on here? I was cleaning up my

BaseApplication

and when I remove the last injection, I get this when compiling tests:

Cannot process test roots and app roots in the same compilation unit:
  App root in this compilation unit: vide.BaseApplication
  Test roots in this compilation unit: [vide.Test1, vide.Test2, ...]

Is it possible to Mock out Hilt Assisted viewmodel dependencies?

I've been out of the dagger/hilt game for a little bit so just want a sanity check. I have a class that is annotated with @Inject, and it seems like I can use it in my android HiltViewModels just fine. That class is not in any @Module though. I now want to make that @Inject a

@Singleton

but, does that mean I have to add it to a module that it @InstallIn(SingletonComponent:class)?

I have a

ComponentsCache

which holds

Component

instances (currently just a flat list of Any) I use hierarchies of components, i.e. subcomponents. When I delete component X from the cache, I want to remove it's children automatically as well. Therefore I need a

parent-child relationship

between the components. I could handle all this myself, i.e. have some sort of

CacheNode(component, parentCacheNode)

etc. However, I do know child components do have a parent component reference. Is this accessible from outside somehow? (So I avoid having a multiple sources of truth)

Hey does AssistedInject with Hilt support SharedViewModels, or will a new instance always be created?

Is hilt KSP suppose to generate java file ?

Is there a better way to provide Retrofit/OkHttpClient instances with different timeouts using Dagger Hilt than duplicating everything? More in 🧵

trying to figure out the difference between using the new

@LazyClassKey

annotation and having a custom

@MapKey

and accessing that map with

Map<Class<out Foo>, @JvmSuppressWildcards Provider<Foo>>

I am using KSP to generate certain code. I want dagger(kapt) to provide that code but dagger fails with

unable to resolve

even though the files get successfully generated. I am assuming it because of some order issue. is it possible to change the order of annotation processing so that my code generated by KSP always runs first and dagger's(kapt) runs after?

Hello everyone! We need to regenerate the whole dependency graph on logout. We know that a better solution would be managing the reset of the Singletons (it's not doable considering the current size of the codebase) or use a custom component (this would require writing boilerplate code anyway). The limitation of Hilt, that makes impossible to regenerate the graph, led us to this possible hack:

@HiltAndroidApp
class LogApplication : Application() {

    @Inject
    internal lateinit var dependency: LoggerInMemoryDataSource

    override fun onCreate() {
        super.onCreate()
        logout()
    }

    @Suppress("CAST_NEVER_SUCCEEDS")
    private fun regenerateComponent() {
        Log.d("", "Before: $dependency")

        val cm = (this as GeneratedComponentManagerHolder).componentManager()
        val f = ApplicationComponentManager::class.java.declaredFields.find { it.name == "component" }
        f?.let {
            it.isAccessible = true
            f.set(cm, null)
        }
        ((this as GeneratedComponentManager<ApplicationComponentManager>)
            .generatedComponent() as LogApplication_GeneratedInjector)
            .injectLogApplication(UnsafeCasts.unsafeCast(this))

        Log.d("", "After: $dependency")
    }

    fun logout() {
        regenerateComponent()
    }
}

(LoggerInMemoryDataSource is a singleton and the reference is changing) Do you foresee any drawback apart of the need of testing on every Hilt upgrade? Should we propose to support this use case in Hilt? Thanks!

Hello, do you know any Open source project that uses hilt and/or anvil? I have a dagger plugin to detect dead code on dagger configuration and I have some huge projects internally where I can test it. But neither or them use hilt nor anvil so I would like to test it on non-trivial projects with hilt and anvil.

How do I deal with Dagger when going multuplatform? Obviously it cannot be in common, but I already have a project written and @Inject constructors everywhere Should I remove @Inject ctors and move to a @Module which would live in androidMain? Or is there a way to bend it so I don"t have to rewrite source? i.e. keep the @Inject annot. in common and somehow just expect actual it?

Hilt question I have an app module and a feature-module. In the feature module I have a class that requires applicationContext. I add it to the constructor with the @ApplicationContext annotation. Everything works fine. In the same class, I now require activityContext... so I do

@ActivityContext private val activityContext: Context

but I get a compile time error about Context not being provided. Is this use case of using two qualified contexts, not supported for some reason? or is Hilt bugging out on me

Is it possible with Hilt to use assisted inject with 3rd party class, when you can’t add annotations to constructor of that class?

I'm working in a codebase that already has a simple dagger/hilt module setup as such:

@Module
@InstallIn(SingletonComponent)
interface MyModule {
  companion object {
    @Provides
    @Singleton
    fun provideThing(builder: MyBuilder): Thing = builder.build()
  }
}

I'm not sure of the reason why this is an interface with a companion object. Can someone explain why? Additionally... if I wanted to add a new provides method for a simple Foo object would I just do @Provides fun provideFoo() = Foo() inside of the companion object, or outside of the companion?

I'm trying to create a cache of Component instances, such that it forms a tree, so if I remove the parent instance from it, all it's children will get removed as well. When I have a Subcomponent B which is a child of A, it internally has this

aComponentImpl

reference. Is there a way to get it from outside? (i.e. to figure out who the parent of bComponent instance is?). Or do I need to track this myself (although not a single source of truth)

Hello! Does anyone have any example how to generate code in the New Dagger SPI plugin (with KSP support) side of things?

initFiler

doesn't exist anymore, so I guess I have to go get

processingEnv?.ksp()?.codeGenerator

instead? Some examples would be welcomed 😊

In

dagger-spi

is there a way to modify the binding graph ? I've generated dagger modules for missing bindings and I'd like to add those modules (or components?) to the bindingGraph 🤔

I have component graph of

App -> User
  |_-> RegistrationFlow

i..e user na registration are children of app, but don't see each other. There is a dependency

Foo

that only needs dependencies from

App

component, so it's injectable in bot

User

and

RegFlow

, however I want to cache it per child scope. i.e instance1 in

User

and instance2 in

RegistrationFlow

as it is stateful. Is this possible? Other than not having

@Inject

on Foo and having 2 module

@Provides

functions Basically I want

@User
@RegistarationFlow
class Foo @Inject constructor(..)

but compiler complains

Sorry I’m having issue with dagger 2, crash OOM when app uses multiple fragments, it seems viewmodel is destroyed, but data is still referenced here, and it causes memory leak?

👋 Hi folks My app has this scenario From workmanager's worker class I update a Singleton EventBus and my HomeViewModel listens to it and shows a UI modal UI Testing scenarios like this when using

EarlyEntryPoints

is not possible As Worker class dependencies uses a different graph of objects and doesn't share any state with Singleton graph Any workarounds to test cases like this? https://dagger.dev/hilt/early-entry-point

One thing from like maybe like wayyyy back when at Droidcon montreal I feel like I remember Jake saying that one of the benefits of something like Dagger is that its helpful vs other DI approaches because you can also swap dependencies at runtime (so you still get compile time safety, but there was like some runtime aspect to it). This was like 10 years ago at this point and was curious if anyone recalls if anything I'm remembering is true at all 🙈

Hi folks, Not sure where to post this query, I wanted to know how the hilt is able to bind the dependency from higher level module to a lower level module component. Ex: Module

A

has an interface(

SampleInterface

) whose implementation is requested in the

Activity

, Module

app

provides the implementation of the

SampleInterface

and binds it. How is lower level module's activity is injected with the Implementation from the higher level module FYI:

SampleInterface

is bound to the

ActivityScope

If anyone here is feeling generous to help with fixing a KSP memory leak by helping me with Dagger's build process to use a dev Kotlin compiler build, would appreciate it 🙏

I'm using hilt in my project to lazily inject a

TTSProvider

instance. I would like to check whether it has been initialized when cleaning up. Is there a better/prettier solution than my current one?

@Provides
fun provideLazyTTSProvider(
    ttsProvider: dagger.Lazy<TTSProvider>,
): kotlin.Lazy<TTSProvider> {
    return kotlin.lazy { ttsProvider.get() }
}

Dagget KSP has been know to have worse performance over kapt version. Is this still true for KSP2?

Is there anything inherently wrong returning a

Deferred<T>

from

@Provides

, like this:

@Provides
@Singleton
fun provideAppConfig(
    coroutineScope: CoroutineScope
): Deferred<AppConfigValues> =
        coroutineScope.async {
            ... some suspend functions ...
            AppConfigValues()
        }