uiviewcontrollers 应该始终是 viewcontroller 层次结构的一部分吗？

Question

在下图所示的应用程序中，我目前正在使用三个 UIViewController：一个主视图控制器，一个用于主菜单，一个用于由主菜单启动的设置屏幕。随着我更多地了解 UIViewController 的工作原理以及它的设计目的，我在质疑我的架构的智慧。

在我看来，子类化的主要目的是能够覆盖在控制器生命周期中自动调用的方法：viewDidAppear、viewWillAppear、willRotateToInterfaceOrientation 等。看来这些方法只有在以下情况下才会被调用UIViewController（或子类）是 UIViewController 层次结构的一部分。因此，继承 UIViewController 是没有意义的，除非我要使用创建视图控制器层次结构的标准方法之一，即 UINavigationController、[UIViewController presentModalViewController] 等。

我对使用 Cocoa 风格的方式将视图控制器添加到层次结构中持谨慎态度，因为它们似乎都非常具有限制性。例如，我可以使用 [UIViewController presentModalViewController] 显示我的设置屏幕，但我不希望它遮挡整个屏幕。即使设置屏幕可见，我也希望用户能够与之交互的背景动画。

这是我的问题：

1) 继承 UIViewController 是否愚蠢，除非我打算通过 Apple 的一种技术将它添加到 viewController 层次结构中？

2) 我的假设是否正确，即显示新视图的内置方法对我来说太严格了，为了获得我想要的灵活性，我只需要通过 [view添加子视图]

3) 如果子类化 UIViewController 确实对我的菜单和设置视图没有意义，我应该如何避免将所有代码放在一个怪物 UIViewController 子类中。当我使用 [NSBundle loadNibNamed] 加载 nib 时，我是否应该只将 NSObject 子类化，添加适当的 IBOutlets 和 IBActions 并将其作为文件所有者传递？

Answer 1

好问题。首先，明确一点：您所说的“Apple 的技术之一”在 UIViewController Programming Guide 中被称为“间接呈现”，包括模态呈现、被推送到导航堆栈、呈现弹出框控制器等内容等。基本上所有这些视图控制器方法都被认为是“间接”呈现方法，而使用 -addSubview:（类似于[someView addSubview:myViewController.view]）被认为是“直接”呈现。

来自上述编程指南：（Giant Block Quote...）

建议您只使用 建议的技术 显示视图的视图 控制器。为了呈现和 正确管理视图，系统 记下每个视图（及其 关联的视图控制器）你 直接或间接显示。它 稍后使用此信息报告 查看与您的控制器相关的事件 应用。例如，当 设备方向改变，一个窗口 使用此信息来识别 最前面的视图控制器和通知 它的变化。如果你加入一个 查看控制器的视图到您的 通过其他方式的层次结构（通过添加它 作为其他视图的子视图 也许），系统假设你想要 自己管理视图并执行 不向关联的人发送消息 查看控制器对象。 （强调我的）

除了设置您的 应用程序的初始界面，大多数 其他观点是间接提出的 通过他们的视图控制器对象。

也就是说，如果您只是将视图直接添加到视图层次结构中并且不采取其他进一步操作（关键窗口是例外），那么您认为所有这些 UIViewController 消息将被浪费是正确的。该引用还提到使用间接表示是最常见的。

1) 我不愿做出笼统的陈述并说“是的，在所有情况下，继承 UIViewController 是愚蠢的，除非你间接地呈现它。”我敢肯定它在某处有一些很好的用途。我会说我个人从未这样做过。

2) 当然，我不会在这里使用 UIViewController 子类。

3) 请允许我将您的注意力引向编程指南的另一个方面：

在 iPhone 应用程序中，视图中的 视图层次结构传统上涵盖 整个屏幕......如果你想划分 一个视图层次结构成多个 子区域并管理每个区域 单独使用通用控制器 对象（自定义对象降序 来自 NSObject) 而不是视图 控制器对象来管理每个 分区。然后使用单个视图 控制器对象来管理 通用控制器对象。

这很明显与您在这里想要做的事情同步。你已经死在了你自己建议的方法上。 “由主菜单启动的设置屏幕”应由从 NSObject 继承的通用控制器对象管理，而后者又由您的全屏 UIViewController 子类管理。