我正在做 iPad 技术演示，但遇到了严重的技术问题。
我有一个利用 UISplitViewController 的应用程序概念，但不作为整个应用程序的主 Controller 。
应用程序流程可以大致描述如下:
主屏幕(UIViewController) 列表->详细信息“目录”(UISplitViewController) super 细节屏幕(UIViewController，但也可以想象是 SplitView 的子级)。
问题出在主页和目录之间的流程中。一旦将 UISplitViewController View 添加到 UIWindow，它就会开始发出嘶嘶声。
问题可以概括为:
当 UISplitView 生成弹出 View 时，它似乎被锁定到其父 View 。从 UIWindow subview 中删除 UISplitView 后，您将收到 CoreGraphics 异常，并且该 View 将无法删除。
当添加其他 View 时(大概是您要返回的主屏幕)，它们不会自动旋转，而是由于 CG 异常而未能删除的 UISplitView 继续响应相反，会导致可怕的渲染错误，无法仅“处理”。此时，添加任何 View ，甚至重新添加 SplitView，都会导致一系列渲染错误。
然后，我尝试简单地将 SplitView 保留为“底部” View ，并不断在其顶部添加和删除主屏幕，但这会失败，因为 SplitView 主导方向更改调用，而主屏幕不会旋转，即使您调用 [homeScreen comeFirstResponder]
您不能将 SplitView 放入像 UINavigationController 这样的层次结构中，您将得到一个彻底的运行时错误，因此该选项不可行。模态框看起来很糟糕并且无论如何都不鼓励。
我现在的假设是，处理这个问题的唯一正确方法是以某种方式“解除”UISplitViewController，以便可以将其从其父 View 中删除而不会引发未处理的异常，但我不知道如何。
如果您想查看一款完全满足我需要的应用程序，请查看 iPad 应用程序商店中的 GILT Groupe。他们成功了，但他们似乎已经编写了整个自定义 View 转换集。
非常感谢您的帮助。
最佳答案
苹果states :
The split view controller’s view should always be installed as the root view of your application window. You should never present a split view inside of a navigation or tab bar interface.
这确实意味着它应该是 Root View 而不是另一个 View 的 subview 。即使他们添加:
You should never present a split view inside of a navigation or tab bar interface
这并不意味着您可以将其添加为任何其他 Controller 的 subview 。 (抱歉)
我有一种感觉，你所经历的事情是尝试这样做的副产品。事实上，令我惊讶的是 GILT Groupe 的应用程序没有被拒绝。 Apple 最近倾向于相当严格地执行这些 HIG 准则。当您尝试将它们添加到 NavigationController 时，它们(正如您已经发现的那样)会导致相当严重的运行时错误。
关于iphone - UISplitViewController 和复杂的 View 层次结构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2640225/