Освоение MVVM на iOS

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

Почему MVVM (Model-View-ViewModel)?

Основная проблема Apple MVC — смешанная ответственность, что приводит к появлению некоторых проблем, таких как Massive-View-Controller.

Мы должны согласиться с тем, что UIViewController является основным компонентом iOS SDK от Apple, и все действия запускаются и создаются внутри этого объекта. Несмотря на название, это больше, чем классический контроллер (или презентер) из MVC (или MVP) из-за обратных вызовов, таких как viewDidLoad, viewWillLayoutSubviews и других связанных с ним методов. Вот почему мы должны игнорировать ключевое слово Controller в имени и использовать его как View, где роль реального контроллера принимает ViewModel.

ViewModel — полное представление данных view. Каждый View должен содержать только один экземпляр ViewModel. Как правило, ViewModel использует диспетчер для извлечения данных и преобразования его в необходимый формат. Давайте перейдем к примерам:

Здесь мы имеем ViewModel, который извлекает элементы через DataManager и помещает их внутри некоторой переменной. Он также содержит сведения об ошибке и refreshing state, что дает возможность создавать пользовательский интерфейс со всеми необходимыми условиями.

Как вы можете видеть выше, у нас есть ItemViewController, который представляет список элементов в UITableView. Он содержит экземпляр ViewModel и просит его получить данные в колбеке viewDidLoad. Мы также передаем closure, который перезагружает UITableView, как только данные будут получены. Методы UITableViewDataSource также используют ViewModel для получения количества ячеек.

Реактивные биндинги

Реактивные привязки (Reactive Bindings) между View и ViewModel являются основной идеей архитектуры MVVM, где разработчики могут работать с кодом ViewModel, а дизайнеры могут работать с View в Interface Designer.

В первом примере мы использовали замыкание (closure), потому что в iOS SDK нет возможности биндинги. В реальных приложениях вы можете использовать некоторые популярные расширения FRP, такие как ReactiveCocoa, RxSwift или Bond. Мы рекомендуем библиотеку Bond в виду ее простоты.

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

Давайте посмотрим на метод bindViewModel: здесь мы привязываем ViewModel к View. Всякий раз, когда изменяется обновляемое значение, оно устанавливает свойство isAnimating объекта ActivityIndicator. Или когда элементы изменены, UITableView перезагружается. Как вы можете видеть, в большинстве случаев реактивные привязки упрощают код.

Композиция нескольких ViewModel

Иногда у нас есть сложные View с несколькими источниками данных. Например, профиль пользователя Instagram, где у нас есть информация о пользователе и все фотографии, связанные с этим пользователем.

Хорошим приемом будет здесь разделить эту логику на две или более ViewModel. Но у нас есть правило: каждый вид должен иметь только один ViewModel. В этом случае лучшим вариантом является использование композиции ViewModel. Давайте рассмотрим пример:

Как вы можете видеть, у нас есть UserProfileViewModel, который содержит две другие ViewModel и собирает данные из них. У нас также есть refreshing state, которое объединяет два refreshing states внутренних ViewModels. Второй важный момент в строке 36, где ViewModel форматирует данные в требуемую форму. Просмотр просто должен привязать компоненты к ViewModel и показать данные как есть.

MVVM: вывод

ViewModel — это действительно хороший и простой способ передачи логики представления  другому объекту, который помогает нам избежать больших View-Controller, упростить управление и охватить код юнит-тестами. Именно так мы и получаем простую и тестируемую архитектуру.

Источник