In this post I’ll give a few general tips for handling device rotations at the UIViewController level. \u00c2\u00a0These tips are for code using iOS (formerly known as iPhone OS) 3.0 or later, which includes all iPad code.<\/p>\n
This sounds obvious and easy, but there are a lot<\/em> of innocent-seeming ways to screw this up.<\/p>\n In this method, you can think of the rotation as being done, and that you’re now moving things to fit the new screen size. \u00c2\u00a0You do not<\/em> have to do any rotations yourself. \u00c2\u00a0You do not <\/em>have to make any calls to UIView’s animation methods. \u00c2\u00a0UIKit handles both of those for you.<\/p>\n One way to think about your responsibility in this method is as follows: Imagine someone started with a tall skinny monitor as their only display, and then unplugged it and plugged back in a short wide monitor. \u00c2\u00a0The<\/p>\n method has the job of making things fit nicely on the new monitor.<\/p>\n But there are still some easy mistakes to make, as we’ll see.<\/p>\n It can be tempting to use something like<\/p>\n to determine if you’re in portrait or landscape mode, but this is a terrible idea for a few reasons:<\/p>\n , the actual bounds of your view has not yet changed to the new orientation.<\/li>\n is always<\/em> in portrait orientation. \u00c2\u00a0Wha? \u00c2\u00a0Yes, always in portrait – what changes is the transform of your view. \u00c2\u00a0So your<\/p>\n is always accurate (keeping in mind the last point), but<\/p>\n may or may not give the aspect ratio that the user is really seeing, since each view’s frame is reported in terms of the superview’s coordinates, and takes into account any transforms applied to the view.<\/li>\n , and to use the helpful macros designed to work with the type<\/p>\n (see here<\/a> for more details on that). \u00c2\u00a0To keep your code consistent, it makes sense to use<\/p>\n variables in all situations where orientation is important.<\/li>\n<\/ol>\n In particular, there’s no need to adjust any view’s transform directly, since it’s done for you. \u00c2\u00a0And you don’t have to think in terms of rotated coordinates either – the point (0,0) is always the upper-left corner of the user’s screen, and this point is moved for you automatically during rotation.<\/p>\n If you’re using iOS 3.0 or later (as this post assumes), then you also don’t want to implement the older functions\u00c2\u00a0<\/p>\n methods. \u00c2\u00a0This old system is considered less efficient and deprecated. \u00c2\u00a0If you try to implement both the new technique (the single method above) and the old technique (the two-step methods here), then only the new technique will actually be executed at runtime.<\/p>\n If you don’t override the\u00c2\u00a0<\/p>\n method of<\/p>\n , then the default implementation of this method will always return<\/p>\n , and you’ll be stuck in portrait mode forever. \u00c2\u00a0It’s a one-line method to rotate to any orientation – ”<\/p>\n ” – and that’s more-or-less required behavior for non-immersive apps on the iPad.<\/p>\n2. \u00c2\u00a0Use interfaceOrientation, and nothing else, to determine your orientation.<\/h2>\n
\n
3. \u00c2\u00a0Don’t do extra work that you think may be needed for rotation.<\/h2>\n
4. Don’t forget to report that you handle all orientations.<\/h2>\n
References<\/h2>\n