The Book of VIPER

Дополнительные материалы Rambler&Co
Rambler.iOS V - V is for VIPER
В Rambler&Co периодически проводятся встречи iOS разработчиков. Одна из них была полностью посвящена VIPER - и стала основой для этой книги.

Вступление (Видео) - Егор Толстой
VIPER a la Rambler (Видео | Слайды) - Сергей Крапивенский
Кодогенерация и Генерамба (Видео | Слайды) - Егор Толстой
Переходы между модулями (Видео | Слайды) - Вадим Смаль
Сложные модули (Видео | Слайды) - Андрей Зарембо
Разбиваем Massive View Controller (Видео | Слайды) - Александр Сычев
Тестирование VIPER (Видео | Слайды) -Станислав Цыганов
VIPER и Swift (Видео | Слайды) - Валерий Попов
Секция вопросов и ответов (Видео) - Егор Толстой, Сергей Крапивенский

О правильности проведенного рефакторинга может свидетельствовать простой опросник, на все вопросы которого необходимо ответить: "Нет".

Взаимодействует ли view controller напрямую с моделью?

Содержит ли view controller бизнес-логику?

Содержит ли view controller логику, не связанную с UI?

Используйте поставляемые со стандартным SDK классы view controllers.

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

Создавайте view controller максимально автономным.

Контроллер представления не должен знать о внутренней логике другого контроллера или о его иерархии view. Обмен данными между двумя контроллерами должен осуществляться через явно определенный публичный интерфейс.

Не храните во view controller данные. View controller выступает посредником между модельным слоем и слоем представления при обмене данными. Он может кешировать некоторые данные для быстрого доступа, валидировать их, но его основная обязанность - гарантировать, что view отображает правильную информацию.

Используйте view controller для реакции на внешние события. К внешним событиям относятся: пользовательский ввод, системные уведомления (например, о появлении клавиатуры), делегатные методы различных обработчиков (например, CLLocationManager).

Каждый такой объект отвечает за:

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

Вариант с ModuleInput
Текущий вариант, доступный в нашем GitHub под названием ViperMcFlurry стал гораздо проще в освоении. У каждого модуля теперь есть точка входа - ModuleInput, которая позволяет настроить модуль или вызывать методы. Этот moduleInput можно использовать внутри роутера для настройки модуля, можно вернуть презентеру, для постоянной связи с подмодулем.

У каждого модуля можно задать ModuleOutput, чтобы вернуть данные из модуля. ModuleInput/Output - это протоколы, которые задаются внутри модуля, то есть в них хранится контракт связи с ним. В большинстве модулей в роли ModuleInput выступает презентер этого модуля, а в качестве ModuleOutput - презентер вызывающего модуля.

Через ViewController c блоком конфигурации
Для решения первых двух проблем были использованы method-swizzling и блоки. В -prepareForSegue: в sender отправляется блок, в котором выполяется настройка модуля через destinationViewController. В альтернативном методе -prepareForSegue: блок вызывается с destinationViewController из segue в качестве параметра.

Это работает, логика настройки следующего модуля находится целиком внутри Router, для каждого модуля больше не требуется добавлять во ViewController метод -prepareForSegue:, но остаются три проблемы:

Данные для работы следующего модуля попадают во View, а не в Presenter,
Каждый модуль знает об устройстве другого модуля,
Каждый роутер знает, что работает с ViewController и схема работает только для этого.

Итоги
Когда подмодули помогают?
Уменьшает сложность основного модуля
Легкое переиспользование подмодулей
Упрощает добавление новой функциональности
Упрощает тестирование
Когда подмодули мешают?
Значительно увеличивает объем кода
Усложняет логику
Усложняет отладку
Тяжело поддерживать

Таблица с группами ячеек
Это способ построения таблицы настроек. Интерактору при инициализации отдается список подмодулей для отображения. Он опрашивает каждый подмодуль и асинхронно получает массив view-model для каждого подмодуля, склеивает их в общий массив и передает своей таблице для отображения. Фабрика ячеек из cell-model получает все необходимые данные для создания и конфигурации ячейки, поэтому универсальна для всех подмодулей

Создание нового модуля - одно из самых узких мест в VIPER, особенно с точки зрения стороннего человека. Для того, чтобы создать новый модуль-экран, нужно как минимум:

Пять новых классов (Assembly, ViewController, Presenter, Interactor, Router),
Пять новых протоколов (ViewInput, ViewOutput, InteractorInput, InteractorOutput, RouterInput),
Пять новых тестов (AssemblyTests, ViewControllerTests, PresenterTests, InteractorTests, RouterTests).