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