Should Flow trigger a State save on lifecycle events?

[loganj]

Currently it does not-- state can only be saved and restored during a traversal. It does seem like we'd want this, so that we save/restore state uniformly for the current key when appropriate lifecycle events occur.

[Zhuinden]

I opened the referenced issue, and I personally would vote for it, primarily because currently if you put the app to the background and bring it to foreground, then a REPLACE direction key traversal is called with [null; IncomingKey] parameters, and the bundle state would be lost here on reinitialization unless it was saved out in onSaveInstanceState (which is called between onPause and onStop fairly reliably). However, if Flow managed to get ahold of this bundle in the State, the key traversal could handle the Bundle like for any other traversal to any previous state that has a Bundle.

Essentially, when the REPLACE occurs bringing the app to foreground, it's almost necessary for Flow to keep the bundle for the current key within the State object so that the key traversal itself can handle it, and not externally managed.

[grandstaish]

I came here to log this exact issue. Really pleased to see you have it tracked for the beta.

To elaborate more, the issue I'm facing is that when I background the app, then restore the app to the foreground, my KeyChanger gets sent a key with direction REPLACE to replace the current view. So the previous state of my view is lost since it has now been replaced and the system couldn't restore the state by itself. In my particular case, I have a RecyclerView that goes resets back to the top every time I bring a backgrounded application into the foreground.

[Zhuinden]

If REPLACE erases your viewstate, then your dispatcher logic does not preserve the state of removed objects properly. After all, you will need to handle the same scenario on configuration change (rotation).

[grandstaish]

Hmm. But when you background the app, the key dispatcher doesn't get called, so you can't call save() on the hierarchy. Then when the REPLACE call happens, the incomingState has a null viewState and therefore it can't be restored. Or am I missing something here? Note that my app functions fine on configuration changes because save/restore are called by the system.

[Zhuinden]

Ah, right, I remember now. This is why I did this:

https://github.com/Zhuinden/flowless/blob/master/flow/src/main/java/flow/ForceBundler.java

And called this on the root container in onSaveInstanceState().

[grandstaish]

That works, so thanks @Zhuinden, I'll use this workaround/hack until this issue is resolved