What is the "right" way to handle orientation changes in iOS 8?

rmp251 picture rmp251 · Sep 27, 2014 · Viewed 70k times · Source

Can someone please tell me the "right" or "best" approach to working with portrait and landscape interface orientations in iOS 8? It seems that all the functions I want to use for that purpose are deprecated in iOS 8, and my research has turned up no clear, elegant alternative. Am I really supposed to look at the width and height to determine for myself if we are in portrait or landscape mode?

For example, in my view controller, how should I implement the following pseudocode?

if we are rotating from portrait to landscape then
  do portrait things
else if we are rotating from landscape to portrait then
  do landscape things

Answer

smileyborg picture smileyborg · Dec 10, 2014

Apple recommends using size classes as a coarse measure of how much screen space is available, so that your UI can significantly change its layout and appearance. Consider that an iPad in portrait has the same size classes as it does in landscape (Regular width, Regular height). This means that your UI should be more or less similar between the two orientations.

However, the change from portrait to landscape in an iPad is significant enough that you may need to make some smaller adjustments to the UI, even though the size classes have not changed. Since the interface orientation related methods on UIViewController have been deprecated, Apple now recommends implementing the following new method in UIViewController as a replacement:

- (void)viewWillTransitionToSize:(CGSize)size withTransitionCoordinator:(id <UIViewControllerTransitionCoordinator>)coordinator
{
    [super viewWillTransitionToSize:size withTransitionCoordinator:coordinator];

    // Code here will execute before the rotation begins.
    // Equivalent to placing it in the deprecated method -[willRotateToInterfaceOrientation:duration:]

    [coordinator animateAlongsideTransition:^(id<UIViewControllerTransitionCoordinatorContext> context) {

        // Place code here to perform animations during the rotation.
        // You can pass nil or leave this block empty if not necessary.

    } completion:^(id<UIViewControllerTransitionCoordinatorContext> context) {

        // Code here will execute after the rotation has finished.
        // Equivalent to placing it in the deprecated method -[didRotateFromInterfaceOrientation:]

    }];
}

Great! Now you're getting callbacks right before the rotation starts, and after it finishes. But what about actually knowing whether the rotation is to portrait or to landscape?

Apple recommends thinking about rotation as simply a change in size of the parent view. In other words, during an iPad rotation from portrait to landscape, you can think of it as the root-level view simply changing its bounds.size from {768, 1024} to {1024, 768}. Knowing this then, you should use the size passed into the viewWillTransitionToSize:withTransitionCoordinator: method above to figure out whether you are rotating to portrait or landscape.

If you want an even more seamless way to migrate legacy code to the new iOS 8 way of doing things, consider using this simple category on UIView, which can be used to determine whether a view is "portrait" or "landscape" based on its size.

To recap:

  1. You should use size classes to determine when to show fundamentally different UIs (e.g. an "iPhone-like" UI vs. an "iPad-like" UI)
  2. If you need to make smaller adjustments to your UI when size classes don't change but your container (parent view) size does, such as when an iPad rotates, use the viewWillTransitionToSize:withTransitionCoordinator: callback in UIViewController.
  3. Every view in your app should only make layout decisions based on the space that it has been given to layout in. Let the natural hierarchy of views cascade this information down.
  4. Similarly, don't use the statusBarOrientation -- which is basically a device-level property -- to determine whether to layout a view for "portrait" vs "landscape". The status bar orientation should only be used by code dealing with things like UIWindow which actually live at the very root level of the app.