UITableView cellForRowAtIndexPath ячейка не ноль, когда ожидается

Question

У меня есть сгруппированный UITableView в моем классе UIViewController, и я обнаруживаю, что время от времени ячейка в удаленном виде не равна нулю, как ожидалось.

В таблице есть 3 раздела для начала, и, как только'viewDidLoad' вызывается, инициируется серверный вызов, чтобы выяснить, есть ли еще разделы.Еще до того, как представление будет обработано, приходит ответ сервера, и нам говорят, что у нас есть 4 раздела.Чтобы справиться с этим изменением, я делаю:

[self.tableview beginUpdates]

// Do the updating of the array that holds table data

[self.tableview endUpdates]
[self.tableview reloadData];

Затем я получаю вызов 'numberOfSectionsInTableView', для которого я возвращаю 4, затем 'numberOfRowsInSection', и я возвращаю ожидаемое правильное количество строк.Обратите внимание, что это первый раз, когда я получаю любой из этих вызовов, так как перезагрузка таблицы произошла так быстро и еще до того, как представление было визуализировано.

На данный момент видны только данные из первых 3-х разделов ипрокрутите для просмотра последнего раздела.Когда вы прокручиваете, чтобы увидеть последний раздел, я ожидаю, что одна из ячеек в вызове tableView: cellForRowAtIndexPath не равна нулю.Тип ячейки - это то, что использовалось для другого раздела (у меня есть один тип UITableViewCell для первых двух секций и другой для последних двух секций, которые я создаю и возвращаю в cellForRowAtIndexPath, когда ячейка равна nil).

Так как же UITableView выясняет, какую ячейку удалять из очереди, и как мне выяснить, почему эта ячейка для этого конкретного раздела / строки не равна нулю, когда она действительно должна быть?

Answer 1

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

Наиболее распространенный подход - привязать идентификаторы повторного использования к классам ячеек. Скажем, если вы используете ячейки класса A для отображения людей из адресной книги и ячейки класса B для отображения организаций, вы, очевидно, не сможете повторно использовать ячейки B для людей и наоборот. В таком случае вы назначаете этим двум классам разные идентификаторы повторного использования, что гарантирует, что когда вам нужно будет предоставить ячейку A, таблица либо выведет из очереди ячейку A, либо вернет nil, если ее пул неиспользуемых ячеек A пуст.

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

Answer 2

Что вы используете для идентификатора своей ячейки?Это то, что UITableView будет использовать при определении того, что удалить из очереди.Если у вас разные типы ячеек, вам понадобятся разные идентификаторы повторного использования.