View models and hilt

[alanjhughes]

Hi,

Could we get some examples added for using view models and hilt?

[LachlanMcKee]

Hi @alanjhughes

I'm currently working on a proposal for using hilt with the library. It should be ready for a 1.1.x release of the library.

I will take make sure I keep view models in mind

[OneFiveFour]

Hey, any progress on this one? We are facing similar issues:

Context

• Single activity app
• Hilt for dependency injection
• Compose-only views with Appyx navigation v"1.2.0"

Problem

1. We cannot use fine grained Hilt scopes, like @ActivityRetainedScoped or @ViewModelScoped. We could only define our own scopes and tie them to the Appyx Node lifecycle, but that would be a lot of effort.

2. We use Android ViewModels for most of the state hoisting for our Views (=Nodes), but the ViewModel lifetime is equal to the app's lifetime in the single activity context, because ViewModels are attached to activities/fragments instead of Nodes. Example: If I reuse a complex view (=Node) in two different locations within the navigation, I receive the same ViewModel instance for both. In that case I would have to clear and reinitialize the ViewModel’s state whenever I enter another instance of the same node which also leads to som e form of manual backtracking of the states.

What would help?

Either
Hilt-components that are based on the Appyx node lifecycle, e.g., @NodeScoped, because then we could use hilt to inject/maintain ViewModel instances and others.
or
Making Node a ViewModelStoreOwner, so that each node creates, maintains and destroys its own ViewModels

[KovalevAndrey]

Hi @OneFiveFour, in regards to the ViewModels we haven't agreed on whether it should be part of the library or not just yet. However, we have exactly the same functionality provided by the library. Please check out this doc

You could even use your ViewModel class if you don't register it and have a separate method for cleaning up which can be called outside:

val vm = buildContext.getRetainedInstance(
    factory = { VideModel() }, // will not create a new instance upon orientation change. Instead will provide the retained one.
    disposer = { it.cleanUp() } // will be called when Node is destroyed. Not called upon orientation change 
) 

[slortz]

Hi @KovalevAndrey, thanks for your quick answer. I'm from the same team as @OneFiveFour. Could you briefly explain/point to a resource where I could learn how you/bumble hoists state and ui logic for views? It appears to me like view models are not part of your solution, right?.

[zsoltk]

Hey @slortz, this is what we use:

1. https://medium.com/bumble-tech/building-a-system-of-reactive-components-with-kotlin-ff56981e92cf
2. https://medium.com/bumble-tech/unidirectional-data-flow-and-the-zen-of-black-box-components-fff5d618f8b6

You're right, we're not using ViewModel (we use this word in the article to refer to data classes without any logic in them that the view can use to render text / image etc.).

Our approach is MVICore + Binder, but Appyx should allow you to use whatever else you like. If you struggle to use ViewModel / or the RetainedInstanceStore, we'd like to hear why! (Also feel free to come over to the #appyx channel on slack for a more dynamic discussion).

[slortz]

Thanks for the insights. We will try the path with Hilt ViewModels and a bit of glue code that binds it to nodes. We might report our experiences a bit along the road. :)