https://kotlinlang.org logo
#compose
Title
# compose
j

Jordi Saumell

12/01/2020, 8:10 PM
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?
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,
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
c

curioustechizen

12/01/2020, 8:20 PM
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.
i

Ian Lake

12/01/2020, 8:49 PM
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
☝️ 1
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
j

Jordi Saumell

12/01/2020, 10:38 PM
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?
i

Ian Lake

12/01/2020, 10:40 PM
Yes, part of Compose itself
👍 1
j

Jordi Saumell

12/01/2020, 10:41 PM
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)
i

Ian Lake

12/01/2020, 10:42 PM
I don't know what you mean. Can you rephrase?
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
(You'd use
parentBackStackEntry.lifecycle
)
j

Jordi Saumell

12/01/2020, 10:46 PM
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
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
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?
i

Ian Lake

12/01/2020, 10:55 PM
Everywhere you can scope a ViewModel, you can save state, you can get a Lifecycle, etc.
j

Jordi Saumell

12/01/2020, 10:56 PM
Thanks, I’ll try that tomorrow! 🙂
i

Ian Lake

12/02/2020, 1:16 AM
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
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
j

Jordi Saumell

01/14/2021, 8:06 PM
@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?
i

Ian Lake

01/14/2021, 8:11 PM
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!
j

Jordi Saumell

01/14/2021, 8:14 PM
Thanks!