why "present modal view controller"?

Question

Just curious about the modal view controller usage. When and why should we use them? Is there a guideline?

I found the sample core data book code create a navigation controller just to present a modal view controller. Why is that?

   UINavigationController *navController = [[UINavigationController alloc] 
                                                 initWithRootViewController:addViewController];

    [self.navigationController presentModalViewController:navController 
                               animated:YES];

Is there a functional reason to this? Would it work if we just push the addViewController to self.navigationController?

Answer 1

Generally you use modal view controllers to focus the user's attention on a Task. When you push, the user is in some kind of navigation flow, but still has the total application at their fingertips. They might decide to go forward or backward, switch to a different tab in the middle, whatever. When they get a modal view controller, they can't do any of that until the task is completed or canceled out of (the modal view is dismissed).

Pls refer why does this code use presentModalViewController? (not pushViewController) also

Answer 2

Yes, there are guidelines. The iOS Human Interface Guidelines say:

Use a modal view when you need to offer the ability to accomplish a self-contained task related to your application’s primary function. A modal view is especially appropriate for a multistep subtask that requires UI elements that don’t belong in the main application user interface all the time.

They also say to "Make Modal Tasks Occasional and Simple":

When possible, minimize the number of times people must be in a modal environment to perform a task or supply a response. iOS applications should allow people to interact with them in nonlinear ways. Modality prevents this freedom by interrupting people’s workflow and forcing them to choose a particular path.

Modality is most appropriate when:

It’s critical to get the user’s attention. A task must be completed (or explicitly abandoned) to avoid leaving the user’s data in an ambiguous state. People appreciate being able to accomplish a self-contained subtask in a modal view, because the context shift is clear and temporary. But if the subtask is too complex, people can lose sight of the main task they suspended when they entered the modal view. This risk increases when the modal view is full screen and when it includes multiple subordinate views or states.

Keep modal tasks fairly short and narrowly focused. You don’t want your users to experience a modal view as a mini application within your application. Be especially wary of creating a modal task that involves a hierarchy of views, because people can get lost and forget how to retrace their steps. If a modal task must contain subtasks in separate views, be sure to give users a single, clear path through the hierarchy, and avoid circularities.

Always provide an obvious and safe way to exit a modal task. People should always be able to predict the fate of their work when they dismiss a modal view.

If the task requires a hierarchy of modal views, make sure your users understand what happens if they tap a Done button in a view that’s below the top level. Examine the task to decide whether a Done button in a lower-level view should finish only that view’s part of the task or the entire task. When possible, avoid adding Done buttons to subordinate views, because of this potential for confusion.

Answer 3

From Apple Documentation

Modal view controllers provide interesting ways to manage the flow of your application. Most commonly, applications use modal view controllers as a temporary interruption in order to obtain key information from the user. However, you can also use modally presented view controllers to implement alternate interfaces for your application at specific times.

Modal View Controllers