search

square / mortar

A simple library that makes it easy to pair thin views with dedicated controllers, isolated from most of the vagaries of the Activity life cycle.
Apache License 2.0
2.16k stars 156 forks source link

ViewPresenter's onLoad and onSave do not have the same call count. #177

Closed urandom closed 8 years ago

urandom commented 8 years ago

I was a bit surprised that takeView calls onLoad yet dropView doesn't call onSave. I was under the assumption that, excepting the first time, onSave will always be called before any new invocation of onLoad, and I could always rely that the state bundle would contain the fresh presenter state.

That however turns out to not be the case. Consider the following case: the related view contains a recyclerview, and I need to save the layout manager's state when the view is detached. I thought it would be rather easy, call the onSaveInstanceState in the 'onSave' callback, and onRestoreInstanceState in 'onLoad'. However, since onSave isn't called most of the time, subsequent calls to 'onLoad' either get no state, or worse, get a stale one, since at some point in time I did get a call to 'onSave' and managed to save something.

I ended up overriding dropView, saving the state in a property, as well as also saving in the state during onSave, and then trying to reuse both during onLoad. That doesn't look like a very elegant solution, and it seems it won't even work in the future due to issue #103 . Another place where thing will get awkward is if I want to register and unregister a receiver. I would have to remember if I already called register once, unless I want the app to crash.

Am I missing something subtle?

rjrjr commented 8 years ago

You're observing something poorly named. The asymmetry is by mis-design. Issue #156 discusses what we should be doing instead.