你能想到 Apple 选择将 UIPopoverController 实现为普通 NSObject 子类的特殊原因吗?对我来说,一个 UIViewController 子类会更有意义,以实现适当的 UIViewController 包含。
但也许有我没有想到的原因,为什么苹果的聪明工程师做出了他们的选择?
你能想到 Apple 选择将 UIPopoverController 实现为普通 NSObject 子类的特殊原因吗?对我来说,一个 UIViewController 子类会更有意义,以实现适当的 UIViewController 包含。
但也许有我没有想到的原因,为什么苹果的聪明工程师做出了他们的选择?
我认为这是因为,就像 UIAlertView 一样,它呈现在一个新的 UIWindow 中,所以 windowLevel 属性保证它呈现在所有内容上。
无论它是否在新的 UIWindow 中,就视图控制器的包含而言,在 UIPopoverController 中显示的视图控制器中使用复杂的父子视图控制器容器层次结构应该没有问题。对于某些弹出框,我在Pillboxie中有至少三层嵌套的视图控制器,没有任何问题。
更新:我通过在示例项目中记录视图层次结构的前三个级别的类来检查层次结构,当弹出框可见时如下所示(我的根视图控制器有两个 UIButtons):
一个窗口:
_SUBVIEW 类:UIView
___SUBSUBVIEW 类:UIRoundedRectButton
_ _SUBSUBSUBVIEW 类:UIButtonLabel
___SUBSUBVIEW 类:UIRoundedRectButton
_ _SUBSUBSUBVIEW 类:UIButtonLabel
_SUBVIEW 类:UIDimmingView
___SUBSUBVIEW 类:_UIPopoverView
_ _SUBSUBSUBVIEW 类:_UIPopoverStandardChromeView
_ _SUBSUBSUBVIEW 类:UIView
Apple 的文档指出,UIWindow 中的根视图控制器的视图不应有由其他视图控制器管理的同级视图,因为这些同级视图控制器不会接收旋转事件(参见此处,第二个项目符号)。
因此,如果 Apple 将 UIPopoverController 设为 UIViewController 子类,则必须将其添加为 rootViewController 层次结构的子视图/子视图。但是,如果根视图控制器(无论如何都是您的代码)决定呈现一个干扰 UIPopoverController 视图层次结构的视图怎么办?Apple 似乎决定完全管理 UIPopoverController 的呈现,而不是让我们搞砸它,但他们不必为 UIWindow 的 no-sibling-view-controllers 政策授予例外。
因为UIPopoverController
对象不与用户交互,这就是为什么它不是视图层的一部分,你UIViewController
能够与用户通信,UIPopoverController
它本身不做任何类似的工作。
快速浏览一下Controller的通用定义:
控制器可以向其关联视图发送命令以更改视图对模型的表示(例如,通过滚动文档)。它可以向模型发送命令以更新模型的状态(例如编辑文档)。
它解释了为什么它不是视图层的一部分,我希望它有所帮助。