Question

Specifically, I have something like a game, with a menu screen made out of standard components. I want a button to switch to another view controller that the user will interact with for a while, then return to the menu screen. It seems like having the menu controller present the ‘game’ mode as a modal view controller is the most straightforward solution, but is this the best way to essentially replace the entire view? Is the whole menu (which may later become a deep nav or split controller) kept in memory as long as the modal controller is in front, and is this something I should bother to worry about?

Answer 1

There are really two parts to this question:

Which method of transitioning from one view to the next in an iPad application provides the best experience to the user?

Which method of transitioning from one view to the next is easiest to implement and best handles memory management?

I’m not going to try to address the first part of this question other than to point you to Apple’s ‘iPad Human Interface Guidelines’ which says (among other things):

Reduce Full-Screen Transitions

Closely associate visual transitions with the content that’s changing. Instead of swapping in a whole new screen when some embedded information changes, try to update only the areas of the user interface that need it. As a general rule, prefer transitioning individual views and objects, not the screen. In most cases, flipping the entire screen is not recommended.

When you perform fewer full-screen transitions, your application has greater visual stability, which helps people keep track of where they are in their task. You can use UI elements such as split view and popover to lessen the need for full-screen transitions.

http://developer.apple.com/library/ios/prerelease/#documentation/General/Conceptual/iPadHIG/DesignGuidelines/DesignGuidelines.html

However, in your case I’d have thought a full-screen transition is entirely appropriate (but then I’m not a user experience expert).

In answer to the second part, yes displaying a new view controller modally seems like a good approach to take.

By default both the objects used by the menu view and those used by the modal view will be kept in memory – but the great thing about using UIViewController sub-classes is that they’ve got some default memory management built-in. If your application receives a memory warning whilst the modal view is being presented in full-screen mode, the menu view controller’s views will be removed and it’s ‘viewDidUnload’ method will be called. So in your implementation of this method you should release any objects you don’t need and then recreate them as needed in the menu view controller’s viewDidLoad method (which will be called again before the menu view is shown).

This is explained in more detail in the UIViewController class reference:

When a low-memory warning occurs, the UIViewController class purges its views if it knows it can reload or recreate them again later. If this happens, it also calls the viewDidUnload method to give your code a chance to relinquish ownership of any objects that are associated with your view hierarchy, including objects loaded with the nib file, objects created in your viewDidLoad method, and objects created lazily at runtime and added to the view hierarchy. Typically, if your view controller contains outlets (properties or raw variables that contain the IBOutlet keyword), you should use the viewDidUnload method to relinquish ownership of those outlets or any other view-related data that you no longer need.

http://developer.apple.com/library/ios/#documentation/uikit/reference/UIViewController_Class/Reference/Reference.html