只是对模态视图控制器的使用感到好奇。何时以及为什么要使用它们？有没有指导方针？为什么“现在的模态视图控制器”？
我发现示例核心数据手册代码创建一个导航控制器只是为了呈现一个模态视图控制器。这是为什么？
UINavigationController *navController = [[UINavigationController alloc]
initWithRootViewController:addViewController];
[self.navigationController presentModalViewController:navController
animated:YES];
是否有这样的功能性原因？如果我们只是将addViewController推送到self.navigationController，它会起作用吗？
通常您使用模态视图控制器将用户的注意力集中在任务上。当你推动时，用户处于某种导航流程中，但总体应用程序仍处于触手可及的状态。他们可能会决定前进还是后退，切换到中间的其他选项卡，无论如何。当他们得到一个模态视图控制器时，他们不能做任何事情，直到任务完成或取消（模态视图被解除）。
请参照why does this code use presentModalViewController? (not pushViewController)也
是的，有指导方针。该iOS Human Interface Guidelines说：
使用模式的看法，当你需要 报价来完成与您 应用程序的主要功能 自足任务的能力。 A 模态视图特别适合用于多步骤子任务 需要 UI元素不属于 主应用程序用户界面所有 的时间。
他们还表示，“交模态任务偶尔和简单”：
如果可能的话，尽量少的人必须是一个模式 环境 次数来执行任务或 供应响应。 iOS应用程序 应该允许人们以非线性的方式与他们交互 。 Modality 通过中断 人的工作流程并强制他们选择特定的路径来阻止这种自由。
模式是最合适的：
这是重要的是获得了用户的 关注。必须完成 （或明确放弃）的任务，以避免 将用户数据留在不明确的状态。人们赞赏 能够在模态 视图中完成 自包含子任务，因为上下文转移清晰且临时性为 。但是如果 子任务太复杂，人们可以忽略它们在进入模态 视图时暂停的主要任务。当模式视图为全屏并且其 包括多个从属视图或 状态时，此风险会增加。
保持模态任务相当短，并且 狭隘地集中。您不希望您的 用户在 应用程序中体验作为 迷你应用程序的模态视图。特别要警惕 创建一个涉及 视图层次结构的模态任务，因为人们可能会迷失，并忘记如何回溯其步骤 。如果模态任务 必须在不同的视图中包含子任务，则必须为 确保为用户提供单一的清除 通过层次结构的路径，并避免 循环。
总是提供一个明显而安全的方式 退出模态任务。人们应该总是能够预测他们在工作时的命运，当他们解雇模态 视图。
如果任务需要的 模式视图的层次结构，请确保您的用户 明白，如果他们在这下面的 顶级视图点击一个 完成按钮会发生什么。检查任务以决定 下级 视图中的“完成”按钮是否应完成任务或整个任务的该视图的 部分。 如果可能，请避免将Done 按钮添加到从属视图，因为 这种潜在的混淆。
从苹果文档
模态视图控制器提供了有趣的方式来管理你的应用程序的流程。最常见的情况是，应用程序使用模态视图控制器作为临时中断，以便从用户获取关键信息。但是，您也可以使用模态呈现的视图控制器在特定时间为应用程序实现备用接口。