dequeueReusableCellWithIdentifier:forIndexPath:的indexPath在哪里使用?

Jer*_*man 40 uitableview ios ios6

Apple的文档说明了indexPath参数:

索引路径指定单元格的位置.数据源在被要求提供单元格时会收到此信息,并且应该将其传递给它.此方法使用索引路径根据单元格在表视图中的位置执行其他配置.

register(Class|Nib):forCellReuseIdentifier:仅指定要使用的重用标识符,而不是指定段或一组索引路径.

我想也许UITableViewCell有一些方法可以把它放在索引路径上,所以如果在一个部分的第一行,它可以绕过它的角,但是我没有看到它.在创建时,它获得的只是它的样式和重用标识符(initWithStyle:reuseIdentifier:); 在重用时,所有它被告知是prepareForReuse.

看到旧dequeueReusableCellWithIdentifier:的仍然受到支持,如果它不能依赖有机会这样做,它可能会采取什么样的基于索引路径的配置呢?

我检查了表视图编程指南,但自iOS 5以来它没有更新.

mat*_*att 40

之间最重要的区别dequeueReusableCellWithIdentifier:,并dequeueReusableCellWithIdentifier:indexPath:为他们不同的方法!因此,他们可以表现得不同,他们也可以.这与indexPath无关,真的; 我们只需要一种方法来区分它们.

新方式

特别是,如果你打电话dequeueReusableCellWithIdentifier:indexPath:,这表明你正在使用新的iOS 6注册和出队系统.因此,如果您未能注册此标识符,您将收到一个很好的崩溃和一条解释该问题的日志消息.这种方法永远不会返回零; 它总是返回一个单元格,通过创建一个单元格或重用一个单元格.

旧路

另一方面,简单和简单dequeueReusableCellWithIdentifier:是旧的,必须向后兼容.如果你还没有注册这个标识符,它就不会抱怨:它只会返回nil,让你保持高度干燥.您将不得不自己创建单元格,就像过去的糟糕日子一样.

编辑:但请参阅@svena的答案!新方式(with indexPath:)具有我不知道的第二个优点:单元格在返回给你时尺寸正确.

  • @matt我说如果你检查两种方法返回的cell.contentView.bounds.以indexPath作为参数的版本将返回已设置(已知)实际宽度和高度的单元格,并且可以对该contentView中的子视图进行次要布局更改. (2认同)

sve*_*ena 36

根据WWDC 2012第200节 - 可可触摸的新功能,

如果您使用- dequeueReusableCellWithIdentifier:forIndexPath:单元格出列,它将是正确的大小,您将能够在单元格中进行布局contentView.

这几乎是来自UIKit工程师Chris Parker的引用.

在iOS 6之前,如果要进行布局调整,则必须对子类进行子类化UITableViewCell并覆盖- layoutSubviews.从封装的角度来看,这可能仍然是更好的解决方案 - 但是,有时你只需要一个微小的调整,现在你可以做到这一点- tableView:cellForRowAtIndexPath:.

  • 在iOS6之前,您必须继承UITableViewCell并覆盖-layoutSubviews.从封装的角度来看,这可能仍然是更好的解决方案,但有时你只需要一个微小的调整和子类,只有那可能是很重的. (2认同)