| Inherits from | |
| Conforms to | |
| Framework | /System/Library/Frameworks/UIKit.framework |
| Availability | Available in iPhone OS 2.0 and later. |
| Companion guide | |
| Declared in | UINavigationController.h UITabBarController.h UIViewController.h |
| Related sample code |
The UIViewController class provides the fundamental view-management model for iPhone applications. The basic view controller class supports the presentation of an associated view in addition to basic support for managing modal views and rotating views in response to device orientation changes. Subclasses such as UINavigationController and UITabBarController provide additional behavior for managing complex hierarchies of view controllers and views.
You use each instance of UIViewController to manage a full-screen view. For a simple view controller, this entails managing the view hierarchy responsible for presenting your application content. A typical view hierarchy consists of a root view—a reference to which is available in the view property of this class—and one or more subviews presenting the actual content. In the case of navigation and tab bar controllers, the view controller manages not only the high-level view hierarchy (which provides the navigation controls) but also one or more additional view controllers that handle the presentation of the application content.
Because view controllers are tightly bound to the views they manage, they are also part of the responder chain used to handle events. View controllers are themselves descendants of the UIResponder class and are inserted into the responder chain between the managed view and its superview. Thus, if the view managed by a view controller does not handle an event, it passes the event to its view controller, which then has the option of handling the event or forwarding it to the view’s superview.
The UIViewController class provides automatic support for rotating the views of the view controller in response to changes to the orientation of the device. As part of the autorotation behavior, the view controller slides any tab bars or navigation bars out of view, reorients the underlying views, and slides the bars back into position. If the autoresizing properties of your view are already configured, this behavior is essentially free. However, you can also customize the rotation behavior by specifying additional animations you want to be performed.
View controllers are fundamental to the design of most iPhone applications. The sections that follow provide basic information about using the methods and properties of the UIViewController class. For additional information about using view controllers to build and manage your application’s user interface, see View Controller Programming Guide for iPhone OS.
View controllers rarely operate in isolation. If your application uses a navigation or tab bar controller, or if your application presents views modally, then it typically has several view controllers interacting with each other to implement those navigation features.
A navigation controller interface consists of a UINavigationController object and one or more custom view controllers to present the different navigation screens. As the user selects new items in the interface, your code pushes new view controllers onto the navigation stack. Each new view controller then displays a new screen’s worth of content. To manage the removal of view controllers from the stack, each view controller has an associated navigation item, which allows navigation back to that item. You can configure the navigation item for a given view controller by modifying its navigationItem property.
A tab bar controller interface consists of a UITabBarController object and one or more view controllers for each tab. The root view controller for each tab can configure the information displayed on its tab by modifying the object in its tabBarItem property.
In iPhone OS, you can display views modally by presenting the controller for the modal view from your current view controller. When you present a view modally using the presentModalViewController:animated: method, the view controller animates the appearance of the view using the technique you specify. (You can specify the desired technique by setting the modalTransitionStyle property.) At the same time, the method creates a parent-child relationship between the current view controller and the modal view controller.
Because the relationships between view controllers can grow quite complex, each view controller object has properties that indicate whether it is managed by other view controllers. You can check the tabBarController or navigationController properties of a view controller to see if it is embedded inside of a tab bar or navigation bar interface. You can also find the controller’s immediate parent controller using the parentViewController property.
For more information about the relationships between view controllers and how you build complex navigation interfaces, see View Controller Programming Guide for iPhone OS.
In a typical iPhone application, there is usually at least one custom subclass of UIViewController and more often there are several. Because the amount of available screen space on iPhone OS–based devices is limited, interfaces must typically be divided into one or more screen’s worth of information. The views used to present each distinct screen are then managed by one of your UIViewController subclasses.
The job of each view controller object is two-fold. Because it is part of your application’s controller layer, a view controller is responsible for coordinating interactions between your application’s visual presentation (your custom views) and your application’s data model (your custom objects). A view controller is also responsible for handling changes to the views that comprise its view layer. For example, when the user rotates a device from a portrait to a landscape orientation, the view controller is responsible for reorienting the views accordingly. Fortunately, the default behavior of the UIViewController class handles much of the work needed to manage your view layer. All you have to do is specify the initial set of views and their default behaviors. After that, you can focus on the interactions between those views and your data model.
When you define a new subclass of UIViewController, you must specify the views to be managed by the controller. There are two mutually exclusive ways to specify these views: manually or using a nib file. If you specify the views manually, you must implement the loadView method and use it to assign a root view object to the view property. If you specify views using a nib file, you must not override loadView but should instead create a nib file in Interface Builder and then initialize your view controller object using the initWithNibName:bundle: method. Creating views using a nib file is often simpler because you can use the Interface Builder application to create and configure your views graphically (as opposed to programmatically). Both techniques have the same end result, however, which is to create the appropriate set of views and expose them through the view property.
Important: A view controller is the sole owner of its view and any associated subviews. It is responsible for creating those views and for releasing them at the appropriate times, including during low-memory conditions and when the view controller itself is released. If you store your views in a nib file, each view controller object creates its own copy of the view in that nib file. However, if you create your views manually, you should never use the same view objects with multiple view controllers.
When creating the views for your view hierarchy, you should always set the autoresizing properties of your views. When a view controller is displayed on screen, its root view is typically resized to fit the available space, which can vary depending on the window’s current orientation and the presence of other interface elements such as the status bar. You can configure the autoresizing properties in Interface Builder using the inspector window or programmatically by modifying the autoresizesSubviews and autoresizingMask properties of each view. Setting these properties is also important if your view controller supports both portrait and landscape orientations. During an orientation change, the system uses these properties to reposition and resize the views automatically to match the new orientation.
Memory is a critical resource in iPhone OS, and view controllers provide built-in support for reducing their memory footprint at critical times. The UIViewController class provides some automatic handling of low-memory conditions through its didReceiveMemoryWarning method, which releases unneeded memory. Prior to iPhone OS 3.0, this method was the only way to release additional memory associated with your custom view controller class but in iPhone OS 3.0 and later, the viewDidUnload method may be a more appropriate place for most needs.
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.
For general information and guidance about memory management practices in iPhone OS, see Memory Management Programming Guide for Cocoa.
By default, the UIViewController class displays views in portrait mode only. To support additional orientations, you must override the shouldAutorotateToInterfaceOrientation: method and return YES for any orientations your subclass supports. If the autoresizing properties of your views are configured correctly, that may be all you have to do. However, the UIViewController class provides additional hooks for you to implement additional behaviors as needed.
To temporarily turn off features that are not needed or might otherwise cause problems during the orientation change, you can override the willRotateToInterfaceOrientation:duration: method and perform the needed actions there. You can then override the didRotateFromInterfaceOrientation: method and use it to reenable those features once the orientation change is complete.
If you want to perform custom animations during an orientation change, you can do so in one of two ways. Orientation changes used to occur in two steps, with notifications occurring at the beginning, middle, and end points of the rotation. However, in iPhone OS 3.0, support was added for performing orientation changes in one step. Using a one-step orientation change tends to be faster than the older two-step process and is generally recommended for any new code.
To add animations for a one-step orientation change, override the willAnimateRotationToInterfaceOrientation:duration: method and perform your animations there. To use the older two-step method, override one or both of the willAnimateFirstHalfOfRotationToInterfaceOrientation:duration: and willAnimateSecondHalfOfRotationFromInterfaceOrientation:duration: methods to configure your animations before each step. You must choose only one technique and override just the methods associated with that technique. If you override either method associated with the two-step technique, the view controller uses that technique by default.
– initWithNibName:bundle:
nibName property
nibBundle property
view property
– loadView
– viewDidLoad
– viewDidUnload
– isViewLoaded
title property
wantsFullScreenLayout property
interfaceOrientation property
– shouldAutorotateToInterfaceOrientation:
– rotatingHeaderView
– rotatingFooterView
– willRotateToInterfaceOrientation:duration:
– willAnimateRotationToInterfaceOrientation:duration:
– didRotateFromInterfaceOrientation:
– willAnimateFirstHalfOfRotationToInterfaceOrientation:duration:
– didAnimateFirstHalfOfRotationToInterfaceOrientation:
– willAnimateSecondHalfOfRotationFromInterfaceOrientation:duration:
modalViewController property
parentViewController property
modalTransitionStyle property
– presentModalViewController:animated:
– dismissModalViewControllerAnimated:
navigationController property
navigationItem property
editing property
– setEditing:animated:
– editButtonItem
hidesBottomBarWhenPushed property
– setToolbarItems:animated:
toolbarItems property
tabBarController property
tabBarItem property
searchDisplayController property
For more about Objective-C properties, see “Properties” in The Objective-C Programming Language.
A Boolean value indicating whether the view controller currently allows the user to edit the view contents.
@property(nonatomic, getter=isEditing) BOOL editing
If YES, the view controller currently allows editing; otherwise, NO.
If the view is editable and the associated navigation controller contains an edit-done button, then a Done button is displayed; otherwise, an Edit button is displayed. Clicking either button toggles the state of this property. Add an edit-done button by setting the custom left or right view of the navigation item to the value returned by the editButtonItem method. Set the editing property to the initial state of your view. Use the setEditing:animated: method as an action method to animate the transition of this state if the view is already displayed.
UIViewController.hA Boolean value indicating whether the bar at the bottom of the screen is hidden when the view controller is pushed on to a navigation controller.
@property(nonatomic) BOOL hidesBottomBarWhenPushed
If YES, the bar at the bottom of the screen is hidden; otherwise, NO. If YES, the bottom bar remains hidden until the view controller is popped from the stack.
UINavigationController.hThe current orientation of the interface. (read-only)
@property(nonatomic, readonly) UIInterfaceOrientation interfaceOrientation
The possible values are described in UIInterfaceOrientation.
– willRotateToInterfaceOrientation:duration:– willAnimateFirstHalfOfRotationToInterfaceOrientation:duration:– willAnimateSecondHalfOfRotationFromInterfaceOrientation:duration:– didRotateFromInterfaceOrientation:UIViewController.hThe transition style to use when presenting the current view controller modally.
@property (nonatomic,assign) UIModalTransitionStyle modalTransitionStyle
This property affects the way the current view controller is presented when it is presented using the presentModalViewController:animated: method. To change the transition type, you must set this property before presenting the view controller.
The default value for this property is UIModalTransitionStyleCoverVertical.
UIViewController.hThe controller for the active modal view—that is, the view that is temporarily displayed on top of the view managed by the receiver. (read-only)
@property(nonatomic, readonly) UIViewController *modalViewController
Typically, a modal view is used to present an edit page or additional details of a model object. The modal view is optionally displayed using a vertical sheet transition.
UIViewController.hA parent or ancestor that is a navigation controller. (read-only)
@property(nonatomic, readonly, retain) UINavigationController *navigationController
Only returns a navigation controller if the view controller is in its stack. This property is nil if a navigation controller cannot be found.
UINavigationController.hThe navigation item used to represent the view controller. (read-only)
@property(nonatomic, readonly, retain) UINavigationItem *navigationItem
This is a unique instance of UINavigationItem created to represent the view controller when it is pushed onto a navigation bar. The first time you access this property, the UINavigationItem is created. Therefore, you shouldn’t access this property if you are not using a navigation controller.
UINavigationController.hReturn the name of the receiver’s nib bundle if it exists. (read-only)
@property(nonatomic,readonly, retain) NSBundle *nibBundle
UIViewController.hReturn the name of the receiver’s nib file, if one was specified. (read-only)
@property(nonatomic,readonly, copy) NSString *nibName
This property contains the value specified at initialization time to the initWithNibName:bundle: method. The value of this property may be nil.
If the value of this property is nil and you did not override the loadView method in your custom subclass, the view controller looks for a nib file whose name (without the .nib extension) matches the name of your view controller class.
UIViewController.hThe parent of the current view controller. (read-only)
@property(nonatomic, readonly) UIViewController *parentViewController
Parent view controllers are relevant in navigation, tab bar, and modal view controller hierarchies. In each of these hierarchies, the parent is the object responsible for displaying the current view controller. If you are using a view controller as a standalone object—that is, not as part of a view controller hierarchy—the value in this property is nil.
UIViewController.hThe search display controller associated with the view controller. (read-only)
@property(nonatomic, readonly, retain) UISearchDisplayController *searchDisplayController
This property reflects the value of the searchDisplayController outlet that you set in Interface Builder. If you create your search display controller programmatically, this property is set automatically by the search display controller when it is initialized.
UIViewController.hA parent or ancestor that is a tab bar controller. (read-only)
@property(nonatomic, readonly, retain) UITabBarController *tabBarController
If the receiver is added to a tab bar controller, this property is the tab bar controller. If the receiver’s navigation controller is added to a tab bar controller, this property is the navigation controller’s tab bar controller. If no tab bar is present or the receiver is a modal view, this property is nil.
UITabBarController.hThe tab bar item that represents the view controller when added to a tab bar controller.
@property(nonatomic, retain) UITabBarItem *tabBarItem
The default value is a tab bar item that displays the view controller’s title. The first time you access this property, the UITabBarItem is created. Therefore, you shouldn’t access this property if you are not using a tab bar controller.
UITabBarController.hA localized string that represents the view that this controller manages.
@property(nonatomic, copy) NSString *title
Subclasses should set the title to a human-readable string that represents the view to the user. If the receiver is a navigation controller, the default value is the top view controller’s title.
UIViewController.hThe toolbar items associated with the view controller.
@property (nonatomic, retain) NSArray *toolbarItems
This property contains an array of UIBarButtonItem objects and works in conjunction with a UINavigationController object. If this view controller is embedded inside a navigation controller interface, and the navigation controller displays a toolbar, this property identifies the items to display in that toolbar.
You can set the value of this property explicitly or use the setToolbarItems:animated: method to animate changes to the visible set of toolbar items.
UINavigationController.hThe view that the controller manages.
@property(nonatomic, retain) UIView *view
The view stored in this property represents the root view for the view controller’s view hierarchy. Whenever you present the view controller on screen (either modally or as part of view controller–based interface), this view is retrieved and displayed in the application window. The default value of this property is nil.
If you access this property and its value is currently nil, the view controller automatically calls the loadView method and returns the resulting view. The default loadView method attempts to load the view from the nib file associated with the view controller (if any). If your view controller does not have an associated view controller, you should override the loadView method and use it to create the root view and all of its subviews.
Each view controller object is the sole owner of its view. You must not associate the same view object with multiple view controller objects.
Because accessing this property can cause the view to be loaded automatically, you can use the isViewLoaded property to determine if the view is currently in memory. Unlike this property, the isViewLoaded property does not force the loading of the view if it is not currently in memory.
The UIViewController class automatically sets this property to nil during low-memory conditions and when the view controller itself is finally released.
UIViewController.hA Boolean value indicating whether the view should overlap the status bar.
@property(nonatomic,assign) BOOL wantsFullScreenLayout
When a view controller presents its view, it normally shrinks that view so that its frame does not overlap the device’s status bar. Setting this property to YES causes the view controller to size its view so that it fills the entire screen, including the area under the status bar. (Of course, for this to happen, the window hosting the view controller must itself be sized to fill the entire screen, including the area underneath the status bar.) You would typically set this property to YES in cases where you have a translucent status bar and want your view’s content to be visible behind that view.
If this property is YES, the view is not resized in a way that would cause it to overlap a tab bar but is resized to overlap translucent toolbars. Regardless of the value of this property, navigation controllers always allow views to overlap translucent navigation bars.
The default value of this property is NO, which causes the view to be laid out so it does not overlap the status bar.
UIViewController.hSent to the view controller after the completion of the first half of the user interface rotation.
- (void)didAnimateFirstHalfOfRotationToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation
The state of the application’s user interface orientation after the rotation. The possible values are described in UIInterfaceOrientation.
This method is called during two-step rotation animations only. Subclasses can override this method and use it to adjust their views between the first and second half of the animations. This method is called outside of any animation transactions and while any header or footer views are offscreen.
– willAnimateFirstHalfOfRotationToInterfaceOrientation:duration:– willAnimateSecondHalfOfRotationFromInterfaceOrientation:duration:UIViewController.hSent to the view controller when the application receives a memory warning.
- (void)didReceiveMemoryWarning
The default implementation of this method checks to see if the view controller can safely release its view. This is possible if the view itself does not have a superview and can be reloaded either from a nib file or using a custom loadView method. If the view can be released, this method releases it and calls the viewDidUnload method.
You can override this method (as needed) to release any additional memory used by your view controller. If you do, be sure to call the super implementation at some point to allow the view controller to release its view. In iPhone OS 3.0 and later, if your view controller holds references to objects in the view hierarchy, you should release those references in the viewDidUnload method instead. In earlier versions of iPhone OS, you should continue to release them from this method. See the discussion in the viewDidUnload method for information about how to safely release outlets and other objects.
UIViewController.hSent to the view controller after the user interface rotates.
- (void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation
The old orientation of the user interface. The possible values are described in UIInterfaceOrientation.
Subclasses may override this method to perform additional actions immediately after the rotation. For example, you might use this method to reenable view interactions, start media playback again, or turn on expensive drawing or live updates. By the time this method is called, the interfaceOrientation property is already set to the new orientation.
This method is called regardless of whether your code performs one-step or two-step rotations.
UIViewController.hDismisses the modal view controller that was presented by the receiver.
- (void)dismissModalViewControllerAnimated:(BOOL)animated
If YES, this method animates the view as it’s dismissed; otherwise, it does not. The style of animation is determined by the value in the modalTransitionStyle property of the view controller being dismissed.
The parent view controller is responsible for dismissing the modal view controller it presented using the presentModalViewController:animated: method. If you call this method on the modal view controller itself, however, the modal view controller automatically forwards the message to its parent view controller.
If you present several modal view controllers in succession, and thus build a stack of modal view controllers, calling this method on a view controller lower in the stack dismisses its immediate child view controller and all view controllers above that child on the stack. When this happens, only the top-most view is dismissed in an animated fashion; any intermediate view controllers are simply removed from the stack. The top-most view is dismissed using its modal transition style, which may differ from the styles used by other view controllers lower in the stack.
If you want to retain a reference to the receiver’s modal view controller, get the value in the modalViewController property before calling this method.
UIViewController.hReturns a bar button item that toggles its title and associated state between Edit and Done.
- (UIBarButtonItem *)editButtonItem
If one of the custom views of the navigationItem property is set to the returned object, the associated navigation bar displays an Edit button if editing is NO and a Done button if editing is YES. The default button action invokes the setEditing:animated: method.
UIViewController.hReturns a newly initialized view controller with the nib file in the specified bundle.
- (id)initWithNibName:(NSString *)nibName bundle:(NSBundle *)nibBundle
The name of the nib file, without any leading path information. If you specify a nib name and need to set values after the nib file is loaded, then you should override the viewDidLoad method to do so. If this argument is nil, the nibName property is set to nil. In this case, you should override the loadView method to set the view property.
The bundle in which to search for the nib file. This method looks for the nib file in the bundle's language-specific project directories first, followed by the Resources directory. If nil, this method looks for the nib file in the main bundle.
A newly initialized UIViewController object.
This is the designated initializer for this class.
If you specify nil for the nibName parameter and do not override the loadView method in your custom subclass, the default view controller behavior is to look for a nib file whose name (without the .nib extension) matches the name of your view controller class. If it finds one, the class name becomes the value of the nibName property, which results in the corresponding nib file being associated with this view controller.
UIViewController.hReturns a Boolean value indicating whether the view is currently loaded into memory.
- (BOOL)isViewLoaded
Calling this method simply reports whether the view is loaded. Unlike the view property, it does not attempt to load the view if it is not already in memory.
UIViewController.hCreates the view that the controller manages.
- (void)loadView
You should never call this method directly. The view controller calls this method when the view property is requested but is currently nil. If you create your views manually, you must override this method and use it to create your views. If you use Interface Builder to create your views and initialize the view controller—that is, you initialize the view using the initWithNibName:bundle: method, set the nibName and nibBundle properties directly, or create both your views and view controller in Interface Builder—then you must not override this method.
The default implementation of this method looks for valid nib information and uses that information to load the associated nib file. If no nib information is specified, the default implementation creates a plain UIView object and makes it the main view.
If you override this method in order to create your views manually, you should do so and assign the root view of your hierarchy to the view property. (The views you create should be unique instances and should not be shared with any other view controller object.) Your custom implementation of this method should not call super.
If you want to perform any additional initialization of your views, do so in the viewDidLoad method. In iPhone OS 3.0 and later, you should also override the viewDidUnload method to release any references to the view or its contents.
UIViewController.hPresents a modal view managed by the given view controller to the user.
- (void)presentModalViewController:(UIViewController *)modalViewController animated:(BOOL)animated
The view controller that manages the modal view.
If YES, animates the view as it’s presented; otherwise, does not.
Sets the modalViewController property to the specified view controller. Resizes its view and attaches it to the view hierarchy. The view is animated according to the transition style specified in the modalTransitionStyle property of the controller in the modalViewController parameter.
UIViewController.hReturns the footer view that slides in and out before and after the user interface rotates.
- (UIView *)rotatingFooterView
The footer view.
If the view controller is a tab bar controller, returns a view containing the tab bar. If the view controller is a navigation controller, returns the top view controller’s footer view. If the keyboard is active, returns the keyboard; otherwise, it returns nil.
In most cases, the header view is the navigation bar and the footer view is the tab bar. If the default behavior is not desired, subclasses should override this method to return an alternate view (that is a already in the receiver’s view hierarchy) that is used as the footer view.
UIViewController.hReturns the header view that slides in and out before and after the user interface rotates.
- (UIView *)rotatingHeaderView
The header view or nil if there is no header view. If the current view controller is a tab bar controller, this method returns the header view of the view controller in the selected tab. If the current view controller is a navigation controller, this method returns the associated navigation bar.
In most cases, the header view is the navigation bar and the footer view is the tab bar. If the default behavior is not desired, subclasses should override this method to return an alternate view (that is a already in the receiver’s view hierarchy) that is used as the header view.
UIViewController.hSets whether the view controller shows an editable view.
- (void)setEditing:(BOOL)editing animated:(BOOL)animated
If YES, the view controller should display an editable view; otherwise, NO.
If YES and one of the custom views of the navigationItem property is set to the value returned by the editButtonItem method, the associated navigation controller displays a Done button; otherwise, an Edit button.
If YES, animates the transition; otherwise, does not.
Subclasses that use an edit-done button must override this method to change their view to an editable state if editing is YES and a noneditable state if it is NO. This method should invoke super’s implementation before updating its view.
UIViewController.hSets the toolbar items to be displayed along with the view controller.
- (void)setToolbarItems:(NSArray *)toolbarItems animated:(BOOL)animated
The toolbar items to display in a built-in toolbar.
If YES, animate the change of items in the toolbar.
View controllers that are managed by a navigation controller can use this method to specify toolbar items for the navigation controller’s built-in toolbar. You can set the toolbar items for your view controller before your view controller is displayed or after it is already visible.
UINavigationController.hReturns a Boolean value indicating whether the view controller autorotates its view.
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
The orientation of the application’s user interface after the rotation. The possible values are described in UIInterfaceOrientation.
YES if the view controller autorotates its view to the specified orientation; otherwise, NO .
By default, this method returns YES for the UIInterfaceOrientationPortrait orientation only. If your view controller supports additional orientations, override this method and return YES for all orientations it supports.
Your implementation of this method should simply return YES or NO based on the value in the interfaceOrientation parameter. Do not attempt to get the value of the interfaceOrientation property or check the orientation value reported by the UIDevice class. Your view controller is either capable of supporting a given orientation or it is not.
UIViewController.hNotifies the view controller that its view was added to a window.
- (void)viewDidAppear:(BOOL)animated
If YES, the view was added to the window using an animation.
You can override this method to perform additional tasks associated with presenting the view. If you override this method, you must call super at some point in your implementation.
UIViewController.hNotifies the view controller that its view was dismissed, covered, or otherwise hidden from view.
- (void)viewDidDisappear:(BOOL)animated
If YES, the disappearance of the view was animated.
You can override this method to perform additional tasks associated with dismissing or hiding the view. If you override this method, you must call super at some point in your implementation.
UIViewController.hCalled after the controller’s view is loaded into memory.
- (void)viewDidLoad
This method is called after the view controller has loaded its associated views into memory. This method is called regardless of whether the views were stored in a nib file or created programmatically in the loadView method. This method is most commonly used to perform additional initialization steps on views that are loaded from nib files.
UIViewController.hCalled when the controller’s view is released from memory.
- (void)viewDidUnload
This method is called as a counterpart to the viewDidLoad method. It is called during low-memory conditions when the view controller needs to release its view and any objects associated with that view to free up memory. Because view controllers often store references to views and other view-related objects, you should use this method to relinquish ownership in those objects so that the memory for them can be reclaimed. You should do this only for objects that you can easily recreate later, either in your viewDidLoad method or from other parts of your application. You should not use this method to release user data or any other information that cannot be easily recreated.
Typically, a view controller stores references to objects using an outlet, which is a variable or property that includes the IBOutlet keyword and is configured using Interface Builder. A view controller may also store pointers to objects that it creates programmatically, such as in the viewDidLoad method. The preferred way to relinquish ownership of any object (including those in outlets) is to use the corresponding accessor method to set the value of the object to nil. However, if you do not have an accessor method for a given object, you may have to release the object explicitly. For more information about memory management practices, see Memory Management Programming Guide for Cocoa.
By the time this method is called, the view property is nil.
If your view controller stores references to views and other custom objects, it is also responsible for relinquishing ownership of those objects safely in its dealloc method. If you implement this method but are building your application for iPhone OS 2.x, your dealloc method should release each object but should also set the reference to that object to nil before calling super.
UIViewController.hNotifies the view controller that its view is about to be added to a window.
- (void)viewWillAppear:(BOOL)animated
If YES, the view is being added to the window using an animation.
This method is called in response to a view being added either directly or indirectly to a window. You add views to a window directly by using the addSubview: method to add them to the window’s view hierarchy. You can also add a view indirectly in several ways, including by pushing it onto a navigation stack or by presenting it modally (using the presentModalViewController:animated: method). This method is called before the view is actually added to the window and before any animations are configured.
You can override this method to perform custom tasks associated with presenting the view. For example, you might use this method to change the orientation or style of the status bar to coordinate with the orientation or style of the view being presented. If you override this method, you must call super at some point in your implementation.
UIViewController.hNotifies the view controller that its view is about to be dismissed, covered, or otherwise hidden from view.
- (void)viewWillDisappear:(BOOL)animated
If YES, the disappearance of the view is being animated.
This method is called in response to a view being removed from its window or covered by another view. This method is called before the view is actually removed or covered and before any animations are configured.
Subclasses can override this method and use it to commit editing changes, resign the first responder status of the view, or perform other relevant tasks. For example, you might use this method to revert changes to the orientation or style of the status bar that were made in the viewDidDisappear: method when the view was first presented. If you override this method, you must call super at some point in your implementation.
UIViewController.hSent to the view controller before performing the first half of a user interface rotation.
- (void)willAnimateFirstHalfOfRotationToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration
The state of the application’s user interface orientation before the rotation. The possible values are described in UIInterfaceOrientation.
The duration of the first half of the pending rotation, measured in seconds.
The default implementation of this method does nothing. If you override this method (or the willAnimateSecondHalfOfRotationFromInterfaceOrientation:duration: method), the view controller always performs rotation animations in two steps. To configure animations using the one-step technique, override the willAnimateRotationToInterfaceOrientation:duration: method instead.
This method is called from within the animation block that is used to rotate the view and slide the header and footer views out. You can override this method and use it to configure additional animations that should occur during the first half of the view rotation. For example, you could use it to adjust the zoom level of your content, change the scroller position, or modify other animatable properties of your view.
At the time this method is called, the interfaceOrientation property is still set to the old orientation.
– willRotateToInterfaceOrientation:duration:– willAnimateSecondHalfOfRotationFromInterfaceOrientation:duration:– didRotateFromInterfaceOrientation:UIViewController.hSent to the view controller before performing a one-step user interface rotation.
- (void)willAnimateRotationToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation duration:(NSTimeInterval)duration
The new orientation for the user interface. The possible values are described in UIInterfaceOrientation.
The duration of the pending rotation, measured in seconds.
The default implementation of this method does nothing. If you override this method, you should not override either the willAnimateFirstHalfOfRotationToInterfaceOrientation:duration: or willAnimateSecondHalfOfRotationFromInterfaceOrientation:duration: method. If you do override either of those methods, this method is never called.
This method is called from within the animation block that is used to rotate the view. You can override this method and use it to configure additional animations that should occur during the view rotation. For example, you could use it to adjust the zoom level of your content, change the scroller position, or modify other animatable properties of your view.
By the time this method is called, the interfaceOrientation property is already set to the new orientation. Thus, you can perform any additional layout required by your views in this method.
UIViewController.hSent to the view controller before the second half of the user interface rotates.
- (void)willAnimateSecondHalfOfRotationFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation duration:(NSTimeInterval)duration
The state of the application’s user interface orientation before the rotation. The possible values are described in UIInterfaceOrientation.
The duration of the second half of the pending rotation, measured in seconds.
The default implementation of this method does nothing. If you override this method (or the willAnimateFirstHalfOfRotationToInterfaceOrientation:duration: method), the view controller always performs rotation animations in two steps. To configure animations using the one-step technique, override the willAnimateRotationToInterfaceOrientation:duration: method instead.
This method is called from inside the animation block that is used to finish the view rotation and slide the header and footer views back into position. You can override this method and use it to configure additional animations that should occur during the second half of the view rotation. For example, you could use it to adjust the zoom level of your content, change the scroller position, or modify other animatable properties of your view.
At the time this method is invoked, the interfaceOrientation property is set to the new orientation.
– willRotateToInterfaceOrientation:duration:– willAnimateFirstHalfOfRotationToInterfaceOrientation:duration:– didRotateFromInterfaceOrientation:UIViewController.hSent to the view controller just before the user interface begins rotating.
- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration
The new orientation for the user interface. The possible values are described in UIInterfaceOrientation.
The duration of the pending rotation, measured in seconds.
Subclasses may override this method to perform additional actions immediately prior to the rotation. For example, you might use this method to disable view interactions, stop media playback, or temporarily turn off expensive drawing or live updates. You might also use it to swap the current view for one that reflects the new interface orientation. When this method is called, the interfaceOrientation property still contains the view’s original orientation.
This method is called regardless of whether your code performs one-step or two-step rotations.
UIViewController.hTransition styles available when presenting view controllers modally.
typedef enum {
UIModalTransitionStyleCoverVertical = 0,
UIModalTransitionStyleFlipHorizontal,
UIModalTransitionStyleCrossDissolve,
} UIModalTransitionStyle;
UIModalTransitionStyleCoverVerticalWhen the view controller is presented, its view slides up from the bottom of the screen. On dismissal, the view slides back down. This is the default transition style.
Available in iPhone OS 3.0 and later.
Declared in UIViewController.h.
UIModalTransitionStyleFlipHorizontalWhen the view controller is presented, the current view initiates a horizontal 3D flip from right-to-left, resulting in the revealing of the new view as if it were on the back of the previous view. On dismissal, the flip occurs from left-to-right, returning to the original view.
Available in iPhone OS 3.0 and later.
Declared in UIViewController.h.
UIModalTransitionStyleCrossDissolveWhen the view controller is presented, the current view fades out while the new view fades in at the same time. On dismissal, a similar type of cross-fade is used to return to the original view.
Available in iPhone OS 3.0 and later.
Declared in UIViewController.h.
Last updated: 2009-08-19
iPhone OS Reference Library User Experience: Windows & Views UIViewController Class Reference