Game Development Reference
In-Depth Information
In Listing 2-6, we see code generated by Interface Builder for each IBOutlet created. In the task
viewDidUnload , we see that each view is released and set to nil. Similarly, in the task dealloc , we see
that each view is released. In the next section, we are going to review how we respond to orientation
change; this same code will be responsible for getting the different views we have been working with
onto the screen.
Responding to Changes in Orientation
The last thing we have to do is add some logic that changes which UIView is displayed based on
the orientation of the device. The class UIViewController specifies a task that is called after the
device rotates. This task is called didRotateFromInterfaceOrientation: and it is passed a constant
UIDevice .
GameController.m (shouldAutorotateToInterfaceOrientation:)
UIDevice* device = [UIDevice currentDevice];
[self setOrientation: [device orientation]];
if (interfaceOrientation == UIInterfaceOrientationLandscapeLeft || interfaceOrientation ==
[portraitView removeFromSuperview];
[self.view addSubview:landscapeView];
[rockPaperScissorsController setup:landscapeHolderView.frame.size];
[landscapeHolderView addSubview:rockPaperScissorsController.view];
} else {
[landscapeView removeFromSuperview];
[self.view addSubview:portraitView];
[rockPaperScissorsController setup:portraitHolderView.frame.size];
[portraitHolderView addSubview:rockPaperScissorsController.view];
}
}
In Listing 2-7, we see that this task has passed the variable fromInterfaceOrientation , indicating
the old orientation of the device. We don't really care about the old orientation in our application, so
we find the current (post-rotation) orientation by getting the current device from the class UIDevice
and then reading the property orientation . Once we get the orientation, we call setOrientation: ,
which is also defined in Listing 2-7.
The task setOrientation: will update UI to use which ever orientation is passed in. If the device is
now in landscape orientation, we remove the portraitView from its super-view, meaning that we
take it off the screen. We then add the view landscapeView to the root-most view. We call setup on
rockpaperScissorsController to give it a chance to lay out its subviews, if it has not already done so.
Lastly, we add rockPaperScissorsController's view property to landscapeHolder as a subview.
 
Search WWH ::




Custom Search