【问题标题】:Why Table Views (UITableView) have to have standalone source object that provide them data?为什么表视图 (UITableView) 必须具有为它们提供数据的独立源对象?
【发布时间】:2014-03-09 13:17:30
【问题描述】:

我想知道为什么所有的 Table Views(也在 Android 中)都必须有特殊的对象来为它们提供数据?

https://developer.apple.com/library/ios/documentation/uikit/reference/UITableView_Class/Reference/Reference.html#//apple_ref/occ/instp/UITableView/dataSource

为什么不能从控制器(或 Android 的 Activity 类)填充表视图?

例如,iOS 中的 UILabel 可以通过设置“text”属性来填充

https://developer.apple.com/library/ios/documentation/uikit/reference/UILabel_Class/Reference/UILabel.html#//apple_ref/occ/instp/UILabel/text

您能解释一下这种设计的目的是什么吗?

【问题讨论】:

    标签: android ios iphone objective-c uitableview


    【解决方案1】:

    这是一个非常好的问题。

    我们可以将其分为两个原因 - 一个普遍的原因和一个常见的具体原因。

    不过,首先,请注意它还不止于此。一个UITableView 可以有两个 委托控制器对象,一个UITableViewDataSourceDelegate 和一个UITableViewDelegate。第一个提供数据;第二个响应对显示数据采取的操作。为什么会有所有这些抽象层?为什么不直接把它贴在UIViewController

    名称“UIViewController”暗示了不这样做的一般原因。它旨在控制视图。在 iOS 中,我希望在 android-land 中,有一种强烈的诱惑只是“将它粘在视图控制器中”——导致非常大的视图控制器反模式,你可以阅读很多内容(例如 here)。

    对于维护和组织视图控制器来布置视图和处理按钮按下,以及其他一些控制器对象来处理定义良好且真正完全独立的提供数据的责任,这要好得多。

    拥有某种对象来处理数据并不罕见——购物车或房地产属性列表等——它封装了额外的业务逻辑(例如,提供小计),但基本上已经“拥有”数据。在这种情况下,提供一个类别或轻量级控制器,可以在该数据和表视图之间“桥接”,并在视图控制器之间传递模型对象而不是数组。

    具体来说:在 iOS 中,我们有 NSFetchedResultsController 之类的东西。这是一门很棒的课程,它为您进行了大量的数据排序、分页、添加、删除、切片、切块、折叠、旋转和切割——它还母语为UITableView 的语言。传递其中一个,您可以保持视图控制器干净整洁,并与数据分开。

    【讨论】:

      【解决方案2】:

      TableView 确实需要一个特殊的或单独的对象,但它们确实需要一个对象实现正确的协议,以便它可以找到数据。在 Apple 的默认实现中,它使用一个新对象 UTableViewCotnroller 来响应这些方法以及执行一些其他操作,例如使 UITableView 成为视图控制器的根视图。

      如果您出于某种原因不想使用该对象,您仍然可以手动将 UITableView 添加到视图控制器,然后将其委托设置为视图控制器。尽管如果可能的话,最好将它移出视图控制器,以帮助保持视图控制器的小型化和数据的可重用性。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2012-09-08
        • 1970-01-01
        • 2016-07-06
        • 1970-01-01
        相关资源
        最近更新 更多