Модификация архитектуры MVP с использованием паттерна "Координатор"

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Пермский филиал федерального государственного автономного образовательного учреждения высшего образования

«Национальный исследовательский университет

«Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Выпускная квалификационная работа

Модификация архитектуры MVP с использованием паттерна «Координатор»

Смирнов Александр Владимирович

Руководитель Л.Н. Ясницкий

Пермь, 2019 год

Аннотация

Данная работа содержит описание процесса создания нового архитектурного паттерна для разработки мобильного приложения под платформу iOS. Для достижения этой цели было проведено сравнительное исследование популярных архитектур мобильных приложений на платформе iOS, проведено улучшение существующей архитектуры MVP при помощи паттерна Координатор, разработана объектная модель новой архитектуры - Coordinated MVP, доказано преимущество применения данной архитектуры на практике.

Текст диссертации занимает 42 страниц формата А4 и включает в себя 18 рисунков и 7 таблиц, состоит из 3 глав: Исследование существующих архитектур мобильных приложений для платформы iOS, Модификация архитектуры MVP, Практическое доказательство преимуществ модифицированной архитектуры.

Оглавление

Введение

Основные обозначения и сокращения

Глава 1. Исследование существующих архитектур мобильных приложений для платформы iOS

1.1 Общие подходы к разработке архитектуры

1.2 Обзор существующих архитектур приложений для платформы iOS 10

1.3 Выводы по главе

Глава 2. Модификация архитектуры MVP

2.1. Создание глобального маршрутизатора

2.2. Внедрение координаторов

2.3. Выводы по главе

Глава 3. Практическое доказательство преимуществ модифицированной архитектуры

3.1. Описание приложения

3.2. Проектирование архитектуры приложения

3.3. Выбор инструментов разработки

3.4. Детали реализации приложения

3.5. Проверка гипотезы о преимуществах модификации

Заключение

Библиографический список

Введение

С развитием современных технологий, которые позволяют создавать различные мобильные устройства, рынок программных продуктов для мобильной техники получает мощнейший стимул к расширению и развитию.

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

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

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

Вопрос выбора подходящей архитектуры для разрабатываемого продукта всегда был и будет актуальным. Языки программирования развиваются, появляются новые инструменты, библиотеки, всё это приводит к тому, что те подходы, которые ранее были менее удобны и просты, становятся актуальнее. Однако, большинство подходов так или иначе имеют какие-либо проблемы и могут быть модифицированы с целью их решения.

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

Целью диссертации является создание нового архитектурного паттерна для iOS-разработки путем модификации текущего с целью универсализации архитектуры и повышения гибкости мобильных приложений, основанных на ней. Объектом исследования, в свою очередь, являются архитектурные паттерны разработки, а предметом - модификация существующего архитектурного паттерна разработки с целью устранения его недостатков.

Для достижения цели диссертации, необходимо выполнить следующий объём задач:

Провести аналитическое исследование существующих архитектур мобильных приложений для платформы iOS, c целью выявления их достоинств и недостатков на основе критериев, описывающих максимально универсальную архитектуру.

Модифицировать архитектуру, оказавшуюся в результате сравнения максимально универсальной, при помощи паттерна Координатор, с целью обеспечения легкости изменения навигационного слоя приложения и увеличения скорости совместной разработки.

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

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

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

Результатом данной работы должна стать новая архитектура приложений для iOS в виде набора диаграмм классов, а также приложение-пример, показывающее её использование.

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

Основные обозначения и сокращения

DIP - Dependency Inversion Principle - принцип инверсии зависимостей.

GPS - Geo Positioning System - система геопозиционирования.

IMEI - International Mobile Equipment Identity - международный идентификатор мобильного оборудования.

LSP - Liskov Substitution Principle - принцип подстановки Лисков.

MVC - Model View Controller - Модель Вид Контроллер.

MVP - Model View Presenter - Модель Вид Презентер.

MVVM - Model View View-Model - Модель Вид Модель Вида.

SOLID - аббревиатура от названий принципов разработки слабосвязанного поддерживаемого кода.

SRP - Single Responsibility Principle - принцип единственной ответственности.

UI - User Interface - пользовательский интерфейс.

UML - Unified Modelling Language - унифицированный язык моделирования

VIPER - View-Interactor-Presenter-Entity-Router - Вид Взаимодействие Презентер Сущность Маршрутизатор.

1. Исследование существующих архитектур мобильных приложений для платформы iOS

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

1.1 Общие подходы к разработке архитектуры

На сегодняшний день, бизнес ставит перед техническими командами всё более и более сложные и нетривиальные задачи при разработке продуктов. Эта тенденция прослеживается во всех сферах, коснулась она и мобильной разработки. Увеличение количества бизнес-логики в клиентских приложениях влечет за собой множество проблем [8]:

Нарушается принцип единой ответственности (SRP), один из пяти принципов SOLID [5], классы в приложении становятся слишком большими и часто выполняют множество ролей одновременно.

Между сущностями в программном коде создается большое количество жестких связей, нежелательных внедрений зависимостей, нарушаются принцип подстановки Лисков, принцип инверсии зависимостей (LSP, DIP) [6]. Всё это приводит к невозможности тестирования, и, как следствие, к невозможности выявлять проблемы на стадии отладки приложения.

Следствием двух предыдущих пунктов является увеличение стоимости и времени поддержки проекта, техническое усложнение внедрения новой функциональности.

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

Не углубляясь в специфику платформы iOS, можно отметить, что большинство описанных выше проблем могут быть решены путём разделения сложных модулей приложения на слои. Разделение на слои, и связанное с ним понятие «чистой» архитектуры было описано в одноименной книге Р. Мартина в 2012 г. [11]. Это понятие содержит в себе следующий набор принципов:

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

Тестируемость бизнес-логики. Набор бизнес-логики должен быть тестируемым без инъекции в тесты любых внешних элементов вроде UI, хранилища данных, сервисов или любых других элементов.

Независимость от слоя отображения. Слой отображения должен легко подменяться на другой и не должен требовать изменения других слоёв приложения. Например, таблица должна заменяться на список, без необходимости изменения слоя бизнес-логики.

Независимость от хранилища данных. Логика вашего приложения не должна быть привязана к реализации хранилища данных.

Независимость от любой внешней сущности. Ни один из классов приложения не должен взаимодействовать с какими-либо внешними инструментами и полагаться на их реализацию.

В архитектуре программного обеспечения эти принципы отражены следующим образом:



Рисунок 1.1 The Clean Architecture

На рисунке 1.1 описано следующее разделение слоёв:

Entities -- слой модели, описывает используемые в приложении сущности.

Use Cases -- бизнес-логика мобильного приложения, “сценарии использования”. Этот слой управляет данными из предыдущего слоя.

Interface Adapters -- прослойка между слоем сценариев использования и внешними сущностями. Она преобразует модели в формат, который подходит для внешних сущностей, таких как хранилище данных или сервер, а также конвертирует направленный обратно поток данных.

Frameworks and Drivers -- наружный слой, который содержит в себе библиотеки, различные вспомогательные классы, хранилища данных и тому подобное. Как уже было отмечено выше, этот слой не должен создавать строгих зависимостей с остальными частями архитектуры приложения.

Слои в Clean Architecture связаны собой правилом зависимости, гласящим, что в исходной архитектуре все связи должны идти только вовнутрь. Это означает то, что более дальние от центра схемы слои не должны упоминаться кодом из более близких к центру. Эта структура легко может быть изменена: слои могут быть добавлены или убраны, но основополагающим правилом в разработке архитектуры мобильного приложения всегда должно оставаться правило зависимости.

1.1 Обзор существующих архитектур приложений для платформы iOS

Рассмотрим наиболее распространенные архитектуры мобильных приложений на платформе iOS. Их можно условно разделить на несколько различных подмножеств. К первому из них - архитектурам, использующим классическое деление на Model + View, относятся следующие архитектуры:

Classic MVC.

Cocoa MVC.

MVP.

MVVM.

Немного особняком от них находится модульная архитектура VIPER, усложняющая классическое деление на слои и являющаяся, в сущности, реализацией Clean Architecture Р.Мартина [11].

И последнее множество представляет собой архитектуры с однонаправленным потоком данных. Хорошим примером будет являться архитектура Flux, предложенная инженерами компании Facebook [13]. Данные архитектуры являются слишком специфичными, так как изначально разрабатывались для кроссплатформенной разработки на веб-фреймворках, поэтому не будут рассмотрены в рамках данной работы

Описание критериев сравнения архитектур

Перед анализом и сравнением существующих архитектур мобильных приложений, необходимо выделить критерии сравнения. Возьмем за основу описанные выше критерии соответствия модуля архитектуры принципам Clean Architecture:

Изолированность от фреймворков.

Тестируемость бизнес-логики.

Независимость от слоя отображения.

Независимость от хранилища данных.

Независимость от любой внешней сущности.

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

Независимость навигации от содержимого модуля. Вся работа с навигацией не должна зависеть от реализации модуля.

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

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

Итак, в следующих разделах рассмотрим реализации каждой архитектуры для платформы iOS подробно, и сравним их по выделенным критериям.

Classic MVC

Рассмотрим классический вариант всем известной архитектуры для клиентских приложений, MVC - Model-View-Controller. Концепция MVC была описана Т. Реенскаугом в 1978 году [16]. На Рисунок 1.2 представлена диаграмма классической архитектуры MVC:

Рисунок 1.2 Диаграмма классов классической архитектуры MVC

Уже при взгляде на диаграмму классов, становится понятно, что данная архитектура в таком виде практически не применима к реалиям iOS-разработки. Видна критичная архитектурная проблема - все три сущности тесно связаны, присутствует размытие функций View. Тем не менее, задокументируем результаты анализа на соответствие критериям в виде таблицы, с комментариями (см. таблицу 1.1):

Таблица 1.1 Анализ архитектуры MVC на соответствие критериям

Критерий	Удовлетворяет?	Комментарий
Изолированность от фреймворков	Да	Использование фреймворков можно вынести в отдельные вспомогательные классы.
Тестируемость бизнес-логики	Нет	View напрямую связано с моделью и само отвечает за подготовку данных к отображению. Это нарушает принцип единственной ответственности, размазывая ответственность контроллера.
Независимость от слоя отображения.	Нет	Технически, объект Вид в данной архитектуре независим, но на практике в iOS-приложении нельзя просто перезагрузить экран, чтобы обновить на нем данные, ведь получается, что Вид должен сам запрашивать данные у модели. Появляются жесткие связи.
Независимость от хранилища данных.	Да	Работу с базой данных можно вынести в отдельные сервисные классы.
Независимость навигации от содержимого модуля	Нет	За навигацию будет отвечать контроллер, получается, что связи экранов будут лежать в одном классе с бизнес-логикой.
Масштабируемость и изменение маршрутов навигации.	Нет	Нет единой картины связей, плохо понятна начальная и конечная точка навигации.
Удобство поддержания консистентности данных	Нет	Её делает невозможной необходимость полностью перезагружать Вид, и делать из него запрос за данными к модели.

Можно сделать вывод, что данная архитектура абсолютно не применима для iOS-разработки. Далее, рассмотрим вариант архитектуры MVC, рекомендуемый к использованию специалистами компании Apple - разработчика iOS.

Cocoa MVC

Рассмотрим диаграмму классов архитектуры Cocoa MVC, которая описана в официальной документации Apple [10] (см. рисунок 1.3):

Рисунок 1.3 Диаграмма классов Cocoa MVC

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

Однако, на практике не случайно возникает такой термин, как Massive View Controller. Класс UIViewController из основного фреймворка для iOS-разработки Cocoa Touch, который предлагается к использованию в качестве объекта Контроллер, слишком сильно связан со слоем представления. Контроллер вовлечен в большинство этапов жизненного цикла представления, а все функции представления ограничиваются отправкой сообщений о действиях контроллеру. Таким образом, UIViewController является и источником данных, и делегатом событий, а также, в худшем случае, местом выполнения сетевых запросов, обращений к хранилищу данных и многое другое.

Если рассматривать фактическую реализацию Cocoa MVC от Apple, то получится следующая диаграмма классов (см. рисунок 1.4):

архитектурный паттерн мобильный координатор

Рисунок 1.4 Диаграмма классов фактической реализации Cocoa MVC

Проанализируем Cocoa MVC на соответствие заявленным критериям (см. таблицу 1.2):

Таблица 1.2 Анализ архитектуры Cocoa MVC на соответствие критериям

Критерий	Удовлетворяет?	Комментарий
Изолированность от фреймворков	Да	Использование фреймворков можно вынести в отдельные вспомогательные классы.
Тестируемость бизнес-логики	Нет	Контроллер слишком тесно связан с представлением. Из-за этого возникает множество лишних связей бизнес-логики и интерфейса, что затрудняет тестирование.
Независимость от слоя отображения.	Нет	Контроллер отвечает за весь жизненный цикл представления.
Независимость от хранилища данных.	Да	Работу с хранилищем данных можно вынести в отдельные сервисные модули.
Независимость навигации от содержимого модуля	Нет	За навигацию будет отвечать контроллер, получается, что связи экранов будут лежать в одном классе с бизнес-логикой.
Масштабируемость и изменение маршрутов навигации.	Нет	Аналогично классическому MVC, нет единой картины связей, плохо понятны маршруты навигации.
Удобство поддержания консистентности данных	Нет	Связи между дочерними и родительскими экранами сложно проследить.

Подытоживая, можно сделать вывод, что улучшенный MVC от Apple фактически не предлагает разработчику никаких выдающихся преимуществ, по сравнению с классическим вариантом MVC. Однако, у него есть одно главное преимущество: простота и минимальное количество лишнего кода, что делает эту архитектуру максимально выгодной с точки зрения скорости и темпов разработки.

MVP

MVP (Model-View-Presenter) - архитектура, считающаяся сообществом тем, чем должна была быть Cocoa MVC от Apple. Этот вариант архитектуры отличается полным абстрагированием от реализации слоя представления и разрушением столь неудобной связи между представлением и контроллером [2]. Рассмотрим диаграмму классов архитектуры MVP (см. рисунок 1.5):

Рисунок 1.5 Диаграмма классов архитектуры MVP

При использовании данной архитектуры, подклассы UIViewController рассматриваются только как части слоя представления. Роль посредника между слоем представления и моделями выполняет новый объект - Presenter. В него закладывается вся специфическая логика, обращения к источникам данных, логика навигации между модулями, но, при этом, он не содержит кода, связанного с версткой или с отрисовкой данных на экране. Подобное разделение обеспечивает превосходную тестируемость.

В MVP впервые вводится концепция «сборки» модулей перед показом представления. Так как для обеспечения инверсии зависимостей все классы связываются между собой через интерфейсы, то для создания действительно абстрагированных друг от друга, необходимо вводить новый объект, который будет отвечать за соединение трёх слоев в единое целое.

Таким объектом может стать Configurator, который будет отвечать за сборку модулей из составляющих его слоев.

Проанализируем архитектуру MVP на соответствие критериям сравнения (см. таблицу 1.3):

Таблица 1.3 Анализ архитектуры MVP на соответствие критериям сравнения

Критерий	Удовлетворяет?	Комментарий
Изолированность от фреймворков	Да	Использование библиотек можно вынести в вспомогательные классы, отвечающие каждый за свою функциональность.
Тестируемость бизнес-логики	Да	Слои связаны друг с другом через абстракции. Представления практически не несет в себе бизнес-логики, вся логика находится в презентере и модели и может быть легко покрыта модульными тестами.
Независимость от слоя отображения.	Да	UIViewController в рамках MVP - лишь представление, не несущее никаких функций кроме передачи действий в Presenter
Независимость от хранилища данных.	Да	Работу с БД легко вынести в отдельные сервисные классы.
Независимость навигации от содержимого модуля	Да	За навигацию может отвечать объект Presenter.
Масштабируемость и изменение маршрутов навигации.	Нет	Все Presenter содержат в себе слой навигации в приложении, однако их раздробленность не позволяет видеть цельную картину.
Удобство поддержания консистентности данных	Нет	Из-за большого количества интерфейсов, необходимо писать довольно много лишнего кода, для передачи измененных данных назад по стеку навигации.

Можно подытожить данный раздел, отметив, что MVP является отличным примером хорошей мобильной архитектуры, который, однако, оставляет несколько моментов для размышления, самый главный из них - как обеспечить понятность и читаемость навигационного слоя приложения.

MVVM

Архитектура MVVM (расшифровывается как Model-View-ViewModel) является самой новой из архитектур семейства MV(X). Она очень похожа на MVP, также использует концепцию абстракции слоев, и также предоставляет нам слой, не зависящий от реализации представления, но хранящий в себе его состояние - в данном случае этот слой называется ViewModel [2]. Главные отличия данной архитектуры в том, что она вводит концепцию биндингов - связей между представлением и его состоянием, заключенным в ViewModel. Для реализации биндингов используется популярный паттерн Наблюдатель. При обновлении состояние, срабатывает связь, и необходимый элемент представления обновляется. Рассмотрим диаграмму классов архитектуры MVVM (см. рисунок 1.6):

Рисунок 1.6 Диаграмма классов архитектуры MVVM

MVVM позволяет разработчику применять концепцию реактивного программирования для создания авто-связей между представлением и View Model. В сравнении с MVP, это избавляет от необходимости сообщать слою Presenter о необходимости изменить представление, так как авто-связей создаются на стороне представления. В реальных крупных проектах MVVM выглядит намного стройнее MVP, и, хотя слой представления в реактивной архитектуре имеет больше обязанностей, тестируемость всё ещё остается хорошей.

Однако, реактивное программирование в iOS имеет неприятную особенность - сложность отладки. Поэтому за меньшее количество кода разработчик платит опасностью легко нарушить стабильность работы приложения.

За работу с библиотеками и сервисным слоем в iOS версии MVVM отвечает UIViewController, и это обстоятельство опять актуализирует проблему «Massive View Controller». Поэтому, на практике, работу с сервисами и маршрутизацию часто выносят в отдельные объекты (см. рисунок 1.7):

Рисунок 1.7 Диаграмма классов MVVM с дополнительными сервисными объектами

Итак, рассмотрим данную архитектуру по выбранным критериям сравнения (см. таблицу 1.4):

Таблица 1.4 Анализ архитектуры MVVM по критериям сравнения

Критерий	Удовлетворяет?	Комментарий
Изолированность от фреймворков	Да	На рисунке 1.7 представлен пример вынесения работы с сервисами в абстрагированные от основного модуля объекты.
Тестируемость бизнес-логики	Да	Несмотря на более тесную связь представления и данных, тестируемость всё ещё остается на достойном уровне.
Независимость от слоя отображения.	Да	UIViewController в рамках MVVM отвечает за отображение данных и обновление себя в момент изменени View Model.
Независимость от хранилища данных.	Да	Работу с БД легко вынести в отдельные сервисные классы.
Независимость навигации от содержимого модуля	Да	На рисунке 1.7 представлена возможность реализации навигации в сервисном классе.
Масштабируемость и изменение маршрутов навигации.	Нет	Аналогично MVP, в MVVM раздробленность не позволяет видеть цельную картину навигационного слоя.
Удобство поддержания консистентности данных	Да	Авто-связи очень удобны для постоянного поддержания экранов в актуальном состоянии.

Можно подытожить обзор данной архитектуры следующими выводами: MVVM очень похожа на MVP, но решает проблему с необходимостью писать большое количество связывающего слои кода. Однако, возникают другие проблемы в виде сложности отладки. И тем не менее, эта архитектура выглядит очень удобной и перспективной.

VIPER

Архитектура VIPER отличается от архитектур семейства MV(X) ещё большим разделением обязанностей между слоями. Вместо трёх базовых слоёв VIPER предлагает пять: View-Interactor-Presenter-Entity-Router [1].

Interactor содержит бизнес-логику, связанную с данными (Entities): например, создание новых экземпляров сущностей или получение их с сервера. Для этих целей вы будете использовать некоторые Сервисы и Менеджеры, которые рассматриваются скорее как внешние зависимости, а не как часть модуля VIPER.

Presenter содержит бизнес-логику, связанную c UI (но UIKit-независимую), вызывает методы в Interactor.

Entities -- простые объекты данных, не являются слоем доступа к данным, потому что это ответственность слоя Interactor.

Router несет ответственность за переходы между VIPER-модулями.

Рассмотрим диаграмму классов архитектуры VIPER (см. рисунок 1.8):

Рисунок 1.8 Диаграмма классов архитектуры VIPER

VIPER обеспечивает максимальную тестируемость приложения, так как разделение на функциональные слои наиболее частое, максимальное реализуется принцип единственной ответственности [4].

Однако, из этого преимущества вытекает очевидная проблема данной архитектуры - огромное количество кода и высокая стоимость его поддержки. Плюс, наиболее популярна данная архитектура в странах СНГ, так как один из её первый вариант для платформы iOS был реализован командой компании Rambler, и описан в книге “VIPER Book” [15]. Этот факт часто приводит к проблемам поддержки проектов, написанных на данной архитектуре, и затем переданных в США или Европу для дальнейшего развития и поддержки. И тем не менее, на сегодняшний день VIPER довольно часто освещается на профессиональных конференциях и поддерживается большим количеством разработчиков.

Рассмотрим архитектуру VIPER на соответствие выделенным ранее критериям сравнения (см. таблицу 1.5):

Таблица 1.5 Анализ архитектуры VIPER по критериям сравнения

Критерий	Удовлетворяет?	Комментарий
Изолированность от фреймворков	Да	VIPER является наиболее распределенной архитектурой, и позволяет достичь максимального уровня абстрагированности от источников данных, фреймворков и библиотек.
Тестируемость бизнес-логики	Да	VIPER предоставляет разработчику максимально удобные для модульного тестирования структуры классов. Однако и количество необходимых тестов возрастает.
Независимость от слоя отображения.	Да	Как и в рассмотренных ранее архитектурах MVP и MVVM - UIViewController и его подклассы выполняют лишь роль отрисовки интерфейса и передачи действий пользователя далее по цепи событий.
Независимость от хранилища данных.	Да	Работа с хранилищем данных в VIPER инкапуслирована в классе Interactor, обеспечивая максимальный уровень абстракции между слоем данных и слоем бизнес-логики.
Независимость навигации от содержимого модуля	Да	В классический VIPER уже входит объект Router, также несущий функцию фабрики для своего модуля.
Масштабируемость и изменение маршрутов навигации.	Нет	Аналогично MVP и MVVM, то, что Routers разделены и находятся в разных частях проекта, при большом количестве связей становится тяжело видеть полную картину
Удобство поддержания консистентности данных	Нет	Из-за большого количества интерфейсов, необходимо писать довольно много лишнего кода, для передачи измененных данных назад по стеку навигации.

Можно подытожить обзор данной архитектуры следующими выводами: VIPER отлично подходит для создания небольших проектов, которые необходимо на 100% покрывать модульными тестами. При его использовании в крупных продуктах, с длительными сроками поддержки и часто меняющимися требованиями описанные выше проблемы приведут к существенному замедлению и удорожанию разработки проекта.

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

Выводы по главе

В разделах 1.2.2 - 1.2.6 были рассмотрены пять архитектур для iOS-приложений. Архитектуры были проанализированы на соответствие критериям сравнения, по каждой архитектуре была составлена итоговая таблица и сделаны выводы. Следующим шагом было объединение этих таблиц для получения итогового результата (см. таблицу 1.6):

Таблица 1.6 Сравнение архитектур по критериям

Критерий/Архитектура	MVC	Cocoa MVC	MVP	MVVM	VIPER
Изолированность от фреймворков	Да	Да	Да	Да	Да
Тестируемость бизнес-логики	Нет	Нет	Да	Да	Да
Независимость от слоя отображения.	Нет	Нет	Да	Да	Да
Независимость от хранилища данных.	Да	Да	Да	Да	Да
Независимость навигации от содержимого модуля	Нет	Нет	Да	Да	Да
Масштабируемость и изменение маршрутов навигации.	Нет	Нет	Нет	Нет	Нет
Удобство поддержания консистентности данных	Нет	Нет	Нет	Да	Нет
Комментарии	Не применима к iOS-разработке	Простая, высокая скорость разработки	Отличная, но есть проблемы с навигацией	Отличная, но есть проблемы с трудностью отладки	Наиболее тестируемая, сложно поддерживать.

Итак, после анализа получившейся таблицы, видно, что архитектуры MVP и MVVM выглядят наиболее предпочтительными для разработки продукта, который будет долго поддерживаться и часто изменяться. Необходимо сузить набор вариантов сравнения до этих двух архитектур и решить, какую из них следует выбрать для дальнейшего улучшения.

Сложности, возникающие при отладке реактивно-написанных приложений на архитектуре MVVM, зачастую могут стать непреодолимыми для разработчика-новичка. Вдобавок к этому, заточенность под реактивное программирование влечет за собой необходимость либо писать свое решение для авто-связей, основанное на KVO (Key Value Observing - один из механизмов, предоставляемых iOS для реализации паттерна Наблюдатель), либо использовать готовые сторонние решения, такие как Reactive Cocoa или RxSwift. Такие решения на ранних этапах разработки могут вызвать довольно широкий круг проблем в будущем: ушел ведущий разработчик, никто не знает, как работает написанный им код, стороннюю библиотеку перестали поддерживать, и так далее.

Поэтому, наилучшим решением будет использовать для дальнейшей модификации архитектуру MVP, у которой был выявлен только один недостаток, не удовлетворяющий текущим требованиям универсальной архитектуры - проблемы с читаемостью и легкостью изменения навигационного слоя приложения. При дальнейшей модификации эту проблему необходимо решить.

В данной главе был описан процесс сравнения существующих архитектур для iOS приложений. Были сравнены архитектуры MVC, Cocoa MVC, MVP, MVVM и VIPER. По результатам сравнения для дальнейшей модификации была выбрана архитектура MVP.

2. Модификация архитектуры MVP

В следующей главе будет описан процесс модификации архитектуры MVP для решения её проблем с навигационным слоем приложения.

2.1 Создание глобального маршрутизатора

Итак, в Главе 1 была выделена следующая проблема архитектуры MVP: навигационный слой приложения трудно читаем, и плохо подходит для частого изменения. Если посмотреть ещё раз на диаграмму классов архитектуры MVP (см. рисунок 1.5), можно увидеть, что объект Presenter каждого модуля, хранит в себе переходы из текущего модуля в его подмодули. Это приводит к раздробленности операций навигации и отсутствию единообразия.

Первым шагом будет попытка объединения навигации в отдельный класс. Для начала, необходимо описать его интерфейс (см. таблицу 2.1):

Таблица 2.1 Интерфейс класса MainRouter

Поля
Название	Тип	Назначение
sharedInstance	MainRouter	Объект-синглтон [4], использующийся для обращения к роутеру.
rootController	UINavigationController (наследник UIViewController)	Корневой контроллер приложения, создается на старте, от него стартует навигационная карта приложения, в нём хранится стек экранов приложения.
Операции
Название	Назначение	Параметры
start()	Старт приложения, показ rootController	нет
pushModule(presentable, animated)	Добавление модуля в стек и показ его на экран c анимацией типа push, либо без неё.	presentable - интерфейс презентуемого модуля. animated - флаг, показывающий необходимость анимации.
presentModule(presentable, animated)	Добавление модуля в стек и показ его поверх текущего стека экранов c анимацией типа present (модальное окно), либо без неё.	presentable - интерфейс презентуемого модуля. animated - флаг, показывающий необходимость анимации.
popModule(animated)	Удаление верхнего модуля из стека с анимацией либо без неё.	animated - флаг, показывающий необходимость анимации.
dismissModule(animated)	Удаление модального окна с экрана с анимацией либо без неё.	animated - флаг, показывающий необходимость анимации.

Таким образом, после замены Routers у модулей на единый MainRouter, который умеет хранить в себе стек экранов и показывать/убирать модули, мы имеем возможность хранить все операции переходов в нём, однако, нам для этого необходимо модифицировать диаграмму классов модуля (см. рисунок 2.1):

Рисунок 2.1 Диаграмма классов реализации MVP модуля для использования с глобальным MainRouter

На этой диаграмме классов следует остановиться подробнее. Как было отмечено в разделе 1.2.4, MVP архитектура привносит в разработку концепцию сборки модулей, и в её классическом варианте, за сборку отвечает роутер модуля. В данной модификации предлагается создавать для этого отдельный класс Configurator, который отвечает за инициализацию и связь компонентов модуля. Также, чтобы абстрагировать слой навигации от содержимого модулей, вводятся интерфейсы Presentable (который уже упоминался ранее в описании интерфейса MainRouter в таблице 2.1), ModuleInput и ModuleOutput. Возвращая и передавая в конфигураторы модулей только объекты интерфейсов, а не конкретные реализации, достигается необходимый уровень инкапсуляции.

Также, на данной диаграмме можно увидеть, как на практике связываются слои View и Presenter, и как в Presenter внедряется зависимость типа Service, которая описывает интерфейс сервиса для получения необходимой модели и её дальнейшего отображения на View.

Таким образом, описанный класс MainRouter использует только объекты типа Configurator, когда ему необходимо проинициализировать какой-либо модуль и показать его на экран. Для каждой инициализации стоит создавать отдельный метод, поддерживать чистую структуру кода, и тогда весь навигационный слой приложения будет находиться в одном файле и будет всегда доступен для расширения или модификации.

2.2 Внедрение координаторов

Описанная в разделе 2.1. архитектура приложения с глобальным маршрутизатором на первый взгляд полностью решает проблему создания единого навигационного слоя, но у неё есть два существенных недостатка:

Класс MainRouter нарушает принцип единой ответственности [7] - он отвечает как за реализацию переходов (анимацию, хранение стека экранов), так и за логику навигации и передачи данных.

Потенциально, разрабатываемое приложение может содержать очень большое количество переходов, поэтому класс MainRouter разрастется до больших размеров и его станет трудно поддерживать.

На следующем этапе модификации архитектуры эти две проблемы необходимо решить.

Возникает необходимость разбить навигацию на некие части, которые будут нести смысловую нагрузку. Предположим, что каждая такая часть будет называться Flow, например AuthorizationFlow, EditProfileFlow и так далее. При этом, отвечать за хранение стека экранов и анимацию их скрытия/появления по-прежнему будет класс MainRouter.

Для реализации такого деления ответственности подойдет паттерн Coordinator. Впервые его применение в iOS-разработке был описан Сорушем Кханлоу в 2015 г. на конференции NSSpain [11]. Суть паттерна состоит в создании объекта Coordinator, который описывает содержимое Flow. Координатор ничего не знает о своем родительском координаторе, однако, он может запускать дочерние координаторы. Рассмотрим пример подобной древовидной структуры координаторов (см. рисунок 2.2):

Рисунок 2.2 Структура навигации простого приложения с использованием координаторов

Таким образом, вся логика по созданию модулей, по передаче данных между ними переносится из MainRouter в соответствующие классы Координаторы. А MainRouter только предоставляет Координаторам интерфейс, с помощью которого эти модули могут сменять друг друга на экране. Реализация Кханлоу была написана для архитектуры Cocoa MVC, следует создать конкретную диаграмму классов для iOS-реализации паттерна Координатор в архитектуре MVP (см. рисунок 2.3):

Рисунок 2.3 Диаграмма классов реализации навигации приложения с помощью паттерна Coordinator

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

Логика по добавлению и удалению дочерних координаторов инкапсулирована в классе Base Coordinator, что гарантирует, что в конкретной реализации не будет лишнего кода, и что код будет тестироваться один раз.

Координатор может как начать ещё один Flow, запустив дочерний координатор, так и открыть какой-нибудь экран в рамках текущего Flow, используя MainRouter.

Координаторы позволяют очень изящно реализовать навигацию по deep links - ссылкам на какой-либо конкретный экран приложения. Эти ссылки в мобильной разработке являются результатом получения push-уведомления, или результатом открытия приложения с помощью специальной динамической ссылки. Поскольку каждый координатор имеет ссылки на список дочерних, можно итерироваться по ним, последовательно вызывая метод start(deeplinkOption), и кто-либо из дочерних коодинаторов ответит на вызов, если это предусмотрено логикой приложения.

ApplicationCoordinator - главный Координатор приложения - использует при старте объект LaunchInstructor, который инициализируется при старте приложения, и определяет опции, которые необходимо учесть при старте (например, авторизован или нет пользователь, посмотрел ли он вступительные инструкции, и т.п.).

Конфигурация модулей может выполняться как без параметров, так и с передачей внутрь модуля необходимых данных. Правильно используя протоколы ModuleInput и ModuleOutput, можно весьма гибко работать с потоком данных в приложении, не нарушая текущую архитектуру и абстрагированность слоёв друг от друга.

Выводы по главе

В данной главе была произведена модификация архитектуры MVP с целью решения проблемы с понятностью и изменяемостью навигационного слоя приложения. Предложенное решение - выделение навигации в отдельный от модулей слой, и реализация его с использованием паттерна Координатор. Получившаяся архитектура может носить название Coordinated MVP.

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

В следующей главе будет приведено практическое доказательство преимуществ модифицированной архитектуры перед классической реализацией MVP.

3. Практическое доказательство преимуществ модифицированной архитектуры

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

3.1 Описание приложения

Для доказательства преимущества архитектуры MVP, модифицированной координаторами перед стандартной реализацией было решено разработать приложение, и продемонстрировать на практике легкость и простоту изменения навигационного слоя приложения с использованием координаторов.

Главной функцией разрабатываемого приложения будет распознавание эмоций человека в реальном времени с помощью камеры iOS-устройства. Также, в приложении будут различные информационные экраны, структура которых позволит продемонстрировать преимущества внесенных модификаций.

Рассмотрим список экранов приложения. Каждому экрану при реализации будет соответствовать отдельный MVP модуль:

Главный экран - объясняет назначение приложения и служит разводной точкой для доступа ко всем разделам приложения (см. рисунок 3.1):



Рисунок 3.1 Главный экран

Экран распознавания - данный экран отображает видеопоток с камеры приложения, и поверх него отображает результат классификации эмоции, распознанной на кадре (см. рисунок 3.2):

Рисунок 3.2 Экран распознавания

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

Рисунок 3.3 Экран О приложении

Экраны документов (Условия использования и Политика конфиденциальности) - информационные экраны, показывающиеся один за другим. Содержат информационные документы, необходимые для публикации приложения в магазине (см. рисунок 3.4).

Данные экраны, вместе с экраном «О приложении» находятся внутри так называемого стека экранов, или контейнера. Идея эксперимента, который планируется провести, состоит в том, чтобы изменить последовательность данных экранов, и проверить, какое количество файлов необходимо изменить, и сколько изменений совершить, как в классической архитектуре MVP, так и в модифицированной Coordinated MVP, и сравнить результаты этих проверок.

Рисунок 3.4 Экраны документов

Итак, после описания содержания приложения, можно перейти к проектированию его архитектуры.

3.2 Проектирование архитектуры приложения

Для начала, спроектируем приложение в стандартной архитектуре MVP, без модификации координаторами. Рассмотрим стандартную для iOS-разработки реализацию архитектуры MVP:

Рисунок 3.5 Стандартная реализация MVP в iOS-разработке

Для каждого из описанных экранов потребуется написать данную структуру классов и протоколов для них. Всего получается 5 модулей:

MainModule,

VisionModule,

AboutAppModule,

TermsOfUseModule,

PrivacyPolicyModule.

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

Соответственно, получится следующая диаграмма переходов между модулями приложения (см. рисунок 3.6):

Рисунок 3.6 Диаграмма переходов между модулями приложения в классической архитектуре MVP

Для классической архитектуры MVP на данном этапе можно переходить к разработке приложения. Но перед этим, есть смысл спроектировать также структуру координаторов для приложения с модифицированной архитектурой.

Следующим шагом необходимо преобразовать данные цепочки модулей в набор Flow - последовательностей модулей, каждая из которых будет описана в виде отдельного Координатора. Как правило, данные последовательности объединяют модули по принципу отношения к одной функциональности приложения, например Авторизация, или Настройки. В случае данного приложения, можно выделить следующие Flow:

MainFlow - будет содержать в себе модули Main и Vision, так как это основной функционал приложения.

AboutAppFlow - будет содержать остальные три модуля, AboutApp, TermsOfUse и PrivacyPolicy, так как все они относятся к одной функциональности приложения - раздел О приложении.

Разделив модули на Flow, можно описать дерево коодрдинаторов для версии приложения, которая будет написана на архитектуре Coordinated MVP. Стартовой точкой приложения всегда будет являться ApplicationCoordinator - главный координатор приложения. На рисунке 3.7 представлено дерево координаторов с модулями, которыми управляет каждый координатор.

Рисунок 3.7 Дерево координаторов для версии приложения с модификациями архитектуры

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

На следующем шаге можно переходить к разработке приложения. Первым делом, необходимо определиться с инструментарием для разработки.

3.3 Выбор инструментов разработки

В данном разделе будут описаны основные инструменты, которые были использованы при разработке приложения. Будет обоснован выбор IDE, генератора исходного кода из шаблонов, системы контроля версий и инструмента для автосборки версий приложения.

Выбор IDE

Для iOS разработки существуют только 2 варианта IDE:

Apple Xcode - IDE, разработанная и рекомендуемая к использованию компанией Apple. Является мощным и довольно удобным инструментом, содержит в себе встроенный графический редактор интерфейсов, инструменты для анализа утечек памяти, производительности, симуляторы различных устройств и многое другое. К её недостаткам относятся наличие огромного количества багов, частые вылеты, ресурсоемкость.

JetBrains AppCode - легковесная IDE, разработанная компанией JetBrains на основе других своих продуктов. Отличается потрясающей скоростью работы и наличия огромного количества удобных и функциональных горячих клавиш. К её недостаткам можно отнести отсутствие встроенного редактора интерфейсов и слабую интеграцию с сервисами Apple а также высокую цену лицензии.

Для данного проекта была выбрана IDE от Apple, во-первых, ввиду бесплатного распространения, а во-вторых, ввиду того, что большая часть команды проекта, включая автора работы была новичками в iOS разработке. А IDE Xcode является фундаментом, с которого начинается обучение стажеров.

Выбор генератора исходного кода

Одним из недостатков модульности архитектуры MVP является большое количество файлов в проекте. К примеру, на основном языке программирования для iOS - Swift, для одного MVP - модуля требуется создать больше 10 файлов и минимум 4 папки. Большое количество создаваемых файлов повышает вероятность ошибки из-за человеческого фактора. Поэтому, для автоматизации создания файлов было решено использовать генератор Generamba, созданный сотрудниками компании Rambler. После инициализации в проекте он позволяет генерировать модули с использованием различных шаблонов кода.

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

Выбор системы контроля версий

В качестве системы контроля версий был выбран продукт GitLab, ввиду его универсальности и бесплатности. Доступной альтернативой был стек продуктов Atlassian (Bitbucket+Jira), однако от него было решено отказаться ввиду дороговизны. GitLab также является системой управления проектами, позволяет следить за рабочим процессом с помощью Kanban-Board. Также, GitLab имеет встроенную систему непрерывной интеграции, позволяющую автоматизировать проведение Unit и UI тестирования. Однако, ввиду большой скорости разработки, система непрерывной интеграции не пригодится в данном проекте. Вместо этого был использован легковесный и скоростной инструмент Fastlane, автоматизирующий выкладку версий приложения в бета- и альфа-тест. Fastlane позволяет свернуть всё в одну команду и не тратить время на рутинное заполнение одинаковых полей на ресурсах Apple. Этот инструмент также имеет возможность дальнейшей интеграции с GitLab и другими популярными системами непрерывной интеграции.

3.4 Детали реализации приложения

Так как основным объектом исследования данной работы являются архитектуры мобильных приложений, то в рамках данного отчета будут затронуты лишь детали реализации тестового приложения, для общего представления о способах и принципах его работы [14,15,16].

Распознавание эмоций с камеры устройства является задачей машинного зрения. Приложение обрабатывает видеопоток с камеры телефона и разбивает его на кадры. Каждый определенный промежуток времени, один из полученных кадров поступает на вход обученной модели [17, 18].

В качестве модели используется сверточная нейронная сеть CNNEmotions. Она относит входные изображения к одному из следующих 6 классов:

Нейтральные эмоции.

Веселье.

Грусть.

Отвращение.

Удивление.

Злость.

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

3.5 Проверка гипотезы о преимуществах модификации

После разработки двух версий приложения - на архитектуре MVP и на её варианте, модифицированной координаторами, можно провести эксперимент, доказывающий преимущества модификации.

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

Предположим, что нам необходимо изменить порядок модулей в разделе Документы - поменять местами модули TermsOfUse и PrivacyPolicy. В классической архитектуре MVP нам потребуется для этого изменить три объекта Presenter:

AboutAppPresenter - заменить вызов модуля TermsOfUse на вызов модуля PrivacyPolicy.

TersmOfUsePresenter - удалить вызов модуля PrivacyPolicy.

PrivacyPolicyPreseenter - добавить вызов модуля TermsOfUse.

Итого минимум 3 действия и 3 измененных файла, не считая изменений, которые могут потребоваться в слое представления.

Для аналогичного изменения в приложении, написанного с помощью модифицированной архитектуры, нам потребуется всего лишь поменять местами вызовы модулей TermsOfUse и PivacyPolicy в рамках одного файла - AboutAppCoordinator.

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

Заключение

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

В ходе работы было произведено аналитическое исследование популярных архитектур для мобильных приложений на платформе iOS. Были сравнены 5 архитектур, и среди них выявлена наиболее универсальная архитектура для студийной разработки - Model - View - Presenter.

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

...