Ошибка автоопределения с помощью UITableView
У меня есть TableView, и я указываю высоту для каждой ячейки, используя метод делегата tableView:heightForRowAtIndexPath:
.
Когда я поворачиваю представление, я получаю эту ошибку, которую я не совсем понимаю.
Он не может удовлетворить ограничение ниже и разрывает его, чтобы продолжить.
"<_UIScrollViewAutomaticContentSizeConstraint:0x8e8d040 UITableView:0x9423400.contentHeight{id: 213} == -1568.000000>"
Кто-нибудь знает, что происходит и почему я нарушаю это ограничение?
Ответы
Ответ 1
ОБНОВЛЕНИЕ. Эта проблема больше не актуальна в iOS 8, что добавляет поддержку ящиков для самостоятельной калибровки. Это все еще актуально для iOS 7.
Оригинальный ответ (iOS 7):
Ответ Грега определенно сработал у меня - мне нужно было отладить мой метод tableView: measuredHeightForRowAtIndexPath:. Я сделал некоторые отладки и некоторые быстрые эксперименты, и вот некоторые вещи, которые я узнал:
-
Не используйте UITableViewAutomaticDimension в оцененных строках. Эта константа предназначена для методов верхнего и нижнего колонтитулов. Думаю, я не уделял достаточного внимания, когда читал документацию: UPDATE: UITableViewAutomaticDimension теперь можно использовать для высот строк в iOS 8, являющейся частью функциональных возможностей саморазмера.
-
Оценка высоты строки 1.0 приводит к исключению: "NSInternalInconsistencyException", причина: "высота строки таблицы не должна быть отрицательной..." "Оценка менее 1.0 также имеет странные результаты.
-
Оценка между 2.0 и фактическими работами прекрасна без каких-либо исключений (хотя 2.0, вероятно, является плохим выбором по соображениям оптимизации - вы хотите быть как можно ближе к фактическому).
-
Исключение ограничения происходит только тогда, когда высота height превышает высоту строки. Чем ближе вы к фактическому, тем меньше вероятность того, что произойдет исключение. Как далеко может быть ваша оценка до получения исключения, похоже, связано с несколькими различными факторами: фактическая высота строки, позиция строки и т.д.
Ответ 2
tl; dr: найдите значения фактические значения, сильно отличающиеся от того, что вы оценили. Или фактические значения отрицательные или 0
.
Я потратил несколько минут на отладку этого исключения ограничений. У меня есть UITableView
с ячейками, заголовками разделов и нижними колонтитулами раздела. В каждом из них были определены сообщения iOS 7 estimatedHeightFor
, возвращающие значение static const
. Я удалил ячейки, заголовки и нижние колонтитулы, по одному за раз, пока не определил, что проблема исходила из нижнего колонтитула (не важно, если у вас нет нижних колонтитулов, пожалуйста, прочитайте).
Если я исключил estimatedHeightForFooterInSection:
, исключение исчезло. В моем heightForFooterInSection:
есть один путь, в котором высота нижнего колонтитула будет 0
. Когда я восстановил сообщение estimatedHeight
и исключил путь кода для фактической высоты 0
, исключение также исчезло. Я заменил 0
на 22
и уменьшил это значение до 12 до того, как возникло исключение.
Независимо от того, мне нужен высота нижнего колонтитула 0
(в этом случае я возвращаю nil
из viewForFooterInSection:
), и я хочу иметь возможность оценить высоту (поддерживаю динамический текст). Моим решением было учесть путь кода, который дал бы мне высоту 0
в estimatedHeightForFooterInSection:
. Как только я добавил, исключение исчезло.
Ответ 3
Попробуйте отладить
(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
реализация. В моем случае он возвращал отрицательное целое число в некоторых редких случаях, в результате чего сообщение появилось в моем журнале и возилось с прокруткой поведения моего представления в таблице.