Presenting View Controllers from Other View Controllers

转自：https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/ModalViewControllers/ModalViewControllers.html

Presenting View Controllers from Other View Controllers

The ability to present view controllers is a tool that you have at your disposal for interrupting the current workflow and displaying a new set of views. Most commonly, an app presents a view controller as a temporary interruption to obtain important information from the user. However, you can also use presented view controllers to implement alternate interfaces for your app at specific times.

How View Controllers Present Other View Controllers

A presented view controller is not a specific subclass of UIViewController (as UITabBarController or UINavigationController is). Instead, any view controller can be presented by your app. However, like tab bar and navigation controllers, you present view controllers when you want to convey a specific meaning about the relationship between the previous view hierarchy and the newly presented view hierarchy.

When you present a modal view controller, the system creates a relationship between the view controller that did the presenting and the view controller that was presented. Specifically, the view controller that did the presenting updates its presentedViewController property to point to its presented view controller. Similarly, the presented view controller updates its presentingViewController property to point back to the view controller that presented it. Figure 10-1 shows the relationship between the view controller managing the main screen in the Calendar app and the presented view controller used to create new events.

Any view controller object can present a single view controller at a time. This is true even for view controllers that were themselves presented by another view controller. In other words, you can chain presented view controllers together, presenting new view controllers on top of other view controllers as needed. Figure 10-2 shows a visual representation of the chaining process and the actions that initiate it. In this case, when the user taps the icon in the camera view, the app presents a view controller with the user’s photos. Tapping the action button in the photo library’s toolbar prompts the user for an appropriate action and then presents another view controller (the people picker) in response to that action. Selecting a contact (or canceling the people picker) dismisses that interface and takes the user back to the photo library. Tapping the Done button then dismisses the photo library and takes the user back to the camera interface.

Each view controller in a chain of presented view controllers has pointers to the other objects surrounding it in the chain. In other words, a presented view controller that presents another view controller has valid objects in both its presentingViewController and presentedViewController properties. You can use these relationships to trace through the chain of view controllers as needed. For example, if the user cancels the current operation, you can remove all objects in the chain by dismissing the first presented view controller. Dismissing a view controller dismisses not only that view controller but also any view controllers it presented.

In Figure 10-2, a point worth noting is that the presented view controllers are both navigation controllers. You can present UINavigationController objects in the same way that you would present a content view controller.

When presenting a navigation controller, you always present the UINavigationController object itself, rather than presenting any of the view controllers on its navigation stack. However, individual view controllers on the navigation stack may present other view controllers, including other navigation controllers. Figure 10-3 shows more detail of the objects that are involved in the preceding example. As you can see, the people picker is not presented by the photo library navigation controller but by one of the content view controllers on its navigation stack.

Presentation Styles for Modal Views

For iPad apps, you can present content using several different styles. In iPhone apps, presented views always cover the visible portion of the window, but when running on an iPad, view controllers use the value in their modalPresentationStyle property to determine their appearance when presented. Different options for this property allow you to present the view controller so that it fills all or only part of the screen.

Figure 10-4 shows the core presentation styles that are available. (The UIModalPresentationCurrentContext style lets a view controller adopt the presentation style of its parent.) In each presentation style, the dimmed areas show the underlying content but do not allow taps in that content. Therefore, unlike a popover, your presented views must still have controls that allow the user to dismiss the view.

For guidance on when to use the different presentation styles, see Modal View in iOS Human Interface Guidelines.

Presenting a View Controller and Choosing a Transition Style

When a view controller is presented using a storyboard segue, it is automatically instantiated and presented. The presenting view controller can configure the destination view controller before it is presented. For more information, see Configuring the Destination Controller When a Segue is Triggered.

If you need to present a view controller programmatically, you must do the following:

1. Create the view controller you want to present.

2. Set the modalTransitionStyle property of the view controller to the desired value.

3. Assign a delegate object to the view controller. Typically, the delegate is the presenting view controller. The delegate is used by the presented view controllers to notify the presenting view controller when it is ready to be dismissed. It may also communicate other information back to the delegate.

4. Call the presentViewController:animated:completion: method of the current view controller, passing in the view controller you want to present.

The presentViewController:animated:completion: method presents the view for the specified view controller object and configures the presenting-presented relationships between the new view controller and the current view controller. Unless you are restoring your app to some previous state, you usually want to animate the appearance of the new view controller. The transition style you should use depends on how you plan to use the presented view controller. Table 10-1 lists the transition styles you can assign to themodalTransitionStyle property of the presented view controller and describes how you might use each one.

Listing 10-1 shows how to present a view controller programmatically. When the user adds a new recipe, the app prompts the user for basic information about the recipe by presenting a navigation controller. A navigation controller was chosen so that there would be a standard place to put a Cancel and Done button. Using a navigation controller also makes it easier to expand the new recipe interface in the future. All you would have to do is push new view controllers on the navigation stack.

Listing 10-1  Presenting a view controller programmatically

- (void)add:(id)sender {

   // Create the root view controller for the navigation controller

   // The new view controller configures a Cancel and Done button for the

   // navigation bar.

   RecipeAddViewController *addController = [[RecipeAddViewController alloc]

                       init];

   // Configure the RecipeAddViewController. In this case, it reports any

   // changes to a custom delegate object.

   addController.delegate = self;

   // Create the navigation controller and present it.

   UINavigationController *navigationController = [[UINavigationController alloc]

                             initWithRootViewController:addController];

   [self presentViewController:navigationController animated:YES completion: nil];

}

When the user taps either the Done or the Cancel button from the new recipe entry interface, the app dismisses the view controller and returns the user to the main view. SeeDismissing a Presented View Controller.

Presentation Contexts Provide the Area Covered by the Presented View Controller

The area of the screen used to define the presentation area is determined by the presentation context. By default, the presentation context is provided by the root view controller, whose frame is used to define the frame of the presentation context. However, the presenting view controller, or any other ancestor in the view controller hierarchy, can choose to provide the presentation context instead. In that case, when another view controller provides the presentation context, its frame is used instead to determine the frame of the presented view. This flexibility allows you to limit the modal presentation to a smaller portion of the screen, leaving other content visible.

When a view controller is presented, iOS searches for a presentation context. It starts at the presenting view controller by reading its definesPresentationContext property. If the value of this property is YES, then the presenting view controller defines the presentation context. Otherwise, it continues up through the view controller hierarchy until a view controller returns YES or until it reaches the window’s root view controller.

When a view controller defines a presentation context, it can also choose to define the presentation style. Normally, the presented view controller determines how it presented using its modalTransitionStyle property. A view controller that sets definesPresentationContext to YES can also set providesPresentationContextTransitionStyle to YES. If providesPresentationContextTransitionStyle is set to YES, iOS uses the presentation context’s modalPresentationStyle to determine how the new view controller is presented.

Dismissing a Presented View Controller

When it comes time to dismiss a presented view controller, the preferred approach is to let the presenting view controller dismiss it. In other words, whenever possible, the same view controller that presented the view controller should also take responsibility for dismissing it. Although there are several techniques for notifying the presenting view controller that its presented view controller should be dismissed, the preferred technique is delegation. For more information, see Using Delegation to Communicate with Other Controllers.

Presenting Standard System View Controllers

A number of standard system view controllers are designed to be presented by your app. The basic rules for presenting these view controllers are the same as the rules for presenting your custom content view controllers. However, because your app does not have access to the view hierarchy managed by the system view controllers, you cannot simply implement actions for the controls in the views. Interactions with the system view controllers typically take place through a delegate object.

Each system view controller defines a corresponding protocol, whose methods you implement in your delegate object. Each delegate usually implements a method to either accept whatever item was selected or cancel the operation. Your delegate object should always be ready to handle both cases. One of the most important things the delegate must do is dismiss the presented view controller by calling the dismissModalViewControllerAnimated: method of the view controller that did the presenting (in other words, the parent of the presented view controller.)

Table 10-2 lists several of the standard system view controllers found in iOS. For more information about each of these classes, including the features it provides, see the corresponding class reference documentation.