For new compose apps that don’t rely on fragments I think it makes sense to manually handle config c...

# compose

[Jordi Saumell]

For new compose apps that don’t rely on fragments I think it makes sense to manually handle config changes. Then, since android ViewModels are designed just to survive config changes, they are not necessary (in those apps).
The navigation component is deeply tied to viewModels and I think it should also offer the possibility of working with plain kotlin viewModels (view controllers). It would be more lightweight, not require factories, and make more sense in general, I think.

What do you think?

[Jordi Saumell]

I already managed to have my viewModels with the help of Koin, but it is hacky. And for nav-scoped my best approach currently is manually handling the koin scope, which works and is powerful, but it is also a lot of work,

[Jordi Saumell]

This questions is sort of a follow-up of a discussion in this issue. I wanted to see other opinions to see if it makes sense creating a feature request or not

[curioustechizen]

I'm experimenting with something similar but haven't gotten as far as you yet. I believe AAC ViewModels are redundant in a compose-only world.

[Ian Lake]

The navigation component is deeply tied to viewModels

They're a part of the toolkit provided to you, but no one is forcing you to use them

[Ian Lake]

If you want a 'permanently destroyed' signal for a composable, I think you should put in a feature request for exactly that. There's nothing Navigation specific about that - I'd imagine many composables would want to be able to tell the difference between temporary disposal (either due to config change or anything else) vs permanent

[Jordi Saumell]

Yes, I can look for alternative navigation tools. But if the usecase is wide enough it might make sense to support it 🙂
When you say “There’s nothing Navigation specific about that” do you mean this should not be part of navigation but of compose itself?

[Ian Lake]

Yes, part of Compose itself

[Jordi Saumell]

I would also like to have a lifecycle for subgraphs. When calling composable we get a navEntry with its lifecycle, but when calling navigation we do not. Would that be possible? (as in not too far from what’s planned so that it could be considered)

[Ian Lake]

I don't know what you mean. Can you rephrase?

[Ian Lake]

It isn't particularly easy right now, but you can certainly get the Lifecycle of the parent NavGraph's NavBackStackEntry using a technique such as that in https://stackoverflow.com/a/64961032/1676363

[Ian Lake]

(You'd use parentBackStackEntry.lifecycle)

[Jordi Saumell]

With the navigation component we can get a viewmodel associated to a nested graph that will be cleared when the the graph is removed from the backstack.
I would like to be able to obtain a callback for when the graph is detached from the backstack, so for when the viewmodel’s onCleared would be called, without having to create a viewModel for that. And ideally also for when the graph is attached

[Jordi Saumell]

as a comparison, when declaring a normal destination, with composable, we get the navEntry and the body is a @Composable. With that I can get the lifecycle of the NavEntry.
When declaring a nested graph, in the navigation function we do not get either, so I do not know how to get those callbacks

[Jordi Saumell]

so, from one of the destinations in the nested graph, calling parentBackStackEntry.lifecycle I would be able to retrieve the lifecycle of the nested graph?

[Ian Lake]

Everywhere you can scope a ViewModel, you can save state, you can get a Lifecycle, etc.

[Jordi Saumell]

Thanks, I’ll try that tomorrow! 🙂

[Ian Lake]

TBH, I think what you actually want is this callback: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt;l=162 - when the Compose specific RestorableStateProvider removes the state of the composable and throws it away for good

[Ian Lake]

Again, that Compose specific API surface is used by Navigation, but isn't part of Navigation - it is part of Compose. Hence why requesting something for Compose that works both within and outside of Compose is definitely the way to go

[Jordi Saumell]

@Ian Lake sorry to bother again with this after so long. I finally created the issue but it was created as a bug (I have not been able to find how to create it as feature request). And is the compose-runtime the correct component?

[Ian Lake]

Yeah, only Googlers can change it to a feature request (I did that for you). I think that component will work fine. Thanks for filing the issue!

[Jordi Saumell]

Thanks!