search

turbolinks / turbolinks-ios

Native iOS adapter for building hybrid apps with Turbolinks 5
MIT License
880 stars 92 forks source link

Help with State Restoration #136

Closed jeffmcfadden closed 6 years ago

jeffmcfadden commented 6 years ago

I'm having trouble with state restoration, and I can't figure out the proper way to deal with this with Turbolinks VCs. If all the container VCs have restoration identifiers is the intention that VisitableViewControllers will 'just work' in restoring their state? What about Navigation Controllers containing VisitableViewControllers? The Demo app doesn't obviously encode the navigation history, which would seem to be necessary to restore state and maintain the ability to go 'back' in the hierarchy. I've tried to dig into the code but I'm struggling to understand the relationship between the iOS and Web sides of visits and restoration identifiers. I realize this is vague. I'd love a nudge in the right direction, if possible.

jeffmcfadden commented 6 years ago

So, to followup on this, and in case someone else finds this, here's what went wrong for me:

I had my (subclass of) VisitableViewController inside of a UINavigationController which was inside of a UITabBarController. On first launch (and only first launch), the viewWillAppear and viewDidAppear methods were not being called on my VisitableViewController. This meant that the Turbolinks load cycle callbacks for the end of the cycle weren't being called, which left things in an improper state. Then, you'd tap on a link in the webView and it would just spin, forever.

My solution has been to implement viewDidAppear in each VC in the hierarchy, and be sure to call super.viewDidAppear in each of those.

Maybe I should have known this already, but, in any case, after many hours of debugging, everything is working as expected. 🍻