Где используется indexPath dequeueReusableCellWithIdentifier: forIndexPath: использовать?

Документация Apple описывает параметр indexPath:

Путь указателя, определяющий местоположение ячейки. Источник данных получает эту информацию, когда запрашивается ячейка, и должен просто передать ее. Этот метод использует индексный путь для выполнения дополнительной конфигурации на основе позиции ячеек в представлении таблицы.

Но register(Class|Nib):forCellReuseIdentifier: указывает только используемый идентификатор повторного использования, а не раздел или набор указательных путей.

Я подумал, что, возможно, UITableViewCell имел некоторый способ добраться до указательного пути, поэтому он мог бы, скажем, обойти его углы, если в первой строке раздела, но я этого не вижу. Во время создания все, что он получает, это его идентификатор стиля и повторного использования (initWithStyle:reuseIdentifier:); во время повторного использования все, что ему говорят, это prepareForReuse.

Увидев, что старый dequeueReusableCellWithIdentifier: по-прежнему поддерживается, какая конфигурация на основе индексирования может быть выполнена, если он не может полагаться на возможность сделать это, во всяком случае?

Я проверил руководство по программированию таблиц, но он не обновлялся с iOS 5.

Ответы

Ответ 1

В соответствии с WWDC 2012 Сессия 200 - Что нового в Cocoa Нажмите,

Если вы используете - dequeueReusableCellWithIdentifier:forIndexPath: для удаления вашей ячейки, это будет правильный размер, и вы сможете сделать макет внутри своей ячейки contentView.

Это в значительной степени цитата из Криса Паркера, инженера UIKit.

До iOS 6 вам нужно было подклассифицировать UITableViewCell и переопределить - layoutSubviews, если вы хотите выполнить настройку макета. С точки зрения инкапсуляции это все равно может быть лучшим решением - однако иногда вам просто нужна крошечная настройка, и теперь вы можете сделать это в - tableView:cellForRowAtIndexPath: вместо этого.

Ответ 2

Самое важное отличие между dequeueReusableCellWithIdentifier: и dequeueReusableCellWithIdentifier:indexPath: заключается в том, что они разные методы! Таким образом, они могут вести себя по-другому, и они это делают. На самом деле это не имеет никакого отношения к indexPath; нам просто нужен способ их отличить.

Новый способ

В частности, если вы вызываете dequeueReusableCellWithIdentifier:indexPath:, это знак того, что вы используете новую систему регистрации и удаления iOS 6. Таким образом, если вы не смогли зарегистрировать этот идентификатор, вы получите хороший сбой и сообщение в журнале, объясняющее проблему. Этот метод никогда не вернет нуль; он всегда возвращает ячейку, создавая новую или повторно используя ее.

Старый путь

С другой стороны, простой и простой dequeueReusableCellWithIdentifier: является старым и должен быть обратно совместимым. Если вы еще не зарегистрировали этот идентификатор, он не будет жаловаться: он просто вернет ноль, оставив вас высоко и сухо. Вам нужно будет создать ячейку самостоятельно, как в старые добрые времена.

РЕДАКТИРОВАТЬ: Но см. также ответ @svena! Новый способ (с indexPath:) имеет второе преимущество, о котором я не знал: ячейка имеет правильный размер в то время, когда она возвращается вам.

Ответ 3

Я полагаю, что он используется для вызова метода tableView:heightForRowAtIndexPath:, если таковой существует, позволяя ячейке иметь правильный размер.

Ответ 4

Я всегда думал, что UIKit будет вокруг углов верхней и нижней ячеек в сгруппированном представлении таблицы, когда метод UITableViewDelegate:

- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath

. Однако, зная, что путь указателя не очень полезен, если клетка не знает, сколько строк находится в одном разделе, чтобы она могла работать, если она была последней ячейкой или нет.

Я предполагаю, что добавление пути индекса к методу dequeueReusableCellWithIdentifier: заключается в улучшении производительности, возможно, в том, что @jrturton предлагается с различными пулами повторного использования или просто для определения положения ячейки в сгруппированных разделах.

Насколько я помню из видео WWDC, в iOS 6 было добавлено несколько дополнительных методов для поддержки переупорядочения, вставки и удаления ячеек, поэтому, возможно, это также входит в фактор здесь?