why “present modal view controller”?

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?

  • UIViewController In-Call Status Bar Issue
  • ios5 - size of modal view controller with storyboard
  • How to HIDE the iPad keyboard from a MODAL view controller?
  • dismissModalViewController AND pass data back
  • iOS Present modal view controller on startup without flash
  • How to present a half modal view controller over the top with iOS 7 custom transitions
  •    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?

    3 Solutions Collect From Internet About “why “present modal view controller”?”

    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

    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.

    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