Предположительно, оценкаHeightForRowAtIndexPath может изменить окончательную "правильную" высоту строки?

Я только что обнаружил поразительную проблему или поведение против интуиции при использовании метода оценкиHeightForRowAtIndexPath

(1) Моя таблица имеет невероятно разные высоты. Конечные результаты могут варьироваться от 111 до 400.

(2) Я абсолютно отлично вычисляю каждую высоту строки. Я имею эти под рукой в ​​массив, то есть кешированный.

{Обратите внимание, что это именно то, что, по-видимому, сейчас рекомендуют инженеры Apple... пример, пункт 5.. Использование автоматической компоновки в UITableView для динамических раскладок ячеек и высоты строк в строке}

(3) Когда heightForRowAtIndexPath запрашивает высоту, я даю ей абсолютно правильную высоту.

(4) Когда я строю ячейку, я построил ее точно на правильной высоте (как в (2) и (3)).

{Обратите внимание - конечно, это iOS, который, наконец, определяет высоту ячейки, а не "меня".}

ЭТО ВСЕ РАБОТЫ СОВЕРШЕННО.

т.е. каждая ячейка построена iOS точно на высоте, заданной в heightForRowAtIndexPath.

Теперь я добавляю код...

-(CGFloat)tableView:(UITableView *)tableView
    estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return 120;
}

В ФАКТЕ, ТАБЛИЦА НЕТ БОЛЬШИХ РАБОТ.................. ВЫСОТА СКОРОСТИ СТАНОВИТСЯ СЛУЧАЙНО!!!

ЛЮБОЕ ВИДЕТЬ ЭТО НЕПРЕРЫВНОЕ ПОВЕДЕНИЕ?

Я сделал различные тесты, чтобы попытаться определить взаимосвязь того, что, по-видимому, оценилHeightForRowAtIndexPath. Сначала я подумал, что это может обеспечить нижнюю границу высоты. Итак, 150... даже мои меньшие ячейки будут неправильно иметь высоту 150. Но это не так.

Я думаю, что МОЖЕТ делать что-то вроде этого: скажем, ваше оценочное значениеHeightForRowAtIndexPath равно 150. Иногда он использует 150 для строк, которые (фактически() оказываются такими или меньше, но иногда это происходит для реального размера heightForRowAtIndexPath.

С другой стороны, если вы ввели значение для оценочногоHeightForRowAtIndexPath, которое меньше, чем когда-либо существовало (скажем, 100 в моем примере), он в значительной степени "совершенно не работает", вы просто получаете то, что может показаться случайные высоты на клетках.

очень высокие ячейки, похоже, работают правильно, возможно, что-то вроде "если высота от heightForRowAtIndexPath удваивается, то она использует реальную высоту"

Чтобы быть ясным, кажется, что он никогда не делает ячейку слишком маленькой, но она часто делает их слишком большими.

Чтобы быть ясным, я не, используя autolayout, это тип ячейки, которую нужно просто создать. (Боюсь, я понятия не имею, как это происходит с автозапуском.) Это только Xcode5/iOS7 +.

Ответы

Ответ 1

Обновленный ответ

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

Оригинальный ответ

Это просто требует автоматической компоновки. Не удивительно, правда, но должно быть абсолютно документировано.

Вот рабочий проект, демонстрирующий корректную работу tableView:estimatedHeightForRowAtIndexPath: с Auto Layout. Если вы отключите автоматическую компоновку в раскадровке, она будет вести себя так, как вы описали.

Оценочная демонстрация высоты строки

Ответ 2

- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath { }

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

Для exmaple: если у вас есть 100 ячеек с каждой высотой от 200 до 300 (например, 201, 207, 250, 299, 300...), вы можете оценить высоту ячейки около 250. Т.е.

- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
return 250;
}
  • Предоставление оценки высоты строк может улучшить пользовательский интерфейс при загрузке представления таблицы.
  • Если этот делегат не реализован, может быть дорого рассчитать все их высоты и, следовательно, привести к более длительному времени загрузки.