2013-08-23 8 views
12

Mam Tableview i określić wysokość dla każdej komórki, stosując metodę delegata tableView:heightForRowAtIndexPath:.autoLayout Błąd UITableView

Kiedy obrócić widok dostaję ten błąd, że nie bardzo rozumiem.

To nie może spełnić ograniczenie poniżej i łamie go, aby kontynuować.

"<_UIScrollViewAutomaticContentSizeConstraint:0x8e8d040 UITableView:0x9423400.contentHeight{id: 213} == -1568.000000>" 

Czy ktoś wie, co się dzieje i dlaczego łamie to ograniczenie?

Odpowiedz

1

Spróbuj debugowania implementacji

(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath

. W moim przypadku zwrócił liczbę całkowitą ujemną w niektórych rzadkich przypadkach, w wyniku czego komunikat pojawia się w moim dzienniku i zakłóca działanie przewijania mojego widoku tabeli.

12

tl; dr: Poszukaj wartości rzeczywistej wysokości drastycznie odmiennych niż co szacuje. Lub rzeczywiste wartości, które są ujemne lub 0.


Właśnie spędziłem kilka minut na debugowaniu tego wyjątku ograniczenia. Mam UITableView z komórkami, nagłówkami sekcji i stopkami sekcji. Każdy z nich miał zdefiniowane komunikaty iOS 7 estimatedHeightFor, zwracając wartość static const. Usunąłem komórki, nagłówki i stopki, po jednym na raz, aż stwierdziłem, że problem pochodzi ze stopki (nie ważne, jeśli nie masz stopek, przeczytaj dalej).

Gdybym wyeliminowane estimatedHeightForFooterInSection: wyjątek zniknął. W moim heightForFooterInSection: istnieje jedna ścieżka, w której wysokość stopki będzie wynosić 0. Po przywróceniu wiadomości estimatedHeight i usunięciu ścieżki kodu dla faktycznej wysokości 0, wyjątek również zniknął. Zastąpiłem 0 z 22 i zmniejszyłem tę wartość aż do 12, zanim ponownie pojawił się wyjątek.

Niezależnie, muszę wysokość stopki być 0 (wrócę nil z viewForFooterInSection: w tym przypadku) i chcę, aby być w stanie oszacować wysokość (popieram tekst dynamiczny). Moim rozwiązaniem było uwzględnienie ścieżki kodu, która dałaby mi 0 wysokość w. Po dodaniu tego wyjątek odszedł.

16

AKTUALIZACJA: Ten problem nie jest już istotny w systemie iOS 8, który dodaje obsługę samokierowania komórek. Wciąż jednak dotyczy to iOS 7.

Original odpowiedź (iOS 7):

odpowiedź Grega pewno pracował dla mnie - ja potrzebowałem do debugowania mojego Tableview: estimatedHeightForRowAtIndexPath: metody.Zrobiłem kilka błędów oraz kilka szybkich eksperymentów i tutaj są pewne rzeczy nauczyłem:

  1. Nie używają UITableViewAutomaticDimension oszacowanych rzędowych metod. Ta stała jest dla metod nagłówka i stopki. Wydaje mi się, że nie zwracałem wystarczającej uwagi, gdy czytałem dokumentację :) UPDATE: UITableViewAutomaticDimension można teraz używać do zwiększania rzędów w systemie iOS 8, który jest częścią funkcji samokwizyjnych komórek.

  2. Oszacowanie wysokości wiersza równej 1,0 powoduje wystąpienie wyjątku: "NSInternalInconsistencyException", powód: "wysokość wiersza widoku tabeli nie może być ujemna ..." "Szacowanie wartości mniejszej niż 1,0 powoduje również dziwne wyniki.

  3. Oszacowanie między 2,0 a faktycznymi utworami jest w porządku bez żadnych wyjątków (chociaż 2.0 jest prawdopodobnie złym wyborem z powodów optymalizacji - chcesz być jak najbardziej zbliżony do rzeczywistego).

  4. Wyjątek ograniczenia występuje tylko wtedy, gdy szacowana wysokość rzędu jest większa niż rzeczywista wysokość wiersza. Im bliżej jesteś rzeczywisty, tym mniej prawdopodobne jest wystąpienie wyjątku. Jak daleko może się zdarzyć twój szacunek przed uzyskaniem wyjątku wydaje się być związany z kilkoma różnymi czynnikami: rzeczywistą wysokością wiersza, pozycją wiersza, itp.

+0

+1 dla numeru 4. FWIW ten wyjątek ograniczenia występuje w iOS 7, ale nie w 8. –

+0

@RichardShin Dzięki za notatkę. Zaktualizowałem swoją odpowiedź, aby powiedzieć, że funkcjonalność bardzo się zmieniła w systemie iOS 8. –

+0

Drugi przypadek to rzeczywisty problem, aż do systemu iOS 10 włącznie. Zostało to naprawione w iOS 11. Szybki przykład: https://github.com/OlesyaS/UITableView-ios10-crash/blob/master/table/ViewController.m –