Архитектура мобильного приложения Android: подробное руководство

Архитектура Android-приложения немного сложнее, чем десктопной программы, хотя бы потому что компьютерное приложение имеет одну точку входа с рабочего экрана или из меню «Пуска» приложений, а далее оно работает по принципу монолитного процесса. У Android-приложения архитектура выглядит по-другому, хотя бы потому, что имеет множество отдельных компонентов, например следующих:

• Activities;

• Fragments;

• Services;

• Content Providers;

• И др.

Как правило, все эти компоненты приложения объявляются в едином файле — манифесте приложения. А сама операционная система Андроид, опираясь на «манифест», уже будет решать, как адаптировать ваше приложение под устройство пользователя.

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

 

Правильная архитектура мобильного приложения Android глазами пользователя

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

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

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

3. Пользователь возвращается в приложение соцсети и добавляет туда изображение из «Галереи».

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

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

• уметь «ждать» своей очереди, если на какой-либо компонент устройства претендуют несколько приложений;

• уметь работать в фоновом режиме;

• уметь работать в «свернутом» режиме, сохраняя все выполненные пользователем действия и ожидая продолжения работы;

• и др.

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

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

 

Архитектура  Android-приложений: основные принципы

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

 

Нужно разделять ответственность

Это один из самых важных принципов, который многие не соблюдают. Нужно разделять ответственность между классами. Например, не нужно разрабатывать весь код приложения в «Activity» или «Fragment», потому что эти классы должны отвечать лишь за логику взаимодействия интерфейса и ОС.

 

Нужно наладить управление интерфейсом пользователя из модели

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

Важно соблюдать принцип управления интерфейсом из постоянной модели, потому что это несет в себе  следующие свойства:

• пользователи вашего приложения не потеряют свои данные, если операционная система Андроид удалит вашу программу, освобождая ресурсы системы;

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

 

Рекомендуемая архитектура  Android-приложения

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

Вот как она выглядит:

Разбираем данную архитектуру Android-приложения:

 

1.  «Activity» и «Fragment» являются частью слоя «View», а это значит, что они не должны иметь ничего общего с бизнес-логикой и/или сложными процессами в приложении. «View» всего лишь отвечает за взаимодействие между пользователем и приложением, анализируя и наблюдая за этим процессом.

2.  «ViewModel» анализирует состояние «LifeCycles» и поддерживает согласование между компонентами в случаях изменений конфигураций  Android-приложения, это также становится возможным благодаря извлечению данных из «Repository». «ViewModel» не взаимодействует напрямую с «View», а делает это при помощи сущности «LiveData».

3.  «Repository» — это не какой-то специальный компонент  Андроид. Это вполне обычный класс, чья основная задача — это выборка данных из разных источников, в том числе и баз данных, и различных веб-служб. Выбранные данные, этот класс преобразует таким образом, чтобы их мог наблюдать компонент «LiveData» и они были доступны компоненту «ViewModel».

4.  «Room» — это библиотека, облегчающая процесс взаимодействия с базой данных «SQLite». Также в ее зоне ответственности лежит: запись шаблонов действий, проверка ошибок во время компиляции, прямое «общение» с «LiveData».

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

Важная рекомендация от разработчиков  Android — это использовать систему «Dependency Injection» или шаблон «Service Locator» для консолидации архитектуры вашего приложения.

 

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

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

1.  Компонент «LiveData».  По сути является компонентом, содержащим какие-то данные, которые можно наблюдать со стороны. Данный компонент всегда знает, когда и какие данные изменяются в приложении и «наблюдает» ли кто-то за ним в данный момент времени и нужны ли обновления «наблюдателю».

2.  Компонент «ViewModel». Это один из самых важных компонентов архитектуры, потому что именно этот компонент содержит в себе информацию о состоянии пользовательского интерфейса, также этот компонент сохраняет «целостность» интерфейса при изменении в конфигурации, например экран телефона был повернут. «ViewModel» связывает «LiveData» и «Repository». «LiveData», получая данные  из «ViewModel», делает его доступным для наблюдения за ним.

3. Компонент «Room». Операционная система Андроид всегда поддерживала работу с базой данных SQLite, но такое взаимодействие имело ряд  проблем. Например, приходилось создавать множество шаблонов для совместной работы, SQLite не могла сохранять простые Java-объекты, не проводилась проверка при компиляции и др. Но пришла библиотека «Room» и решила эти проблемы взаимодействия между  Android и SQLite.

 

Заключение

Любая архитектура  Android-приложения — это широкое поле для творчества, да и вообще программирование — это творчество, где любую проблему можно решить несколькими путями, в общем так, как видит решение конкретный «автор».

Описанную архитектуру  Android-приложений рекомендует Google, при это она не является обязательной — об этом, кстати, сам Гугл и пишет. Поэтому не стоит бояться экспериментировать и практиковать что-то новое.