Как стать автором
Обновить

Комментарии 9

Не смотрели на способы работы NSFetchedResultsController? Точнее даже не их (т.к. он для проверки изменений, естественно, полагается на возможность узнать это у объектов класса NSManagedObject), а взаимодействие с таблицей через делегат. Просто решаемая задача-то одна, а тогда при сходном синтаксисе делегата (...WillChangeContent:, didChangeSection: и так далее) было бы проще пользоваться и вашей библиотекой.
Нет, не смотрел. Не могу сказать, взлетит оно или нет, CoreData может внезапно поставить палки в колеса, но посмотрю.
Глянул. Ничего особо не должно препятствовать использованию ATableAnimationCalculator даже вместо NSFetchedResultsController. Конечно, мы потеряем события об изменении запросов, но если нужно обновлять по требованию пользователя, то будет даже немного проще.

Ну, или подключиться к событиям, после чего заполнить результат вручную (я имею в виду ATableDiff, там достаточно простые поля), и в controllerDidChangeContent — сказать diff.applyTo(collectionView:collectionView).

Впрочем, не уверен, что только ради второй части нужно использовать ATableAnimationCalculator :)
Я, наверное, криво выразился. Суть не в использовании вашего контрола вместо NSFetched… (не обижайтесь, но смысла мало — первый очень хорошо решает данную задачу, но ограничен классами). Мое предложение было сделать ваше взаимодействие (протоколы) максимально похожим на то, которое идет «из коробки» (в NSFetched...) — будет проще, если все примерно в одних терминах живет (отдельно обновляет ячейки, отдельно секции, делает общую подготовку).
Никаких обид, отличное предложение.

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

Дело в том, что NSFetchedResultsController был сделан для UITableView, и так себе, например, подходит для UICollectionView с его performBatchUpdates.

Также разнится и источник изменений. В NSFetchedResultsController — внешняя сущность, CoreData. А у меня изменения должны вливаться в модель бизнес-логикой приложения. В этой ситуации проще применить сразу все изменения, нежели выдавать их по-одному.

Другое дело, что, возможно, имеет смысл дать возможность подключить стандартные операции, которые приходят из UI (редактирование таблицы из UI, перемещение ячеек) — это интересная мысль, я подумаю, что тут можно сделать.
А вот это отличный ответ, спасибо! В целом со всем согласен))
Добавил немного методов, чтобы проще было подключить методы редактирования UITableViewDataSource. (код в обновлении статьи про 0.9.12)
Кажется, это именно то, что я все время планировал написать для себя.
NSFetchedResultsController — можно использовать, но иногда хочется работать с простыми данными.

Добавил в закладки. Буду пробовать.
Я обновил код до 0.9.12, он стал сильно стабильнее и умнее. Если будете пользоваться — лучше использовать именно эту версию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий