what’s the best way to inject a primitive into the ViewModel constructor?

# dagger

[aperfilyev]

what’s the best way to inject a primitive into the ViewModel constructor?

[Colton Idle]

Couple of things:
1. More info of other libraries you're using would be helpful and where is the primitive coming from (a nav arg?). For example if you use AAC ViewModels + hilt + AAC navigation can inject argument primitives on your behalf that you can access via savedStateHandle. With no work to do on your end! I just implemented this recently and it's super convenient!
2. Inject a primitive at compile time? You can create a qualifier annotation for the primitive, or use the @Named qualifier to give the primitive a name and you can provide it that way.
3. Most likely though you shouldn't inject primitives/data classes, you should inject "services". So maybe you have some kind of MyPrimitiveProviderService which has a bunch of primitives, and therefore you can just inject that entire type instead of just a single primitive.
4. If you want to provide values at runtime, then that is not currently possible. "Hilt does not support assisted injection (values provided at runtime):" https://github.com/google/dagger/issues/2287
Sorry for the long answer, but yeah. Depending on whether you are using AAC VM, hilt or dagger, AAC navigation will change the answer a bit I think. Also, if you are looking for runtime or compile time injection then the answer also changes.

Note: I'm not an expert at dagger. The above info just comes from my experience recently with dagger.

[Jeremy]

Injecting primitives with a qualifier/named is fine. I do this sometimes

[aperfilyev]

@Colton Idle thanks for such a detailed answer. I was interested in mainly providing values at runtime when navigating between screens in composable functions. As I read more and more about Compose I decided to just ditch AAC ViewModels altogether and use some kind of AppState object with screen states exposed as observable values.

[FunkyMuse]

You can use the savedstatehandle
Works well with navigation arguments

[Jeremy]

AAC viewmodels were always strange abstractio_n_ and overused. If doing a pure compose I'd also avoid them

[FunkyMuse]

The abstraction was strange because you had a bad instantiation of Fragments and Activities, they had no control over those components and had to do a bad abstraction of ViewModels as well, however if doing Hilt with compose, AAC ViewModels are here to ease your life, although if you're going the multi platform route you should avoid anything platform agnostic and go for a cross-platform solution, which either doesn't exist or you have to build it yourself, battle test it and then claim something is strange abstracted, don't take this as an attack to your statement, but try to implement a view model yourself and you'll see the pain

[Jeremy]

What we wanted :
• persist key value pairs across activity lifecycle INCLUDING process death
What we go:
• Solution that adds another lifecycle and doesn't survive process death
• Solution that forces us to inherit a specific class hierarchy coupled to Android and opinionated guidance to put our business logic into this android specific class

[Jeremy]

Its official guidance so now all apps need to adapt

[FunkyMuse]

If you want to just persist keys you can use rememberSaveable

View model has a different purpose than just that

[Jeremy]

That won't work for running threads. The alternatives to viewmodel have been deprecated/removed