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.