Do not forward appearance events to central VC when drawer is offscreen #271
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The idea is to avoid sending appearance events when setting new central controller before drawer put into view hierarchy (or offscreen). This PR fixes issue #261 related to state restoration. Related issue #268.
This patch also adds some minor optimization for side controller setter method to avoid reseting the same view controller. This does make sense with state restoration because at the moment all controllers will be set twice, first time when your code actually instantiates other controllers from storyboard and second time while state restoration decoding.
I tested this patch in my app with and without state restoration and everything works. I haven't tested hot-swap of central controller, but I believe it should work as before.
The good thing, it seems state restoration is smart enough and grabs the last instance of sidebar/central controller instantiated using
-[UIStoryboard instantiateViewControllerWithIdentifier:]
. If you create controllers manually, then you end up with two different sets of controllers I assume.If you ask me, I do not encode child VCs for my controllers, because I create them in code anyway. Instead, I save properties that will help me to restore the state of those controllers. From my observations, saving child controller is only makes sense when you use embed segue in storyboard, then you leverage Storyboard to save/restore such controller. But essentially it always creates this controller for you, so you never even decode it, you only encode it.