A modern programming language that makes developers happier.

kotlinlang

Anyone know how to react to returning from a navigation subgraph?  I basically want to treat the subgraph as a black box and re-use it in several different other graphs.  The problem is how do i detect when i’ve come back from it.  I could use a destination listener, and add it prior to navigation, and remove it when it comes back to the destination i want, but that doesn’t work right if the app goes out of memory and is rebuilt.

looking at the same topic right now. The answer is either shared ViewModel or observing savedStateHandle:
<https://developer.android.com/guide/navigation/navigation-programmatic#returning_a_result>

Yeah, i’ve been using the shared view model, but it seems hokey.

I also am struggling with out to navigate back.  I can obviously pop the subflow off the stack and then when the parent fragment resumes, it can then move forward to the next screen if necessary.

However, that has visual ramifications on the transition.  Instead i’ve been passing the exit action (through shared view model), and doing two navigate events.

One to pop the subflow, and one to navigate to the next destination.  It works, and visually looks better than the other approach, but it just seems ugly from a code standpoint to do two navigations.

I had looked into using the fragmentmanager’s new support for listening to that stuff, but i’m not going to use an alpha version for something real.

It also seems very hokey to use the savedStateHandle for return values since you’ll end up saving that if you background the app.

&gt; However, that has visual ramifications on the transition.
Tell me more? It probably should be a bug

<@U014B4GMN8M> the visual ramifications would be related to the delivery of the changes to savedStateHandle.  The navigation to pop the subflow off the stack would work jsut fine.  However, the observer for the savedStateHandle would be attached to the lifecycle of the fragment that called the subflow.  That fragment would have to be resumed first, which means the user would briefly see it before being able to navigate forward to the next screen

Instead, i’m using a shared view model where i put the next action.  I then pop the flow and execute the next action all at once, which is a smoother transition.