В мобильной разработке редкие экраны обходятся без коллекций UITableView или UICollectionView. Эти UI-компоненты позволяют разделять экран на ячейки, настраивать их по отдельности или заменять при необходимости. Однако вместе с этим появляется много рутинной работы по настройке DataSource и Delegate коллекции.

Чтобы уменьшить рутину, мы создали библиотеку Reactive Data Display Manager (RDDM). В её основе — адаптер, имплементирующий DataSource и Delegate, и генератор, соответствующий ячейке коллекции. Подробнее о библиотеке вы можете прочитать в первой статье «Reactive Data Display Manager. Введение», написанной аж в 2019 году.

Библиотека дорабатывалась и становилась мощнее. Но чем больше мы вносили улучшений, тем больше понимали, что с архитектурой библиотеки что-то не так. Последней каплей стала попытка подружить RDDM с мощным UITableViewDiffableDataSource, которая завершилась провалом.

Я — Никита Коробейников, iOS teamlead в Surf. С недавних пор отвечаю за развитие RDDM. В статье расскажу историю рефакторинга, который помог обновить библиотеку до современного состояния и подружить с новейшими API для работы с коллекциями.

Проблемы расширения

RDDM родился из идеи вынести UITableViewDelegate и UITableViewDataSource в отдельную сущность, чтобы не имплементировать их методы. Однако во время разработки мы столкнулись с тем, что такое решение сложно модифицировать: любая модификация порождала нового наследника адаптера.

Рассмотрим ситуацию на примере экрана с пагинацией. Такой механизм часто используется, когда нет смысла загружать данные целиком: например, если с сервера приходит много однотипных данных, которые не уместить сразу на одном экране.

Backend-разработчики предоставляют нам API для загрузки данных по пачкам. Задача iOS-разработчика заключается в том, чтобы определить момент, когда нужно запросить следующую пачку. Желательно минимизировать время ожидания: предугадать намерения пользователя и запросить данные чуть раньше.

В этом поможет метод делегата tableView(_:willDisplay:forRowAt:), который срабатывает незадолго до отрисовки ячейки. По индексу можно определить, что последняя ячейка готова к отрисовке, но при использовании RDDM нельзя просто взять и переопределить метод делегата. Придётся наследоваться =(

open class PaginableBaseTableDataDisplayManager: BaseTableDataDisplayManager {

    /// Called if table shows last cell
    public var lastCellShowingEvent = BaseEvent<Void>()

    open override func tableView(_ tableView: UITableView,
                                 willDisplay cell: UITableViewCell,
                                 forRowAt indexPath: IndexPath) {
        super.tableView(tableView, willDisplay: cell, forRowAt: indexPath)

        let lastSectionIndex = self.cellGenerators.count - 1
        let lastCellInLastSectionIndex = self.cellGenerators[lastSectionIndex].count - 1

        let lastCellIndexPath = IndexPath(row: lastCellInLastSectionIndex,
                                          section: lastSectionIndex)
        if indexPath == lastCellIndexPath {
            self.lastCellShowingEvent.invoke(with: ())
        }
    }

}

Не самое дальновидное решение, но это лучше, чем копировать логику из контроллера в контроллер, не так ли? Будем использовать этот адаптер для экранов с пагинацией. Но что если мы захотим расширить возможности адаптера? Тогда появится ещё один наследник. Если понадобится сочетать возможности адаптеров, получится наследник наследника.

За годы использования в RDDM появилось слишком много наследников базового адаптера. На девяти проанализированных проектах собралось 40 различных наследников и их комбинаций. Пугающая статистика, правда? Но это не самое страшное.

С выходом iOS 13 в дополнение к стандартному UITableViewDataSource Apple создали новый тип — UITableViewDiffableDataSource. Мы столкнулись с проблемой: заменить dataSource и попробовать новый мы не могли, потому что RDDM-адаптер представлял монолитное слияние UITableViewDelegate и UITableViewDataSource.

Эти причины и натолкнули нас на мысль о рефакторинге.

Рефакторинг

Что хотели получить после рефакторинга

Возможность расширения без наследования.
Возможность подмены delegate или dataSource.
Хотя бы частичную обратную совместимость. В отдел iOS-разработки Surf работает двадцать разработчиков. Все они используют RDDM в продакшене, поэтому сохранить концепцию библиотеки и интерфейс адаптера было важно.

Архитектура библиотеки до рефакторинга

Это общая схема для UITableView и UICollectionView. Фиксация на тип коллекции и ячеек происходит через алиасы CollectionType, CellGeneratorType. Пунктиром обозначаем части, у которых нет проблем с расширяемостью или заменой. В данном случае — только с интерфейсом адаптера.

Недостатки такой архитектуры мы уже описали выше: слишком много наследников базового адаптера и невозможность использовать новый тип dataSource.

Что получилось после рефакторинга

В новой архитектуре получилось довольно много сущностей. Чтобы собрать из них конкретный адаптер, используем паттерн Builder.

Delegate и DataSource теперь — свойства адаптера. Их можно заменять — правда, только при инициализации, но этого достаточно.

Animator отвечает за обновление таблицы или коллекции. Его можно подменить, но на деле достаточно двух готовых реализаций, которые выбираются в зависимости от версии ОС. Для iOS младше 11 мы проводим вставку и удаление внутри beginUpdates/endUpdates. Для более новых iOS используем performBatchUpdates.

Для мелких модификаций ввели плагины.

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

FeaturePlugin нужен для более сложных фич, в которых потребуется подменить возвращаемое значение в делегате или источнике. Например, в поддержке swipeActions для таблицы.

В общем случае фича равно плагин. То есть когда нужно будет добавить адаптеру новое умение, в первую очередь подумаем, как реализовать его через плагины.

Примеры использования

Пагинация

public override func process(event: TableEvent, with manager: BaseTableManager?) {

        switch event {
        case .willDisplayCell(let indexPath):
            guard let generators = manager?.generators else {
                return
            }
            let lastSectionIndex = generators.count - 1
            let lastCellInLastSectionIndex = generators[lastSectionIndex].count - 1

            let lastCellIndexPath = IndexPath(row: lastCellInLastSectionIndex,
                                              section: lastSectionIndex)
            if indexPath == lastCellIndexPath {
                action()
            }
        default:
            break
        }
    }

Для пагинации теперь используется плагин. Тело главного метода плагина говорит само за себя. Алгоритм действий аналогичен тому, что был в адаптере-наследнике. TableEvent тут — всего лишь enum, описывающий события делегата или dataSource.

Подключить плагин очень просто

 private let lastCellIsVisibleEvent: () -> Void = {
        print("Last cell is visible")
    }

    private lazy var adapter = tableView.rddm.manualBuilder
        .add(plugin: .lastCellIsVisible(action: lastCellIsVisibleEvent))
        .build()

Бонус-трек: стресс-тест адаптер

Количество плагинов ограничено только вашей фантазией.

private lazy var adapter = tableView.rddm.manualBuilder
        .add(plugin: .displayable())
        .add(plugin: .direction(action: scrollDirectionEvent))
        .add(plugin: .headerIsVisible(action: headerVisibleEvent))
        .add(plugin: .lastCellIsVisible(action: lastCellIsVisibleEvent))
        .add(plugin: .selectable())
        .add(plugin: prefetcherablePlugin)
        .add(plugin: .foldable())
        .add(featurePlugin: .movable())
        .add(plugin: .refreshable(refreshControl: UIRefreshControl(), output: self))
        .add(featurePlugin: .swipeActions(swipeProvider: swipeActionProvider))
        .add(featurePlugin: .sectionTitleDisplayable())
        .build()

Стресс-тест адаптер проверяет сочетаемость плагинов. В одном адаптере 11 плагинов:

Displayable пробрасывает willDisplay и didEndDisplaying в генератор, соответствующий типу DisplayableItem.
Direction определяет направление скролла. Реакция идёт на ScrollEvent — событие ScrollViewDelegate.
HeaderIsVisible позволяет задать реакцию на видимость заголовка секции.
LastCellIsVisible нам уже знаком.
Selectable пробрасывает didSelect в генератор, соответствующий SelectableItem.
PrefetchablePlugin добавляет префетчинг изображений. В Example-проекте есть реализация префетчера для Nuke, но можно использовать любую другую библиотеку загрузки изображений с поддержкой префетчинга.
Foldable поддерживает разворачиваемые ячейки.
Movable поддерживает перетаскивания ячеек.
Refreshable — плагин для поддержки UIRefreshControl.
SwipeActions добавляет поддержку sipe menu для таблицы.
SectionTitleDisplayable добавляет отображение индексных заголовков.

11 плагинов в одном адаптере! Представьте, как бы страшно выглядело дерево наследования аналогичного адаптера, если бы мы делали его на старой нерасширяемой архитектуре.

Все эти плагины уже реализованы в библиотеке: можно использовать их в проектах, если обновиться до RDDM 7.x.

Как подключить DiffableDataSource

Очевидно, что UITableViewDiffableDataSource не подключить плагином. К тому же это не конкретный протокол, а generic класс.

Давайте рассмотрим преимущества UITableViewDiffableDataSource на примере изменяемой коллекции.

Чаще контент с сервера мы получаем и показываем без изменений, но иногда даём пользователю возможность:

удалить ячейку,
вставить новую ячейку после или перед другой ячейкой,
поменять ячейки местами.

Такие кейсы я буду называть изменяемой коллекцией.

Заменить ячейку можно тремя разными способами:

ручным,
с помощью сторонней библиотеки,
с помощью нового DiffableDataSource.

Ручной способ

Ручной способ подразумевает, что мы действуем по алгоритму:

определили индекс элемента;
обновили массив генераторов, переместив элемент или удалив его;
выполнили ту же операцию с индексами в коллекции, вызвав методы insertItems/deleteItems.

guard let index = self.findGenerator(oldGenerator) else { return }

generators[index.sectionIndex].remove(at: index.generatorIndex)
generators[index.sectionIndex].insert(newGenerator, at: index.generatorIndex)
let indexPath = IndexPath(row: index.generatorIndex, section: index.sectionIndex)

animator?.perform(in: view, animated: insertAnimation != .none) { [weak view] in 
    view?.deleteItems(at: [indexPath])
    view?.insertItems(at: [indexPath])
}

Внутри аниматора в данном случае скрывается метод performBatchUpdates.

Имеем одну операцию поиска, две операции удаления и две операции вставки. Причём удаление и вставку нужно выполнить в правильном порядке, чтобы результат замены соответствовал ожиданиям и не вызывал падение приложения.

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

Это неудобно, поэтому появились решения типа DifferenceKit. Не будем изобретать велосипед: подружим нашу библиотеку со сторонней.

DifferenceKit

С DifferenceKit алгоритм замены примерно такой:

Сделать генераторы дифференцируемыми. Для этого в библиотеке есть специальный фреймворк, напоминающий Equatable с дополнительным полем для уникального идентификатора.
Сделать слепок массива генераторов.
Обновить массив генераторов, переместив или удалив элемент.
Сделать новый слепок массива генераторов.
Сформировать changeSet из состояния контента до и после изменений, используя слепки.
Применить changeSet к коллекции, указав необходимые анимации.

Библиотека сделана через extensions к коллекции. Её можно использовать, начиная с iOS 9, — то есть практически на любом проекте.

guard let index = self.findGenerator(oldGenerator) else { return }
let oldSnapshot = makeSnapshot()

generators[index.sectionIndex].remove(at: index.generatorIndex)
generators[index.sectionIndex].insert(newGenerator, at: index.generatorIndex)


let newSnapshot = makeSnapshot()

let changeset = StagedChangeset(source: oldSnapshot, target: newSnapshot)
view.reload(using: changeset,
            deleteSectionsAnimation: .automatic,
            insertSectionsAnimation: .automatic)

Шагов в алгоритме больше, но код стал понятнее.

makeSnapshot преобразует массив секций и генераторов в понятный для DifferenceKit формат. Один раз снимаем слепок до изменений и ещё раз — после изменений.

StagedChangeset представляет упорядоченный набор операций типа insertItems/deleteItems. Внутри reload есть блок performBatchUpdates: в нём будут выполнены все операции из составленного сета.

У reload также есть блок-параметр interrupt, в котором можно определить, при каком наборе операций следует сделать полный reloadData коллекции. В общем, решение получилось гибкое и прекрасно ложится на концепцию RDDM.

Вносить DifferenceKit внутрь RDDM мы не стали, чтобы у библиотеки не появились созависимости.

Пример дружбы двух библиотек — в Example проекте.

DiffableDataSource

Кроме сторонних решений, есть системный подход от Apple. Нам так хотелось его использовать, но есть серьёзное ограничение: DiffableDataSource доступен, начиная с iOS 13. Из-за этого DiffableDataSource пока не принести на многие наши проекты. Но скоро мы будем стартовать проекты именно с этого таргета, поэтому подход заранее изучили и подружили с RDDM.

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

Все генераторы должны быть дифференцируемы. SectionIdentifiable и ItemIdentifiable — алиасы для Hashable + Equatable.
Определить DiffableDataSource — generic DataSource, в котором уже определены основные методы типа numbersOfSections, cellForRowAt и другие. Для генерации ячеек, заголовков и футеров используется блок, который устанавливается при инициализации.
Обновить массив генераторов, переместив элемент или удалив его.
Сделать слепок NSDiffableDataSourceSnapshot массива генераторов.
Применить изменения.

В результате получаем такой код для операции замены ячейки другой ячейкой:

guard let index = self.findGenerator(oldGenerator) else { return }

generators[index.sectionIndex].remove(at: index.generatorIndex)
generators[index.sectionIndex].insert(newGenerator, at: index.generatorIndex)
guard let snapshot = makeSnapshot() else { return }

DispatchQueue.main.async { [weak dataSource] in 
    dataSource?.apply(snapshot, animatingDifferences: true, completion: completion)
}

Код сочетает в себе всё хорошее от двух предыдущих решений:

Ясность ручного решения.
Удобство приёма со слепком из решения с DifferenceKit.

Флаг animatingDifferences обеспечивает автоматический выбор необходимых анимаций для ячеек. Значение false будет равносильно вызову reloadData.

В отличие от решения с DifferenceKit, слепок делаем один раз: формируем его из массива генераторов после изменений.

Слепок до изменений всегда есть внутри dataSource. Мы пользуемся тем, что у нас всегда есть возможность сделать слепок из массива генераторов и не создаём конфликтующие стейты.

func appendSections([SectionIdentifierType])

func insertItems([ItemIdentifierType], afterItem: ItemIdentifierType)
func insertItems([ItemIdentifierType], beforeItem: ItemIdentifierType)

func deleteItems([ItemIdentifierType])
func deleteSections([SectionIdentifierType])

func reloadItems([ItemIdentifierType])

Все операции следует выполняеть через адаптер. Плюс RDDM-адаптера в том, что он сочетает в себе делегат и датасорс и позволяет добавлять фичи с помощью плагинов.

Использование DiffableDataSource без RDDM будет выглядеть немного иначе.
Снапшот можно использовать вместо адаптера. NSDiffableDataSourceSnapshot — не просто слепок и не массив. Это более сложный класс, к которому можно применять insert/delete операции — наподобие тех, что есть в коллекции.Однако нам эта способность не нужна. В этом случае мы:
— Либо будем дублировать операции, как и в ручном методе.
— Либо нарушим соответствие состояний адаптера и слепка, так как они независимы.

DiffableDataSource — мастхэв для экранов с поиском или формочек, где часто меняется количество ячеек или их высота и вручную рулить этим сложно.

Если требования по таргету соблюдены, обязательно попробуйте.

Если вас заинтересовал RDDM и вы хотели бы попробовать его на своём проекте, то милости прошу в репозиторий. Мы собираемся дальше развивать библиотеку и всегда рады контрибьюторам.

Больше полезного про iOS — в нашем телеграм-канале Surf iOS Team. Публикуем кейсы, лучшие практики, новости и вакансии Surf. Присоединяйтесь >>

Reactive Data Display Manager. История одного рефакторинга