UIViewController Class Reference

【翻译自官方的类参考文档】

Overview

概览

The UIViewController class provides the fundamental view-management model for all iOS apps. You rarely instantiateUIViewController objects directly. Instead, you instantiate subclasses of theUIViewController class based on the specific task each subclass performs. A view controller manages a set of views that make up a portion of your app’s user interface. As part of the controller layer of your app, a view controller coordinates its efforts with model objects and other controller objects—including other view controllers—so your app presents a single coherent user interface.

UIViewController为所有的iOS app提供了基本的视图管理模型。你很少直接实例化UIViewController对象，相反你直接实现需要执行特定任务的子类。一个视图管理器管理一系列组成组成你程序用户界面的视图。作为你的app控制器层的一部分，一个视图控制器协调模型对象和起亚控制器对象，包括其他视图控制器对象，所以你的app呈现一个单一连贯的用户界面

Where necessary, a view controller:

• resizes and lays out its views
• adjusts the contents of the views
• acts on behalf of the views when the user interacts with them

必要时，一个视图控制器：

1，重新调整和显示它的视图

2，调整视图的内容

3， 根据用户与视图的交互响应操作

View controllers are tightly bound to the views they manage and take part in the responder chain used to handle events. View controllers are descendants of theUIResponder class and are inserted into the responder chain between the managed root view and its superview, which typically belongs to a different view controller. If the view controller’s view does not handle an event, the view controller has the option of handling the event or it can pass the event to the superview.

视图控制器和它所管理的视图紧紧绑定，并且参与到处理事件的响应链。视图控制器是UIResponder类的子类。并且嵌入到管理的根视图还有它的父视图之间的响应链中，这属于一个不同的视图控制器。如果视图控制器的视图不处理一个事件，那么这个视图控制器可以选择处理这个事件或者它可以把这个事件传递给它的父视图。

View controllers are rarely used in isolation. Instead, you use multiple view controllers, each of which owns a portion of your app’s user interface. For example, one view controller might manage a table of items while a different view controller manages the display of a selected item from that table. Each view controller displays its own views to show the content it is responsible for.

视图控制器很少孤立的使用。相反，你使用各种各样的视图控制器，每个都拥有你的程序用户界面的一部分。例如，一个视图控制管理一个列表项，而其他不同的视图负责显示这个列表中的某一项的内容。

Subclassing Notes

子类化建议

An app contains at least one custom subclass of UIViewController and more often there are several. These custom subclasses define behaviors specific to your app, such as how it handles user interactions with its views. The following sections provide a brief overview of some of the tasks your custom subclass performs. For more information about implementing your custom subclasses, seeView Controller Programming Guide for iOS.

一个app包含只是一个自定义的UIViewController子类，事实上经常不止一个。自定义的子类定义了针对你的app的行为，比如如何处理用户与视图的交互。接下来的部分提供了自定义子类的执行的某些任务的概览。可以参考一下（View Controller Programming Guide for iOS）。

View Management

视图管理

When you define a new subclass of UIViewController, you must specify the views to be managed by the controller. A typical view hierarchy consists of a view with flexible bounds—a reference to which is available in theview property of this class—and one or more subviews that provide the actual content. The size and position of the root view is usually determined by another object that owns the view controller and displays its contents. The view controller determines the positions of any subviews it owns based on the size given to its root view by the owning object. A view controller is usually owned by a window or another view controller. If a view controller is owned by a window object, it acts as the window’s root view controller. The view controller’s root view is added as a subview of the window and resized to fill the window. If the view controller is owned by another view controller, then the parent view controller determines when and how the child view controller’s contents are displayed.

当你定义一个新的UIViewController的子类，你必须指定这个控制器管理的视图。一个典型的视图层次包含一个有着灵活边界的视图,对这个边界的引用可以在这个类的视图属性中使用，并且至少一个子视图提供实际的内容。拥有视图管理器以及展示它的内容的对象觉得了根视图的大小和位置。视图控制器根据子视图传给根视图的大小决定子视图的位置。一个视图控制器通常被一个窗口(window)或者其他的视图控制器拥有。如果一个视图控制器被一个窗口拥有，那么它就是这个窗口的根视图视图控制器。这个视图控制器的根视图被加到了这个窗口的子类中并且缩放去填充这个窗口。如果这个视图被另外一个视图拥有，那么父视图控制器决定何时以及如何显示子视图控制器。

The UIViewController class provides built-in support for loading a view controller’s views whenever they are needed. Specifically, views are automatically loaded when theview property is accessed. There are a few ways you can implement your app to load these views:

每当需要时，UIViewController Class内嵌支持加载一个视图管理器的视图。特别地，当视图属性被访问时，视图被自动加载。

• You can specify the views for a view controller using a storyboard created in Interface Builder. A storyboard contains preconfigured view controllers and their associated views and is the preferred way to develop your app’s user interface. A key advantage of storyboards is that they can express relationships between different view controllers in your app. For example, you can state that one view controller’s contents are contained inside another view controller or that a view controller is displayed as a transition (known as a segue) from another view controller . By allowing you to see the relationships between view controllers, storyboards make it easier to understand your app’s behavior at a glance.At runtime, the view controller uses the storyboard to automatically instantiate and configure its views. Often, the view controller itself is automatically created by segues defined in the storyboard. When you define a view controller’s contents using a storyboard, you never directly allocate and initialize the view controller object. Instead, when you need to programmatically instantiate the view controller, you do so by calling the instantiateViewControllerWithIdentifier: method on a UIStoryboard object.
• You can specify the views for a view controller using a nib file, also created in Interface Builder. Like a storyboard, a nib file allows you to create and configure a set of views. However, you cannot easily create or see the relationships between view controllers using nib files as you can when using storyboards.To initialize your view controller object using a nib, you use theinitWithNibName:bundle: method to specify the nib file used by the view controller. Then, when the view controller needs to load its views, it automatically creates and configures the views using the information stored in the nib file.
• If you cannot define your views in a storyboard or a nib file, override theloadView method to manually instantiate a view hierarchy and assign it to theview property.

1，你可以在Interface Builder里创建一个storyboard，然后通过它来制定视图控制器的视图。stotyboard包含预配置的视图控制器以及他们的相关的视图，这是开发应用程序界面的好方法。storyboard的重要优势是他们能表现应用中不同视图控制器间的关系。你可以规定一个视图控制器的内容包含在另外一个视图控制器中，或者一个视图控制器从另外一个视图控制器转移过来的。【本段未完】

2，你可以用nib文件制定视图控制器的视图，nib也是通过Interface Builder创建的。类似storyBoard。nib文件允许你创建并且配置一系列视图。但是，你不能使用nib文件创建或者看到两个视图控制器间的关系。要使用nib初始化你视图控制器的对象，你可以通过视图控制使用initWithNibName:bundle: 方法指定nib文件。然后，当视图控制器需要加载视图时，它自动使用存在nib文件中的信息创建和配置视图。

3，你不能在storyboard或者nib文件中定义你的视图，复写loadView 方法去手动地实例化视图层次并把他赋给view属性。

All of these techniques have the same end result, which is to create the appropriate set of views and expose them through theview property.

所以这些技术都有同样的结果，就是创建适当的视图集，并通过view属性显示它们。

Important: A view controller is the sole owner of its view and any subviews it creates. It is responsible for creating those views and for relinquishing ownership of them at the appropriate times such as when the view controller itself is released. If you use a storyboard or a nib file to store your view objects, each view controller object automatically gets its own copy of these views when the view controller asks for them. However, if you create your views manually, you should never use the same view objects with multiple view controllers.

重要：视图控制器是它的视图以及这个视图创建的子类的唯一拥有者。它负责创建这些视图，以及在适当的时候，比如当这个视图控制器自己被释放的时候，要释放对它们的所有权。如果你使用storyboard或者nib存储你的视图对象，当视图控制器需要它们时，每个视图控制器自动获取这些视图的拷贝。如果你手动创建视图，你不要在不同的视图控制器中使用相同的视图对象。

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 theautoresizesSubviews 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. If your view controller supports autolayout and is a child of another view controller, you should call the view’ssetTranslatesAutoresizingMaskIntoConstraints: method to disable these constraints.

Memory Management

Memory is a critical resource in iOS, and view controllers provide built-in support for reducing their memory footprint at critical times. TheUIViewController class provides some automatic handling of low-memory conditions through itsdidReceiveMemoryWarning method, which releases unneeded memory.

Prior to iOS 6, when a low-memory warning occurred, the UIViewController class purged its views if it knew it could reload or recreate them again later. If this happens, it also calls theviewWillUnload and viewDidUnload methods to give your code a chance to relinquish ownership of any objects that are associated with your view hierarchy, including objects loaded from the nib file, objects created in yourviewDidLoad method, and objects created lazily at runtime and added to the view hierarchy. On iOS 6, views are never purged and these methods are never called. If your view controller needs to perform specific tasks when memory is low, it should override the didReceiveMemoryWarning method.

Handling View Rotations

In iOS 6, your app supports the interface orientations defined in your app’sInfo.plist file. A view controller can override the supportedInterfaceOrientations method to limit the list of supported orientations. Generally, the system calls this method only on the root view controller of the window or a view controller presented to fill the entire screen; child view controllers use the portion of the window provided for them by their parent view controller and no longer participate in directly in decisions about what rotations are supported. The intersection of the app’s orientation mask and the view controller’s orientation mask is used to determine which orientations a view controller can be rotated into.

You can override the preferredInterfaceOrientationForPresentation for a view controller that is intended to be presented full screen in a specific orientation.

In iOS 5 and earlier, the UIViewController class displays views in portrait mode only. To support additional orientations, you must override theshouldAutorotateToInterfaceOrientation: method and returnYES 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, theUIViewController class provides additional hooks for you to implement additional behaviors as needed. Generally, if your view controller is intended to be used as a child view controller, it should support all interface orientations.

When a rotation occurs for a visible view controller, the willRotateToInterfaceOrientation:duration:, willAnimateRotationToInterfaceOrientation:duration:, anddidRotateFromInterfaceOrientation: methods are called during the rotation. TheviewWillLayoutSubviews method is also called after the view is resized and positioned by its parent. If a view controller is not visible when an orientation change occurs, then the rotation methods are never called. However, theviewWillLayoutSubviews method is called when the view becomes visible. Your implementation of this method can call thestatusBarOrientation method to determine the device orientation.

Note: At launch time, apps should always set up their interface in a portrait orientation. After theapplication:didFinishLaunchingWithOptions: method returns, the app uses the view controller rotation mechanism described above to rotate the views to the appropriate orientation prior to showing the window.

View Event Notification

The UIViewController class automatically responds to many notifications, such as when the view controller’s view is added to or removed from a window’s view hierarchy or when it is resized. TheUIViewController class provides specific methods that are called when these events occur. Subclasses can override these methods to implement specific behaviors.

Implementing a Container View Controller

A custom UIViewController subclass can also act as a container view controller. A container view controller manages the presentation of content of other view controllers it owns, also known as its child view controllers. A child’s view can be presented as-is or in conjunction with views owned by the container view controller.

Your container view controller subclass should declare a public interface to associate its children. The nature of these methods is up to you and depends on the semantics of the container you are creating. You need to decide how many children can be displayed by your view controller at once, when those children are displayed, and where they appear in your view controller’s view hierarchy. Your view controller class defines what relationships, if any, are shared by the children. By establishing a clean public interface for your container, you ensure that children use its capabilities logically, without accessing too many private details about how your container implements the behavior.

Your container view controller must associate a child view controller with itself before adding the child’s root view to the view hierarchy. This allows iOS to properly route events to child view controllers and the views those controllers manage. Likewise, after it removes a child’s root view from its view hierarchy, it should disconnect that child view controller from itself. To make or break these associations, your container calls specific methods defined by the base class. These methods are not intended to be called by clients of your container class; they are to be used only by your container’s implementation to provide the expected containment behavior.

Here are the essential methods you might need to call:

• addChildViewController:
• removeFromParentViewController
• willMoveToParentViewController:
• didMoveToParentViewController:

Note: You are not required to override any methods when creating a container view controller.

By default, rotation and appearance callbacks are automatically forwarded to children. You may optionally override theshouldAutomaticallyForwardRotationMethods and shouldAutomaticallyForwardAppearanceMethods methods to take control of this behavior yourself.