For new compose apps that don t rely on fragments I think it

Question

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 · Answer

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 · Answer

This questions is sort of a follow up of a discussion in this <https issuetracker google com u 1 issues 173717801|issue> I wanted to see other opinions to see if it makes sense creating a feature request or not

curioustechizen · Answer

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 · Answer

gt 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 · Answer

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 · Answer

Yes I can look for alternative navigation tools But if the usecase is wide enough it might make sense to support it slightly smiling face 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 · Answer

Yes part of Compose itself

Jordi Saumell · Answer

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 · Answer

I don t know what you mean Can you rephrase

Ian Lake · Answer

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 · Answer

You d use `parentBackStackEntry lifecycle`

Jordi Saumell · Answer

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 · Answer

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 · Answer

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 · Answer

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

Jordi Saumell · Answer

Thanks I ll try that tomorrow slightly smiling face

Ian Lake · Answer

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 · Answer

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 · Answer

< Ian Lake> sorry to bother again with this after so long I finally created 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 · Answer

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 · Answer

Thanks