In the architecture guide <https://developer.andro...
# android
m
In the architecture guide https://developer.android.com/jetpack/guide/ui-layer/events#handle-viewmodel-events it is suggested to model navigation as state updates instead of events. It makes sense, but how to best model it in a way which avoids navigating away multiple times? On screen A the state changes in a way that signifies screen B should be shown. In response, screen A navigates to screen B. All is fine. Then the user presses back. We are on screen A, but it will just immediately navigate to screen B since the state didn't change. How to handle that?
a
You can also model the state indicating that forward navigation should occur
m
I'm not sure what you mean. When I leave screen A, it's left in the "leaving for screen B" state. So when I go back from screen B, screen A is still in the "leaving for screen B" state and navigates away. I could clear the "leaving for screen B" state in screen A when navigating away, but that seems like boilerplate. I would like to see an example of what Google suggests to do.
a
without modeling that,
awaitingResultToGoToNext
state, what would you use to restore from a cold process start? If the user clicks next, a request to some service kicks off, the user navigates away, then launches a browser, the camera, takes a phone call, the process dies after savedInstanceState save but also after the request completed and the app recorded the result in some other persistent storage. (Or maybe not. Maybe the app is going to sync with the server on next start.)
There are a lot of ways to attack this problem space, but keeping that single state bit around that also saves as instance state tends to be pretty robust and works in a lot of combinations of other architectures if your navigation state is also savedInstanceState
if you take any of the roads that involve consuming and discarding an event, then you have to build extra accommodations for cold process start to get back to the right place