How can I have a viewmodel that persists all throughout my app? Then one that persists only one scre...

# compose

[zt]

How can I have a viewmodel that persists all throughout my app? Then one that persists only one screen? With them both supporting backstack. I'm using this small library https://github.com/X1nto/Taxi as opposed to compose destinations and androidx navigation cause its a lot simpler and animation is super easy. I'm just not sure how to get my viewmodels to behave how I want them to.

Surface {
    Taxi(
        modifier = Modifier.fillMaxSize(),
        navigator = navigator,
        transitionSpec = { fadeIn() with fadeOut() }
    ) { destination ->
        when (destination) {
            is AppDestination.Root -> RootScreen(navigator)
            is AppDestination.Search -> SearchScreen(navigator = navigator)
            is AppDestination.Player -> PlayerScreen(
                navigator = navigator,
                videoId = destination.videoId
            )
            is AppDestination.Channel -> ChannelScreen(
                navigator = navigator,
                channelId = destination.channelId
            )
            is AppDestination.Settings -> SettingsScreen(onClickBack = navigator::pop)
        }
    }
}

Settings, Search, Player, Channel should all be scoped to the one screen.

I'm using koin for injecting my viewmodels like this

fun SearchScreen(
    viewModel: SearchViewModel = getViewModel(),
    navigator: BackstackNavigator<AppDestination>
) {

[Ian Lake]

That navigation library offers no support for scoping ViewModels to individual screens - the only thing it scope per screen is the saved state (i.e., rememberSaveable): https://github.com/X1nto/Taxi/blob/6c5a814bd27bb0e2380052eb882cb0f564f4364b/lib/src/main/java/com/xinto/taxi/Taxi.kt#L41

[zt]

So the library would have to add support for it? I was discussing with the developer of it and they had me convinced that the library wasn't gonna be responsible for it. I tried figuring out how to scope it to screens but I couldn't figure it out

[Ian Lake]

You can't just tack it on after the fact, no. E.g., when they pop a screen off the back stack, that needs to be a signal to destroy the entire ViewModelStore associated with that screen (which would be what would clear out every ViewModel you scoped to that ViewModelStore). But you can't even destroy the ViewModel right there - you need to wait for your screen to actually finishing animating out (as it will continue to recompose as it exits its AnimatedContent with whatever transitionSpec you've defined)

[Ian Lake]

And actually, I don't think that library even handles save state correctly - you need to call saveableStateHolder.removeState when you pop a screen off the back stack, so I'm pretty sure any screen you ever push onto that stack is going to be saved forever, even if you popped it off the stack

[Ian Lake]

It probably also has the unfortunate case where if you pop a screen off the stack, then go back to it (assuming you are defining your AppDestination as an object like their example does), that instead of getting a fresh copy of your screen, you end up getting the previous, popped screen's state back...

[zt]

Yea, I was having my screens saving data and not getting cleared. ^ exactly

[Ian Lake]

Which, I guess if that's what you want....then having a global ViewModel that never gets cleared is at least consistent 🙃

[Ian Lake]

(well, it would get cleared when the containing fragment/activity is cleared, so eventually it'll get cleaned up)

[zt]

What I want is a global state, or some way to keep some stuff all through out my app. Since the main functionality is playing videos which would need to be accessed in the full screen player and the mini-player too. And other screens would have regular screen-scoped viewmodels

[Ian Lake]

yeah, that's a pretty normal requirement, which is why Navigation Compose has supported that out of the box since the first alpha back in October 2020. Not sure why other navigation libraries haven't done something similar (they certainly can, nothing is stopping them - Navigation Compose uses the same public APIs that are also available to them)

[dewildte]

What's wrong with having an activity scoped VM?

[dewildte]

Unless your activity is being destroyed when you go to mini player?

[zt]

It's all one activity

[dewildte]

So that activity is global then

[dewildte]

Scope the ViewModel to the Activity and boom you have a global ViewModel no?

[zt]

i'm not sure how to do that

[dewildte]

Pass the activity in as the lifecycle owner.

[dewildte]

When you get the VM from the provider.

[Ian Lake]

That's the default scope if your navigation library isn't doing anything special. I don't think that's the unsolvable problem though: it is the single screen scoped ViewModels

[dewildte]

Maybe I am not understanding the problem.
Can you get the state you require from a data source that is tied to the lifecycle of the Application class then?

[dewildte]

Like a repository would be a singleton who's reference is held by the Application class.

[dewildte]

That way all consumers get the same source of truth.

[zt]

@Ian Lake so I'm guessing my only choice here is using androidx navigation? not really a fan of the way it handles arguments though, and strings for routes

[Ian Lake]

Or Compose Destinations if you want to abstract those bits entirely away. The only arguments you should passing in 99% of the time are the unique IDs of what you are loading anyways

[zt]

I was using compose destinations but its method of animations was causing me problems and had slow build times with it

[Ian Lake]

It is pretty straightforward to write two line type safe wrappers around Navigation Compose if you don't want to take the build time speed hit of having to generate it every time, we had talked about that previously: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1660233995063049?thread_ts=1660227596.881239&cid=CJLTWPH7S

[zt]

@Ian Lake found this pretty neat library that looks like it solves all the problems ive had with the other libs: https://github.com/kiwicom/navigation-compose-typed

[Ian Lake]

That's a really slick approach, thanks for sharing it

[zt]

it would be cool if the official library got typesafe arguments too someday

[Ian Lake]

That's the plan, yep! Feel free to star the feature request (and maybe leave a comment linking to this new library too): https://issuetracker.google.com/issues/188693139