{"action":"created","issue":{"url":"https://api.github.com/repos/bluelinelabs/Conductor/issues/10","repository_url":"https://api.github.com/repos/bluelinelabs/Conductor","labels_url":"https://api.github.com/repos/bluelinelabs/Conductor/issues/10/labels{/name}","comments_url":"https://api.github.com/repos/bluelinelabs/Conductor/issues/10/comments","events_url":"https://api.github.com/repos/bluelinelabs/Conductor/issues/10/events","html_url":"https://github.com/bluelinelabs/Conductor/issues/10","id":145087775,"number":10,"title":"Is there a reason for the save/restore and bind/unbind distinction?","user":{"login":"JakeWharton","id":66577,"avatar_url":"https://avatars.githubusercontent.com/u/66577?v=3","gravatar_id":"","url":"https://api.github.com/users/JakeWharton","html_url":"https://github.com/JakeWharton","followers_url":"https://api.github.com/users/JakeWharton/followers","following_url":"https://api.github.com/users/JakeWharton/following{/other_user}","gists_url":"https://api.github.com/users/JakeWharton/gists{/gist_id}","starred_url":"https://api.github.com/users/JakeWharton/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JakeWharton/subscriptions","organizations_url":"https://api.github.com/users/JakeWharton/orgs","repos_url":"https://api.github.com/users/JakeWharton/repos","events_url":"https://api.github.com/users/JakeWharton/events{/privacy}","received_events_url":"https://api.github.com/users/JakeWharton/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2016-04-01T05:04:05Z","updated_at":"2016-04-01T12:03:26Z","closed_at":null,"body":"I would like to convince you to combine them!\r\n\r\nBoth 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.\r\n\r\nBonus: _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.\r\n\r\nA 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.\r\n\r\nWhat'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:\r\n* Birth? One callback (maybe): `onRestoreInstanceState`.\r\n* Setting up a view? One callback: `initializeView` (or whatever).\r\n* Displaying view? One callback: `onAttach`.\r\n* View no longer displaying? One callback: `onDetach`.\r\n* View being recycled? One callback: `destroyView`.\r\n* Deathbed? One callback: `onSaveInstanceState`."},"comment":{"url":"https://api.github.com/repos/bluelinelabs/Conductor/issues/comments/204368974","html_url":"https://github.com/bluelinelabs/Conductor/issues/10#issuecomment-204368974","issue_url":"https://api.github.com/repos/bluelinelabs/Conductor/issues/10","id":204368974,"user":{"login":"EricKuck","id":2039026,"avatar_url":"https://avatars.githubusercontent.com/u/2039026?v=3","gravatar_id":"","url":"https://api.github.com/users/EricKuck","html_url":"https://github.com/EricKuck","followers_url":"https://api.github.com/users/EricKuck/followers","following_url":"https://api.github.com/users/EricKuck/following{/other_user}","gists_url":"https://api.github.com/users/EricKuck/gists{/gist_id}","starred_url":"https://api.github.com/users/EricKuck/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/EricKuck/subscriptions","organizations_url":"https://api.github.com/users/EricKuck/orgs","repos_url":"https://api.github.com/users/EricKuck/repos","events_url":"https://api.github.com/users/EricKuck/events{/privacy}","received_events_url":"https://api.github.com/users/EricKuck/received_events","type":"User","site_admin":false},"created_at":"2016-04-01T12:03:26Z","updated_at":"2016-04-01T12:03:26Z","body":"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.\r\n\r\nI'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!"}}