Używam UITableView z komórkami statycznymi. Jeśli używam reloadData, to wszystko jest w porządku.UITableView reloadRowsAtIndexPaths ukrywa wiersz
Jeśli spróbuj reloadRowsAtIndexPaths ukrywa wiersz. Wiersz pojawia się, gdy przeciągam tableView góra-dół (gdy komórka jest aktualizowana).
Miałem ten sam problem, wydaje się, że jest to błąd. Niektóre eksperymentowałem, a problem nie występuje, gdy ustawię opcję animacji na UITableViewRowAnimationNone. Inne interesujące rzeczy zdarzają się, gdy ustawisz tę opcję na UITableViewRowAnimationTop.
Jeśli komórki tabeli są statyczne (tzn. Używasz tego samego obiektu komórki do zastąpienia tego, który jest aktualnie wyświetlany), to, co widzisz, jest artefaktem animacji przejścia.
Pomyśl o tym w ten sposób. Powiedzmy, że ustawiłeś UITableViewAnimationOptionFade. Kiedy komórka ma zostać zastąpiona, komórka, którą ma zastąpić (która w tym przypadku jest dokładnie tym samym obiektem) ma dodaną animację wejścia. Następnie zastępowana komórka (znowu to ten sam obiekt) ma dodaną animację zaniku. Na końcu komórka rzeczywiście istnieje, ale jest niewidoczna, ponieważ zanikająca animacja spowodowała, że obiekt komórki stał się niewidoczny.
W niestatycznym widoku tabelowym, w którym komórka zastępcza jest innym obiektem niż komórka, która ma zostać zastąpiona, nie stanowi to problemu, ponieważ animacje są dodawane do dwóch różnych obiektów.
Nie wiem, w jaki sposób struktura/zalecany wzorzec może zapewnić, że komórki będą w rzeczywistości inne. Czy nie ma możliwości, aby 'dequeueReusableCellWithIdentifier' zwrócił tę samą komórkę do ponownego wykorzystania, z której jest ukryta? Wydaje mi się, że Apple powinien właśnie naprawić ten błąd. Nie ma powodu, dla którego nie będzie w stanie obsłużyć obu scenariuszy za pomocą prostego sprawdzenia, czy nowa komórka == stara komórka. – devios1
Nie ma mowy, żebym znalazł. Zgaduję radar. – leftspin
Niezłe wyjaśnienie. Jakie byłoby zatem rozwiązanie? – Josh
i .... gdzie i kiedy to ustawisz? – Josh
Jeszcze nie naprawione. Dziękuję Ci. – Maik639