Best practice for UITabBarController

[scruff311]

I read in another issue that Basecamp sets up each tab have it's own UINavigationController. This makes sense, but I am wondering where the ApplicationController logic from the sample app lives, since that is set up as a subclass of UINavigationController and handles all of the TurboLinks logic for new visits. It doesn't seem right to me to have each tab be an ApplicationController class.

My thought was to maybe create an ApplicationController singleton that is just an NSObject subclass and have each UINavigationController act as a delegate of it to handle the visit actions passed to it from the Turbolinks Session.

Has anyone come up with a nice working solution for this?

[zachwaugh]

The ApplicationController setup in the demo app is just for simplicity and not necessarily a best practice or a suggested way to structure your app. You definitely would want an object (doesn't have to be a singleton) that is handling this higher-level setup. In the Basecamp app, we have a TurbolinksController that manages the Turbolinks session for each navigation stack. I'm a fan of the coordinator pattern (http://khanlou.com/2015/10/coordinators-redux/), and we also rely on some coordinators in the app as well.

[scruff311]

Thanks, @zachwaugh. I set up our app in what sounds like a similar fashion (singleton TurbolinksController) that dispatches messages to the active navigation controller. The problem I had with this was that the webview is shared between all tabs, so every time you switched a tab the webview had to reload. This wasn't a great experience, so I split it up to a separate webview per tab but this brought with it memory issues (iOS would kill a web process after some time with 5 webviews running at once).

It seems in basecamp you can switch tabs without having to reload the webview. How do you manage that? I'll check out coordinators.

Thanks!

[zachwaugh]

@scruff311 we do use a separate turbolinks session/webview per tab and then an additional session for modals. We haven't noticed any issues with that setup, though our initial view controllers for each tab are native, and a webview isn't loaded until you navigate to something, so that might help in our case. If a web view process is killed though, there is a delegate method we implement to automatically reload it - https://developer.apple.com/documentation/webkit/wknavigationdelegate/1455639-webviewwebcontentprocessdidtermi