ViewPresenter onSave is awkward with Flow

[Kritarie]

I've been struggling to come up with a clean solution to this problem. The BundleService does a great job of allowing my ViewPresenters to save and restore their state on orientation change. Unfortunately, when I navigate from screen to screen with Flow, the View's onSaveInstanceState is called, and not my Presenter's onSave.

I've tried a number of things including:

• Delegating the View's onSaveInstanceState to the Presenter's onSave. This is about as janky as you'd expect, since onLoad is called for Presenter#takeView which happens before onRestore, and on config changes onSave will be called twice with two different bundles.
• Force calling BundleServiceRunner#onCreate / onSaveInstanceState from my Flow Dispatcher. This is also really weird and definitely not the intended functionality.

The two solutions that would actually work, but that I'm not super excited about, are:

• Save state in both the Presenter and the View separately; in the View for Flow nav, and in the Presenter for orientation change. This is weird because now my previously thin View needs to know about a lot of state that I prefer it didn't.
• Toss the BundleService and ViewPresenter altogether and roll up my own Presenter whose onSave / onLoad act only as delegates for the View's onSave / onRestore.

Possible solution that, admittedly, may be out of scope for the BundleService is to allow saving state not necessarily tied to the Activity's lifecycle. So in my dispatcher I could call through to traversal.getState(key).save(outgoingView) as normal, and then call BundleServiceRunner.save(key? bundle? state?) and similarly for restoring the incomingView. Then, when my Presenter's onLoad is called, the Bundle for that key is passed down.

[Zhuinden]

I ran into this problem and the solution was to get rid of Mortar's ViewPresenters and just use Flow's state persistence directly instead.