Conductor: Is there a reason for the save/restore and bind/unbind distinction?

[JakeWharton]

I would like to convince you to combine them!

Both pairs are really responsible for the same thing: moving the controller from a place with no view to a place with a fully usable view. In the happy case where views are saving all the state themselves, nothing changes about your implementation. And if you do need custom storage around view state it now happens at the same time and in the same place where you're already setting them up or tearing them down.

Bonus: _greatly_ simplified lifecycle (especially combined with #8) which is focused around the larger _what_ not the _how_ things happen. This makes you opinionated about the lifecycle instead of the implementation of the lifecycle.

A simplified lifecycle also reduces the question of when methods are called by putting them into higher-level categories. The application-layer is allowed to decide what distinction they want to break apart based on their library and conventions. Unlike the mistakes Android made in Activity and Fragment, you don't need to cater to subclasses trying to incorrectly mix-in functionality through inheritance instead of composition via delegation. When the lifecycle is simplified you even make delegation easier since there's less for libraries wanting to hook into the lifecycle to require hooks for.

What's also nice about the new lifecycle (assuming #8 as well) is that it's only ever one step to move from state to state, not multiple. This eliminates the question of conditional callback uncertainty and ordering uncertainty:

• Birth? One callback (maybe): onRestoreInstanceState.
• Setting up a view? One callback: initializeView (or whatever).
• Displaying view? One callback: onAttach.
• View no longer displaying? One callback: onDetach.
• View being recycled? One callback: destroyView.
• Deathbed? One callback: onSaveInstanceState.

[sockeqwe]

Agreed. This would simplify the lifecycle. The first time I have seen the lifecycle diagram I thought that this is pretty similar (regarding complexity) as the lifecycle diagram of Fragments (too complex) ...

[EricKuck]

Good stuff! Totally agree on all points. The one case where merging the save and unbind methods could be an issue is the one where the host Activity's onSaveInstanceState method is called, which would trigger each Controller to save its own state. If the Controller's view was still on the screen at the time this happened, the detach/saveState method wouldn't have been called yet, and therefore the view's state would go unsaved.

I'll look over everything again today to see if there's a way around that. If there's a solution for this issue I'll be making this change today. If anyone has a suggestion on it, that'd be great too!

[EricKuck]

One other thing we'd lose by merging all these methods is having restoreHierarchyState called on the view after it's been inflated, but before the developer has done any custom restoring/binding. I wouldn't want to call this method after the developer's done all this, as you don't want to accidentally overwrite any changes they made.

I suppose this could be mostly overcome using a custom LayoutInflater. Another option would be to just drop the restoreHierarchyState, as I don't believe it's really used much in the framework (although I could be wrong on that).

[EricKuck]

Updated lifecycle diagram with changes from #8 and comments up for discussion from this issue. I've love to find a way to merge saving and restoring the view's states, but I'm not sure it's possible. Saving a view's state could happen while it's still attached, so I'm pretty sure we couldn't remove that callback. Restoring the view's state could be merged with createView(), but then the developer would be responsible for calling restoreHierarchyState themselves, which seems kind of annoying.

[sockeqwe]

The asymetric order of attach/detach and save/restore is a little bit confusing ( already discussed in #6 ).
The naming of createView() and unbindView() could be adjusted to fit each other slightly better. Also maybe renaming onAttach()/onDetach() to something like onViewAttached() would make it a little bit more clear when this callback will be invoked. Just my two cents (and personal preference) ...

I would appreciate if lifecycle could be even more simplified, but I'm not sure how ... good job :+1:

[EricKuck]

@sockeqwe Whoops yeah that was a typo in the diagram I attached. onUnbindView() should have been renamed to destroyView(). I just edited the post above with that change.

As for the asymmetrical calls, I just commented on #6 again with a bit more info. If you have thoughts on what I said I'm very open to making whatever changes will improve the lifecycle.

[PaulWoitaschek]

It would be great to have more explanation what this library does exactly. Now as I see the above diagram it gets more clearer which event happens when.

The readme shows this image as the lifecycle

Which does not state anything about onSaveViewState and onSaveInstanceState.

A wiki describing through an example what should be done in which callback would be helpful for people being new to this library.