В прошлой статье были рассмотрены базовые тезисы в рамках поставленной задачи разработки мобильного приложения для геймификации бега.
В этой статье предлагается рассмотреть более детально ряд технических концепций, тесно связанных с разработкой мобильного приложения на ОС Android.
Первая и, пожалуй, наиболее важная часть - стек технологий.
Под стеком технологий в данном контексте можно понимать набор из следующих объектов, использование которых позволяет реализовать поставленную задачу:
1. Язык программирования и среда разработки.
2. Набор библиотек и расширений для обогащения функционала.
3. Классическая концепция архитектуры приложения и ее применение.
Язык программирования и среда разработки
Для разработки под Android традиционно предпочитают язык программирования Java, хотя в последнее время все более популярным и продвигаемым для этих целей считается Kotlin, как более гибкий и удобный. В данной работе было принято решение использовать последний.
Несмотря на его относительную новизну, под него уже существует достаточно обширный набор библиотек и компонентов для работы с ОС Android и железными компонентами устройств, а также сервисов Google.
Для комфортной разработки приложений Google создала на базе умной IDE от JetBrains свою собственную – Android Studio. Она позволяет разрабатывать приложения под ОС Android с возможностью интерактивного изменения визуальных представлений активностей, поддерживает анализ синтаксиса на обоих актуальных языках программирования (Java/Kotlin), автоматически управляет зависимостями для системы сборки проектов Gradle и подсказывает типовые ошибки в коде и доступности интерфейса.
Библиотеки и средства расширения функционала
Концептуальный алгоритм минимально рабочего прототипа выглядит следующим образом:
1. Получить данные о геолокации устройства.
2. Положить их во внутреннюю базу данных.
Для этого требуется иметь пакеты для работы с датчиками устройства и базой данных.
Разработка приложения под Android предполагает определенные ограничения и возможности: Google с каждой новой версией ОС Android вводит все более серьезные изменения в механизмы работы с компонентами устройства и ОС, например, отдельный механизм запроса геолокации устройства в фоновом режиме теперь требует отображения специального уведомления в шторке.
Так, для взаимодействия с этими компонентами требуется использовать соответствующие пакеты из API Reference.
Способы получения данных с датчиков устройства
Получать данные о геолокации устройства в Android можно несколькими способами:
1. Используя методы обращения к сервисам устройства, получить доступ к сервису геолокации, проверить методы геолокации (GPS, Сеть) и на их основе совершить «запрос геолокации», получив результат.
2. Использовать методы FusedLocationProvider из пакета Google [Play] Services, которые самостоятельно определят сервис получения геоданных и вернут результат.
В рамках данной работы был выбран второй вариант. Для этого был подключен пакет play-services-location из пакета com.google.android.gms.
Для получения дополнительных данных о физической активности пользователя устройства был подключен пакет play-services-fitness из того же пакета, что и сервис геолокации выше.
Все эти пакеты поставляются Google и, хотя их можно использовать в коде сразу после синхронизации проекта, для физического использования их функциональности может потребоваться запрос у пользователя некоторых разрешений, например, для работы приложения в фоне или получения данных о его физической активности.
Методы организации хранения данных
В качестве базы данных была выбрана система SQLite, представляющая из себя базу данных в одном файле, хранящемся на устройстве пользователя.
Для упрощения работы с базой был использован пакет Android Room. Он предоставляет возможность применения некоторых уровней абстракции для работы с данными из базы, такие как Сущность (Entity), DAO (Data Access Object, объект доступа к данным), а также такие концепты как LiveData (объект доступа к данным в реальном времени) и ViewModel (объект, связывающий данные с компонентом представления пользовательского интерфейса).
Классическая концепция архитектуры приложения и ее применение
Классическое
приложение под Android
состоит из разных компонентов, которые, как правило, указываются в специальном
файле – Android
Manifest.
Примеры компонентов:
Activity – Активность. Это «фундаментальный» компонент приложения, содержащий одну логическую единицу функциональности. Может содержать инструкции для отображения визуального пользовательского интерфейса и их макетов, управления потоком данных. Позволяет реализовывать парадигму «Одно действие – один экран – одна активность».
· Fragment – Фрагмент. Представляет из себя переиспользуемую часть приложения, как правило отвечает за макет части визуального пользовательского интерфейса и связанную с ним логику.
· Service – Сервис. Является механизмом выполнения постоянных, периодических или достаточно длительных действий в фоне. Запускается в общем потоке приложения. Бывает нескольких видов: активный, фоновый и привязанный.
· Broadcast receiver – Получатель широковещательных сообщений. Предназначен для подписки на широковещательные сообщения от разных компонентов ОС и других приложений. Представляет из себя некоторую реализацию паттерна проектирования Listener.
Основной принцип проектирования приложений на Android: принцип разделенной ответственности: классы, связанные с отображением пользовательского интерфейса, содержат исключительно логику отображения этого интерфейса и взаимодействия с системой. Все остальное вынесено в другие функциональные блоки.
Данные обрабатываются в
отдельных функциональных блоках, с учетом архитектуры MVP – в приложении есть три условных слоя, каждый из которых отвечает за свою часть
работы приложения:
Слой пользовательского интерфейса
Этот слой иначе называют презентационным слоем. Его назначение – отображать данные приложения в том или ином виде на экране устройства. При изменении данных, взаимодействии с пользователем или поступлении внешнего ввода интерфейс должен соответствующим образом реагировать и отражать изменения
Слой данных
Слой данных приложения содержит в себе «бизнес-логику». Бизнес-логика – это то, в чем есть суть приложения. Это правила, указывающие, как приложение создает, сохраняет и изменяет данные.
Слой данных состоит из репозиториев, каждый из которых может содержать неотрицательное количество источников данных. Репозиторий создается на каждый отдельный тип данных, обрабатываемый в приложении.
Слой взаимодействия с данными
Иначе – слой доменов. Является опциональным слоем, расположен между презентационным слоем и слоем данных.
Обычно представляет собой инкапсуляцию бизнес-логики, если она переиспользуется разными ViewModel объектами или если она достаточно объемная и сложная.
В минимально рабочем прототипе результирующего приложения также используется классическая архитектура приложения на Android.
Поскольку приложение работает с данными геолокации, в коде создан класс LocationEntity, отвечающий за единичную запись о геолокации устройства в конкретный момент времени.
Он связан с объектами репозитория данных и доступа к данным.
Эти объекты представляют собой слой данных в приложении.
Как такового слоя доменов в приложении нет, потому далее имеет смысл описать презентационный слой.
В приложении слой пользовательского интерфейса представлен следующими объектами:
• LocationUpdateViewModel – объект типа ViewModel, связывающий изменения в данных с изменениями в макете и его элементах;
• LocationUpdateFragment – компонент типа Fragment, описывающий макет с отображаемым на экране содержимым и связанную с ним логику.
Таким образом с помощью применения стандартных компонентов и подходов к архитектуре реализуется корректный процесс работы с данными и интерфейсом в приложении под Android.
На этом можно завершить общий обзор стека технологий, используемых при разработке мобильного приложения в рамках актуальной научно-исследовательской работы.
Открытым вопросом являются методы оптимизации работы приложения на конечном устройстве, т.к. приложение, работающее в фоне и производящее постоянные запросы с очень большой долей вероятности будет использовать больше ресурсов устройства, чем того хотелось бы. Но этот вопрос выходит за рамки данной статьи и, возможно будет рассмотрен в следующей статье.