Лучший способ реализации протокола UICollectionViewDataSource?

Question

У меня есть теоретический вопрос.

В настоящее время мое приложение использует UICollectionView в качестве способа отображения списка объектов. UIViewController, который содержит UICollectionView как подпункт, реализует протокол UICollectionViewDelegate и выполняет функции делегата и источника данных. Datasource использует NSFetchedResultsController для предоставления данных;

По-моему, это не лучший способ реализовать источник данных, а реализация его в отдельном классе выглядит лучше. Но проблема в том, что источник данных зависит от параметров поиска в UITextField и некоторых других вариантах кнопок, поэтому каждый раз, когда пользователь вводит текст в поле поиска или нажимает любую из кнопок «сортировки», я должен обновлять источник данных (в частности fetchRequest в NSFetchedResultsController).

Итак, наконец, мой вопрос: Есть ли «лучшие практики» для реализации источников данных, которые зависят от внешних параметров? Должен ли я создать отдельный класс для источника данных для отпуска так, как сейчас? Если я использую datasource как отдельный класс, должен ли я создавать datasourcedelegate для вызова самодельных методов делегатов при делегировании при обновлении источника данных или при использовании некоторых других обходных путей для этой проблемы (я не рассматриваю возможность использования уведомлений о обновлении данных, поскольку, как и для механизма уведомлений это более глобальное решение, которое мне нужно здесь)?

Я не ищу самый быстрый способ, я просто хочу найти верный теоретический способ реализации.

Спасибо всем заранее :)

Answer 1

Я лично реализовал конкретный NSObject производного класса, который реализует UICollectionViewDataSource, а также NSFetchedResultsControllerDelegate, что практически переводит извлечённые результаты контроллера события (объект вставляется, обновлено, удалено), чтобы просмотреть коллекцию события (вставка, обновление или удаление ячеек). Вы можете найти примеры того, как это сделать, я взял мой из here, но я реализовал его как отдельный класс, а не категорию по представлению коллекции. Я обнаружил, что мой класс очень многократно используется, на практике я использую его во всех своих проектах, где необходимо визуализировать управляемые объекты в виде коллекции. Аналогичный класс может быть реализован и для UITableViewDataSource.

Если вам необходимо обновить запрос на выборку с помощью предиката поиска, я бы подклассифицировал ваш вновь созданный класс DataSource и добавил логику для обновления запроса на выборку прямо там. Скажем, вы добавляете метод -(void)updateSearchFilterWithText:(NSString*)text, в котором вы добавляете логику для обновления запроса на выборку получаемого контроллера результатов.Не забудьте снова выполнить выборку и вызовите reloadData в виде коллекции!

С этой архитектурой контроллер представления владеет этим объектом dataSource. Каждый раз, когда пользователь обновляет одно из текстового поля фильтрации (или другого виджета), контроллер вида вызывает updateSearchFilterWithText: вашего объекта источника данных, а остальная часть работы выполняется позже.

Answer 2

То, что вы в настоящее время является стандартным подходом. Хотя нет определенного «лучшего» подхода, то, что вы описываете, безусловно, является лучшим подходом.

Контроллер вашего представления будет иметь экземпляр вашего нового класса источника данных и, скорее всего, будет обрабатывать методы делегата (потому что это действия, которые необходимо выполнить, а не данные), поэтому, когда что-либо изменяется в пользовательском интерфейсе, вид контроллер должен «подталкивать» эти изменения к источнику данных. Никакой дополнительной делегации не требуется.

Нельзя создавать источник данных с мыслью о том, что текстовые поля и кнопки непосредственно меняют изменения. Ваш источник данных должен представлять общий интерфейс, в котором вы можете обновить запрос на выборку для выполнения (который охватывает предикат и сортировка) и изменить настройку ячейки (возможно, с помощью блока). Таким образом, вы сохраняете свою бизнес-логику в контроллере представления и повторно используемом исходном коде данных в другом классе, который можно использовать повторно для других видов/проектов коллекций.