Что такое архитектура мобильного приложения

Мобильное приложение — это связанные фрагменты кода, которые работают как единый механизм. Например, пользователь нажимает иконку на экране смартфона — и открывается приложение Яндекс Go, в котором можно вызвать такси, арендовать самокат или заказать еду. За работу этих функций отвечает код внутри приложения.

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

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

1. Сконцентрировать код в одном месте. В этом случае, если что-то пойдёт не так, будет трудно понять, где именно произошла ошибка. Но если производство «товаров» разделить, то поддерживать процессы и искать ошибки будет проще.

2. Сделать каждый фрагмент автономным. Это называют «чистой архитектурой», её составляющие:

● Data-слой. Всё, что связано с данными: доступ к информации, проверка, утилиты. Обычно данные хранятся на сервере. Дата-слой позволяет обращаться к серверу и запрашивать информацию. Дата-слой можно сравнить со складом материалов для производства.
● Слой Domain. Здесь вся бизнес-логика приложения: каким образом будут организованы, отсортированы и распределены по категориям данные из дата-слоя. Доменный слой — это «фабрика», на которой производятся «товары».
● Слой Presentation. На этом уровне отслеживаются изменения в пользовательском интерфейсе и принимаются решения, как на них реагировать. Например, запрашивать новые данные или отправлять информацию на сервер. Слой представления — это менеджер магазина.
● UI-слой. Пользовательский интерфейс: «витрина» в магазине.

Итак, хорошая архитектура помогает:

● Обеспечить надёжную работу приложения: оно выполняет все функции в соответствии с потребностями пользователей.

● Быстро и удобно изменять один или несколько элементов — и это никак не отражается на остальных.

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

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

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

Этот шаблон делит логику приложения на три части:

1. Model — модель. Отвечает за получение и хранение данных по «распоряжениям» от контроллера и их передачу в слой представления. В нашей аналогии это — «производство» и «склад».

2. View — представление, вид. Получает данные от модели, отображает их в интерфейсе, реагирует на решения контроллера и передаёт ему действия, которые выполняет пользователь. Представление — это «магазин» и «витрины».

3. Controller — контроллер. Анализирует действия пользователя, принимает решения по изменению представления и отвечает за то, какие именно данные View будет получать от модели. Контроллер — это прослойка, которая связывает модель и представление. Если «магазин» работает по модели MVC, в роли контроллера будет выступать менеджер, который следит за наличием товара в магазине, забирает на фабрике готовые товары и расставляет их на полках. У него большая зона ответственности, но он не занимается производством и не контролирует остатки материалов на складе.

В шаблоне MVC все части архитектуры взаимодействуют друг с другом

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

1. Model — модель. Отвечает за получение, хранение и обработку данных в соответствии с бизнес-логикой приложения.

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

3. Presenter — презентер. Анализирует действия пользователя, принимает решения по изменению представления и передачи ему данных, которые получает из модели .

В этой схеме архитектуры приложения Presenter — прослойка между видом и моделью

Включает в себя:

1. Model — модель. Получает, хранит и обрабатывает данные, отвечает за бизнес-логику приложения. Это «фабрика» мобильного приложения, которая остаётся неизменной.

2. View — представление, вид. Отвечает за отображение данных и взаимодействие с пользователем. Это «магазин», он также не изменяется.

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

С шаблоном MVVM программу легко тестировать и масштабировать, так как модель и представление не пересекаются

Самый современный шаблон, состоит из компонентов:

1. Model — модель. В отличие от других шаблонов, модель — или «фабрика» — в MVI представляет состояние пользовательского интерфейса, например: процесс загрузки, ошибки, текущее состояние экрана.

2. View — представление, вид. Интерфейс приложения — «витрина». Отвечает за отображение данных и отслеживание действий пользователя.

3. Intent — намерение. То, что пользователь или приложение намереваются сделать. Представим, что у менеджера есть десятки версий магазина, которые можно менять в зависимости от ситуации. Например, версия, в которой все полки заняты товарами. Или другая — с пустой витриной. Покупатель будет недоволен, что не может приобрести товар, значит, нужно сменить состояние магазина на то, где все полки заняты. В этом примере намерение покупателя приобрести товар приводит к изменению состояния модели — фабрики и вида — витрины магазина.

MVI — самый новый и при этом самый в работе сложный шаблон архитектуры

Чёткой инструкции, как создавать архитектуру, нет: это процесс, в котором многое зависит от цели приложения, его системы, компонентов и связей между ними. Чтобы создать архитектуру приложения на Android или iOS, нужно в первую очередь понимать, что представляет из себя система приложения в целом. Рассмотрим на примере магазина. Чтобы «распутать» систему, надо ответить на вопросы:

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

Точно так же «распутывают» систему мобильного приложения. Когда будет понятно, из каких частей она состоит, можно определять слои — Data, Domain, Presentation, UI — и зоны ответственности. Формировать архитектуру приложения можно, когда понятно, как пользователь ощущает себя в системе.