Closed jeffmcfadden closed 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. 🍻
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
VisitableViewController
s will 'just work' in restoring their state? What about Navigation Controllers containingVisitableViewController
s? 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.