(I have read other answers on this subject, but they refer to older tech and practices.)
I have also read: https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/TheAdaptiveModel.html
I have an iOS app featuring 3 pages (1 per tab). The storyboard architecture is as follows:
TabBarController
-> Navigation Controller 1 -> View Controller 1
-> Navigation Controller 2 -> View Controller 2
-> Navigation Controller 3 -> View Controller 3
The app features major UI design differences when used on a small device (e.g. iPhone portrait) vs a large one (e.g. iPad fullscreen.) The basic architecture remains the same, but each View Controller needs to display a very different set of UI elements.
I could respond to size changes in Interface Builder, by Installing and Uninstalling elements and Auto Layout Constraints according to size class, but this would be extremely unwieldy and fragile.
In ye olden days (~2014), Apple's advice was:
If you want to present the same data differently based on whether a device is in a portrait or landscape orientation, the way to do so is using two separate view controllers. One view controller should manage the display of the data in the primary orientation (typically portrait), while the other manages the display of the data in the alternate orientation.
Despite the advent of Size Classes, this strikes me as still the best solution for my particular design (remembering to take size classes and split-view, slide-in to account.)
Question 1: at what point in my app should I detect the trait changes?
Question 2: (presuming that I have loaded an alternate view controller from a storyboard) in response to the trait change, how should I best transition/present the alternate view controller?
来源:https://stackoverflow.com/questions/36906606/adaptive-swapping-of-view-controllers-in-response-to-size-class-trait-changes-io