Использование reloadData в качестве страхового полиса для UITableView

Question

У меня довольно сложный источник данных для моего UITableView.Я очень тщательно синхронизирую его с самой таблицей, вставляя и удаляя строки / секции вручную (с анимацией) всякий раз, когда некоторые данные меняются, и наоборот.

Трудно быть на 100% уверенным в своих способностяхчтобы они соответствовали.Последствия несоответствия между представлением и данными могут быть серьезными - например, выбор строки и попытка сделать что-то для связанного объекта, когда этот объект не существует, вызовет сбой.Многие другие ошибки могут привести к менее очевидным ошибкам (например, при работе с неправильным объектом).

Я думал о том, как все это исчезнет, ​​если я буду вызывать reloadData после каждого изменения данных вместо того, чтобы вручную изменять представление,Но тогда я бы потерял анимацию.

Так что, возможно, я мог бы как-то вызвать reloadData после , когда мои анимации закончились, в качестве меры безопасности.

• Озвучивает ли это звук?как хорошая идея?Какие-нибудь альтернативы?
• Где бы я мог разместить этот вызов так, чтобы перезагрузка происходила только после анимации (и, таким образом, была бы невидимой для пользователя, если все в порядке)?
• Могу ли я что-нибудь сделатьсравнить представление до и после reloadData, чтобы определить, изменилось ли что-либо на экране, и выдать предупреждение, для целей отладки?Я ожидаю, что это будет работать только для строк, которые находятся в поле зрения, поскольку закадровый контент удаляется только тогда, когда это необходимо.

Интересуют ваши мысли!

Answer 1

Я чувствую твою боль. К сожалению, я не думаю, что идея перезагрузки сильно помогает. Если есть расхождение между моделью и табличным представлением, по моему опыту, проблема проявляется как исключение до или во время обновления анимации. Если есть проблема, я обнаружил, что вы не попали на перезагрузку, и я не думаю, что вы хотите.

Вот некоторые факторы риска, которые, по моему опыту, приводят к тому, что модели, склонные не синхронизироваться с представлением таблицы:

• количество моделей и элементов модели, полученных из более сложных расчетов чем простой подсчет массивов и массив itemAtIndex:
• фильтры, такие как вкладки, которые показывают другой аспект модели в той же таблице в зависимости от того, какая вкладка выбрана
• контроллер результатов поиска и его таблица
• обновления на основе событий, которые запускаются асинхронно
• гетерогенных типов в модели, с различными типами клеток и размеров
• одно неуклюжее слово: FetchedResultsController
• и особенно комбинации вышеперечисленных

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

1. Создайте пользовательский интерфейс без искусства и как можно меньше логики приложения; просто макет модели - в максимально возможной степени - равный в сложность, но не в объеме, к реальной вещи.

2. Построить модель и логику приложения вместе с тестами, которые - в той степени, возможно - используйте его независимо от пользовательского интерфейса.

3. Пока вы тестируете, принимайте исключения в качестве друга, сообщая вам, что вам нужно исправить. Вставьте как можно меньше защитного кода как можно дольше .

Мои $ 0,02. Желаем удачи.

Answer 2

Вы можете добавить эту строку кода, где бы вы ни выполняли анимацию вставки / удаления строк.

   [self performSelector:@selector(reloadTheTable) withObject:nil afterDelay:0.3];  




-(void) reloadTheTable {
    [tableView reloadData];
}

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