АРХИТЕКТУРНЫЕ РЕШЕНИЯ ПРИ РАЗРАБОТКЕ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ

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

Рисунок 1. Операционные системы мобильных устройств, представленных на современном рынке

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

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

При этом разработка Android и iOS приложений имеют существенные отличия. Рассмотрим наиболее значимые из них.

В первую очередь следует отметить, что реализация приложений для мобильных устройств с операционной системой Android может разрабатываться на таких операционных системах, как Windows, mac OS и Linux, в то время как, для мобильных устройств с операционной системой iOS разработка возможна только на операционной системе mac OS.

В качестве языков программирования для устройств с операционной системой Android используют: Java, C#, Phyton, Kotlin, C++. Основной интегрированной средой разработки (IDE) Android приложений является Android studio. Данная IDE поддерживает такие языки программирования, как Java, Kotlin и C++. В ней содержаться основные инструменты разработки приложений для смартфонов, планшетов, а также новые технологические решения для Android TV, Android Wear, Android Auto и Glass.

В качестве языков программирования для устройств с операционной системой iOS используют: Swift, Objective-C, C# и C++. Основная IDE для iOS приложений является Xcode. Xcode предназначен не только для разработки iOS приложений, но и mac OS, watchOS и tvOS приложений. Xcode поддерживает такие языки программирования, как Swift и Objective-C, и предоставляет разработчикам все необходимые инструменты для разработки, тестирования, отладки, анализа и т.д.

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

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

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

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

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

Рисунок 3. Детализированная архитектура мобильного приложения

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

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

Описанная структура представлена на рисунке 4.

Рисунок 4. Архитектурные слои мобильного приложения

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

В настоящее время существует множество архитектурных решений, применяемых на практике, например, MVP, MVC, MVVM, VIPER. Рассмотрим более подробно некоторые из них.

Компания Apple для разработки приложений для мобильных устройств с операционной системой iOS, предлагает архитектуру MVC (Model View Controller). Эта архитектура, представленная на рисунке 5, состоит из трёх отдельных компонентов: Model, View и Controller.

Компонент Model - предоставляет собой объектную модель некой предметной области, включает в себя данные и методы работы с этими данными, реагирует на запросы из controller, возвращая данные и/или изменяя своё состояние, при этом model не содержит в себе информации, как данные можно визуализировать, а также не «общается» с пользователем напрямую.

Рисунок 5. Архитектура MVC

Компонент View - отвечает за отображение информации (визуализацию), одни и те же данные могут представляться различными способами.

Компонент Controller - обеспечивает связь между пользователем и системой, использует model и view для реализации необходимой реакции на действия пользователя, как правило, на уровне controller осуществляется фильтрация полученных данных и авторизация (проверяются права пользователя на выполнение действий или получение информации).

Однако, архитектурное решение MVC является хорошим, но не в случае с iOS. Реальная картина MVC от Apple представлена на рисунке 6.

Рисунок 6. MVC от Apple

Чаще всего MVC расшифровывают, как Massive View Controller, потому что Controller очень зависим от жизненного цикла view, поэтому трудно назвать Controller отдельной сущностью, хотя сама архитектура задумывала принцип разделения ролей и способы взаимодействия объектов друг с другом. Таким образом, Controller берет на себя слишком много обязанностей, и в следствии увеличивает объем кода и усложняет его поддержку, масштабируемость и нахождение ошибок.

VIPER (View Interactor Presenter Entity Router) – Архитектурное решение основанное на clean architecture, имеющее пять отдельных компонентов: View, Interactor, Presenter, Entity, Router. Данная архитектура представлена на рисунке 7.

Рисунок 7. Архитектура VIPER

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

Компонент Interactor – это слой, который содержит бизнес-логику с данными (Entities). Этот слой взаимодействует только с Presenter и Entity, поэтому он не должен зависеть от пользовательского интерфейса (UI) и других слоев.

Компонент Presenter – это слой, который содержит бизнес-логику связанную с UI. Это означает, что Presenter передает View, что он должен отображать, когда Presenter получает информацию от Interactor, и будет реагировать на действия View (UI), чтобы сделать навигацию или запросить данные.

Компонент Entity – это слой, который содержит модели объектов, используемых Interactor. Доступ к этому слою имеет только слой Interactor.

Компонент Router – это слой, который содержит всю навигацию приложения. Router несет ответственность за переходы между VIPER-модулями. Router взаимодействует только с Presenter модулями.

Если сравнивать VIPER и MVC, то можно увидеть несколько отличий в распределении обязанностей:

• логику из Model (взаимодействие данных) смещается в Interactor, а также есть Entities – структуры данных, которые ничего не делают;
• из Controller обязанности представления UI перешли в Presenter, но без возможности изменения данных;
• VIPER является архитектурой, которая пробует решить проблему с навигации с помощью Router.

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

Список литературы:

1. Model-View-Controller [Электронный ресурс] – Режим доступа: https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html, свободный (дата обращения 01.09.18).
2. Архитектура мобильного клиент-серверного приложения [Электронный ресурс]. – Режим доступа: https://habr.com/post/246877/, свободный (даты обращения: 01.09.2018).
3. Архитектурный дизайн мобильных приложений [Электронный ресурс]. – Режим доступа: https://habr.com/company/redmadrobot/blog/246551/, свободный (дата обращения: 01.09.2018).