Es scheint Apples Absicht zu sein, beide iPad Orientierungen zu behandeln, als Das Gleiche - aber wie wir feststellen müssen, gibt es sehr legitime Design-Gründe, das UI-Layout für iPad Portrait vs. iPad Landscape zu variieren.
Leider scheint das aktuelle Betriebssystem keine Unterstützung für diese Unterscheidung zu bieten ... was bedeutet, dass wir wieder Auto-Layout-Einschränkungen in Code oder ähnlichen Problemumgehungen manipulieren, um das zu erreichen, was wir im Idealfall erreichen können kostenlos mit Adaptive UI.
Keine elegante Lösung.
Gibt es keine Möglichkeit, die Magie, die Apple bereits in IB und UIKit eingebaut hat, zu nutzen, um eine Größenklasse unserer Wahl für eine bestimmte Orientierung zu verwenden?
~
Beim Nachdenken über das Problem allgemeinen, wurde mir klar, dass ‚Größenklassen‘ sind einfach Möglichkeiten, mehrere Layouts zu adressieren, die in IB gespeichert werden, so dass sie zur Laufzeit benötigt aufgerufen werden können.
In der Tat ist eine "Größenklasse" wirklich nur ein Paar Enum-Werte. Von UIInterface.h:
typedef NS_ENUM(NSInteger, UIUserInterfaceSizeClass) {
UIUserInterfaceSizeClassUnspecified = 0,
UIUserInterfaceSizeClassCompact = 1,
UIUserInterfaceSizeClassRegular = 2,
} NS_ENUM_AVAILABLE_IOS(8_0);
Also unabhängig davon, was Apple Namen diese verschiedenen Varianten entschieden hat, im Grunde, sie sind nur ein Paar von ganzen Zahlen als eindeutige Kennung der Art verwendet, zu unterscheiden, ein Layout aus ein anderes, in IB gespeichert.
Jetzt, unter der Annahme, dass wir ein alternatives Layout (unter Verwendung einer nicht genutzten Größenklasse) in IB erstellen - sagt sie, für iPad Portrait ... ist es eine Möglichkeit, das Gerät verwendet unsere Wahl der Größenklasse haben (UI Layout) nach Bedarf zur Laufzeit?
Nachdem ich mehrere verschiedene (weniger elegante) Ansätze für das Problem versucht habe, vermutete ich, dass es eine Möglichkeit gibt, die Standardgrößenklasse programmgesteuert zu überschreiben. Und es gibt (in UIViewController.h):
// Call to modify the trait collection for child view controllers.
- (void)setOverrideTraitCollection:(UITraitCollection *)collection forChildViewController:(UIViewController *)childViewController NS_AVAILABLE_IOS(8_0);
- (UITraitCollection *)overrideTraitCollectionForChildViewController:(UIViewController *)childViewController NS_AVAILABLE_IOS(8_0);
Wenn Sie also Ihre View-Controller-Hierarchie als 'Kind' View-Controller verpacken können, und fügen Sie es zu einem Top-Level-Eltern-View-Controller ... dann Sie können das untergeordnete Element überschreiben, indem Sie davon ausgehen, dass es sich um eine andere Größenklasse als die Standardeinstellung des Betriebssystems handelt.
Hier ist eine Beispielimplementierung, das dies tut, in der ‚Eltern‘ View-Controller:
@interface RDTraitCollectionOverrideViewController : UIViewController {
BOOL _willTransitionToPortrait;
UITraitCollection *_traitCollection_CompactRegular;
UITraitCollection *_traitCollection_AnyAny;
}
@end
@implementation RDTraitCollectionOverrideViewController
- (void)viewDidLoad {
[super viewDidLoad];
[self setUpReferenceSizeClasses];
}
- (void)setUpReferenceSizeClasses {
UITraitCollection *traitCollection_hCompact = [UITraitCollection traitCollectionWithHorizontalSizeClass:UIUserInterfaceSizeClassCompact];
UITraitCollection *traitCollection_vRegular = [UITraitCollection traitCollectionWithVerticalSizeClass:UIUserInterfaceSizeClassRegular];
_traitCollection_CompactRegular = [UITraitCollection traitCollectionWithTraitsFromCollections:@[traitCollection_hCompact, traitCollection_vRegular]];
UITraitCollection *traitCollection_hAny = [UITraitCollection traitCollectionWithHorizontalSizeClass:UIUserInterfaceSizeClassUnspecified];
UITraitCollection *traitCollection_vAny = [UITraitCollection traitCollectionWithVerticalSizeClass:UIUserInterfaceSizeClassUnspecified];
_traitCollection_AnyAny = [UITraitCollection traitCollectionWithTraitsFromCollections:@[traitCollection_hAny, traitCollection_vAny]];
}
-(void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
_willTransitionToPortrait = self.view.frame.size.height > self.view.frame.size.width;
}
- (void)viewWillTransitionToSize:(CGSize)size withTransitionCoordinator:(id<UIViewControllerTransitionCoordinator>)coordinator {
_willTransitionToPortrait = size.height > size.width;
}
-(UITraitCollection *)overrideTraitCollectionForChildViewController:(UIViewController *)childViewController {
UITraitCollection *traitCollectionForOverride = _willTransitionToPortrait ? _traitCollection_CompactRegular : _traitCollection_AnyAny;
return traitCollectionForOverride;
}
@end
Als schnelle Demo, um zu sehen, ob es funktioniert, habe ich benutzerdefinierte Etiketten speziell auf die ‚Regular/Regular‘ und 'Compact/Regular' -Versionen des Kindes Controller-Layout in IB:
Und hier ist, wie es aussieht, wird nach Drücken der iPad in beiden Orientierungen ist: 
Voila! Benutzerdefinierte Größenklassenkonfigurationen zur Laufzeit
Hoffentlich wird Apple dies in der nächsten Version des Betriebssystems unnötig machen. In der Zwischenzeit könnte dies ein eleganterer und skalierbarerer Ansatz sein, als programmgesteuert mit Auto-Layout-Einschränkungen zu arbeiten oder andere Manipulationen im Code durchzuführen.
~
EDIT (6/4/15): Bitte beachten Sie, dass der obige Beispielcode ist im Wesentlichen ein Proof of Concept, die Technik zu demonstrieren. Fühlen Sie sich frei, sich für Ihre eigene spezifische Anwendung anzupassen.
~
EDIT (7/24/15): Es ist erfreulich, dass die obige Erklärung scheint das Problem zu helfen entmystifizieren. Während ich es nicht getestet habe, sieht der Code von mohamede1945 [unten] wie eine hilfreiche Optimierung für praktische Zwecke aus. Fühlen Sie sich frei, es auszuprobieren und lassen Sie uns wissen, was Sie denken. (Im Interesse der Vollständigkeit belasse ich den obigen Beispielcode unverändert.)
Es scheint keine nicht-programmatische Lösung zu sein, die für den Standard benötigt würden Bildschirm – SwiftArchitect