在下图所示的app中,我目前正在使用三个UIViewControllers:一个主视图控制器,一个用于主菜单,另一个用于主菜单启动的设置屏幕。随着我对UIViewController如何工作以及它的设计方式有了更多的了解,我正在质疑我的架构的智慧。
在我看来,子类化的要点是能够覆盖在控制器生命周期中自动调用的方法:viewDidAppear,viewWillAppear,willRotateToInterfaceOrientation等。看来这些方法只在调用时调用UIViewController(或子类)是UIViewController层次结构的一部分。因此,除非我打算使用创建视图控制器层次结构的标准方法之一,即UINavigationController,[UIViewController presentModalViewController]等,否则继承UIViewController是没有意义的。
我担心使用Cocoa风格的方法将视图控制器添加到层次结构中,因为它们似乎都非常严格。例如,我可以使用[UIViewController presentModalViewController]显示我的设置屏幕,但我不希望它模糊整个屏幕。有背景动画,我希望用户即使在设置屏幕可见时也能够进行交互。
以下是我的问题:
1)除非我要通过Apple的一种技术将它添加到viewController层次结构中,否则继承UIViewController是否愚蠢?
2)我是否正确地假设显示新视图的内置方式对我来说过于严格,为了获得我想要的灵活性,我将需要通过[view]加载视图addSubview]
3)如果UIViewController的子类化对我的菜单和设置视图没有意义,那么我应该如何避免将所有代码放在一个怪物UIViewController子类中。我应该只是NSObject的子类,添加适当的IBOutlets和IBActions,并在使用[NSBundle loadNibNamed]加载nib时将其作为文件所有者传递?
答案 0 :(得分:5)
好问题。首先,一个清晰点:你所谓的“Apple的技术之一”在UIViewController Programming Guide中称为“间接表示”,包括模态表示,被推入导航堆栈,呈现基本上所有这些视图控制器方法都被认为是“间接”表示方法,而-addSubview :(类似[someView addSubview:myViewController.view]
)的使用被认为是“直接”表示。
来自编程指南:( Giant Block Quote ...)
建议您仅使用 建议的技术 显示您的视图的视图 控制器。为了呈现和 正确管理视图,系统 记下每个视图(及其视图) 相关的视图控制器)你 直接或间接显示。它 稍后使用此信息进行报告 查看与您相关的控制器相关事件 应用。例如,当 设备方向改变,一个窗口 使用此信息来识别 最前面的视图控制器和通知 它的变化。如果你加入了 查看控制器的视图到您的 通过其他方式的层次结构(通过添加它 作为其他观点的子视图 也许),系统假定你想要 自己管理视图和做 不向相关联的人发送消息 查看控制器对象。 (强调我的)
除了你设置你的 应用程序的初始界面,大多数 其他观点间接呈现 通过他们的视图控制器对象。
如果您只是直接将视图添加到视图层次结构中,并且不采取其他进一步操作(关键窗口是例外),那么您认为所有这些UIViewController消息都将被浪费是正确的。该引述还提到最常见的是使用间接表示。
1)我毫不犹豫地发表一句话并说“是的,在所有情况下,除非你间接地提出它,否则将UIViewController子类化是愚蠢的。”我确信在某个地方有一些很好的用途。我很乐意说我个人从未这样做过。
2)当然,我不会在这里使用UIViewController子类。
3)请允许我将您的注意力转向“编程指南”的另一个领域:
在iPhone应用程序中,视图中的一个 视图层次结构传统上涵盖了 整个屏幕...如果你想分裂 视图层次结构为多个 分区和管理每一个 单独使用通用控制器 对象(自定义对象降序 来自NSObject)而不是视图 控制器对象来管理每个 分区。然后使用单个视图 控制器对象来管理 通用控制器对象。
这很清楚地与你想要在这里做的事情同步。你自己建议的方法已经死了。 “主菜单启动的设置屏幕”应该由NSObject下降的通用控制器对象管理,而NSObject又由全屏UIViewController子类管理。