为什么UITableViewController不能在Cocoa Touch中管理窗口的一部分?

时间:2010-01-29 03:19:19

标签: iphone cocoa-touch uitableview

我有一个包含UITableViewUILabel的视图,据我所知,它可以完美运行。我真的不想管理UIViewUITableView使用与UITableViewController相同的控制器处理大量的内务管理并根据documentation

  

如果要管理的视图是   复合视图,其中有一个表视图   是必须的,是多个子视图之一   使用自定义子类   UIViewController来管理表   查看(和其他观点)。不要使用   因为UITableViewController对象   此控制器类调整表的大小   查看填充屏幕之间的   导航栏和标签栏(如果   要么就在场。)

为什么Apple警告不要使用它,如果忽略此警告会发生什么?

更新:最初我引用Apple Documentation中的以下内容:

  

您不应该使用视图   控制器来管理填充的视图   只是他们窗户的一部分 - 即   只有部分区域由   应用内容矩形。如果你   想拥有一个由...组成的界面   几个较小的视图,将它们全部嵌入   在单个根视图中并管理它   用你的视图控制器查看。

虽然此问题可能与UITableViewController设计为全屏的原因有关,但问题并非完全相同。

4 个答案:

答案 0 :(得分:7)

每个屏幕仅使用一个视图控制器的主要实际原因是因为这是管理导航的唯一方法。

例如,假设您的屏幕具有两个单独的视图控制器,并使用导航控制器加载它。你推动了哪两个视图控制器,你如何加载和引用第二个? (更不用说同时协调两个独立控制器的开销。)

我认为使用单个自定义控制器并不像你想的那么麻烦。

请记住,不需要将TableviewDataSource和TableViewDelegate放在实际控制器中。 Apple模板只是为了方便起见。您可以将实现这两​​种协议的方法放在一个类中,也可以将它们分别放在自己的类中。然后,您只需将它们与自定义控制器中的表链接起来即可。这样,所有自定义控制器所要做的就是管理tableview本身的框架。所有配置和数据管理都将在独立的自包含对象中。如果您需要来自其他UI元素的数据,自定义控件可以轻松地向它们发送消息。

这种灵活性,自定义和封装是委托设计模式首先使用的原因。您可以自定义任何东西,而无需创建一个可以完成所有任务的怪物类。相反,你只需弹出一个委托模块然后去。

Edit01:对评论的回应

如果我正确理解你的布局,你的问题是UITableViewController是硬连线设置表来填充可用的视图。大多数情况下,tableview是顶视图本身并且有效。 UITableViewController的主要功能是定位表,因此如果您使用的是非标准布局,则不需要它。您可以使用通用视图控制器并让nib设置表的框架(或以编程方式执行)。就像我说的那样,很容易认为委托和数据源方法必须在控制器中,但它们不是。你应该完全摆脱tableViewController,因为它在你的特定设计中没有用处。

答案 1 :(得分:3)

对我而言,Apple文档中的重要细节是他们建议您不要使用“视图控制器 [即UIViewController或其子类的实例]来管理仅填充其部分内容的视图窗口”。将几个(自定义)控制器用于非全屏视图没有任何问题,它们不应该是UIViewController对象。

UIViewController期望它的视图占据整个屏幕,如果没有,你可能会得到奇怪的结果。视图控制器调整视图大小以适应窗口(减去导航栏和工具栏),当它出现时,它管理设备方向(如果视图不占用整个屏幕,则难以正确应用)等。所以给出了UIViewController如何工作,我认为Apple的建议是有道理的。

但是,这并不意味着您无法编写自己的控制器类来管理子视图。除了上面提到的事情,与标签栏和导航控制器交互,以及接收内存警告之外,UIViewController没有那么多。您可以编写自定义控制器类(从NSObject创建子类),在“普通”全屏视图控制器中实例化它,让它处理与您视图的交互。

我看到的唯一问题是响应者链。视图控制器是响应程序链的一部分,因此视图不处理的触摸事件将转发到视图控制器。在我看来,没有简单的方法将自定义控制器放在响应器链中。我不知道这是否与你相关。如果您可以使用目标 - 操作机制管理与视图的交互,则无关紧要。

答案 2 :(得分:2)

我有一个应用程序,我在另一个视图控制器下面使用了2个单独的UIViewController子类来管理表视图和工具栏。它有点'有效',但结果却让我自己变成了一个巨大的泡菜,现在我意识到我不应该为子控制器使用UIViewController子类,因为它们包含我不需要的行为并且会妨碍它。

出现问题的那种事情往往是:

  • 从子导航返回时奇怪调整视图大小,并且viewWillLoad和viewDidLoad等之间的几何计算不同。

  • 当我不应该使用子视图控制器时,难以处理低内存警告。

期望UIViewController子类不会像这样使用,以及它们处理事件的方式,使用导航控制器等使得尝试在同一页面上使用多个UIViewController子类变得棘手,因为你最终花费更多时间绕过他们在这种情况下的行为。

答案 3 :(得分:-3)

在我看来,Apple Way将为您提供“一个”解决方案。这为最终用户提供了很好的服务。别无选择,没有头痛。

我们是程序员,我们想要并且需要定制。但是,在某些情况下,Apple仍然不希望我们做太多改动。例如,标签栏,工具栏和导航栏的高度,UI组件的一些默认大小(表格视图),一些默认行为等。在设计框架和一套API时,他们需要确定一些决定。即使它是一个非常好的和灵活的设计,世界上总有一个程序员想要做一些不同的事情,并且发现很难实现与设计的对比。

简而言之,您希望在同一屏幕上显示表格视图和标签,但他们并不这么认为。 :)