Developer android com wear

Разработка и отладка приложений для Android Wear

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

В этой статье мы поговорим об ОС Android Wear, обратив особое внимание на устройства, работающие под её управлением, на типы приложений, на их разработку и отладку. В частности, рассмотрим два способа отладки с использованием ADB.

Устройства

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

Крупнейшие производители оборудования выпускают собственные серии наручных часов, которые несут на борту Android Wear. Среди устройств этого типа можно отметить ASUS ZenWatch 2, Motorola 360, LG Watch Urbane, Samsung Gear S, Sony SmartWatch 3. Выглядят эти часы по-разному, но в их функциональности, благодаря одной и той же программной платформе, много общего. Это приложение Google Now, возможность отслеживания физической активности пользователя, средства для управления воспроизведением музыки, поддержка голосовых команд.

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

Что разрабатывать для умных часов?

Хотя Android Wear – проект сравнительно новый, Android Wear Center, площадка, аналогичная Google Play, предлагает множество приложений, созданных специально для носимых устройств.

Магазин приложений для умных часов

Здесь есть программы на любой вкус. Каждый день в Android Wear Center публикуются новые приложения для персонализации часов, для работы с музыкой, приложения для организации работы с функциями связи, разработки для здоровья, спорта и другие. Несмотря на небольшой размер экранов часов, есть и игры для них. Например – аркады и паззлы, хотя «носимых игр» пока не так много.

Игры для умных часов

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

Как разрабатывать?

С одной стороны, написание приложений для умных часов очень похоже на создание программ для планшетов и смартфонов. В дело идут знакомые Android-разработчикам инструменты, такие, как JDK, Android SDK (платформа Android Wear поддерживает большую часть API Android), Eclipse, Android Studio или другие интегрированные среды разработки. Здесь можно найти список классов из библиотеки поддержки носимых устройств (Wearable Support Library).

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

Как отлаживать?

Отладка – это то, без чего не обходится процесс создания любого программного кода. Разработка для Android Wear – не исключение. В этом разделе мы рассмотрим отладку «носимых» приложений на примере часов LG G Watch R, подключённых к Nexus 4.

Android Wear поддерживает два способа отладки: с использованием проводного интерфейса USB и по беспроводному Bluetooth.

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

Установка ADB на компьютер разработчика.

Отладочный мост Android (Android Debub Bridge, ADB) – это инструмент командной строки, который обеспечивает взаимодействие компьютера с устройствами, работающими под управлением ОС Android или с соответствующими эмуляторами.

Для того чтобы отлаживать приложения для Android Wear, нужно включить на устройствах работу в режиме отладки. Сделать это необходимо и на умных часах, и на смартфоне, к которому они подключены. Если устройство впервые используется для отладки, нужно открыть его Настройки (Settings), войти в раздел Об устройстве (About) и семь раз коснуться элемента Номер сборки (Build number). После этого в списке настроек устройства появится новая строка – Параметры разработчика (Developer Options). На устройствах различных производителей названия пунктов могут выглядеть иначе.

Включение режима разработчика на умных часах

Переход в раздел настроек разработчика и включение возможности отладки с использованием ADB.

Включение отладки с использованием ADB на умных часах

После этого, если планируется использовать USB-отладку, выполняются следующие действия.

Подключение носимого устройства к ПК с помощью USB-кабеля.

Подключение часов к ПК с помощью USB-кабеля

Разрешение отладки приложений на часах.

Для этого нужно нажать ОК во всплывающем окне с соответствующим вопросом. Оно появится на смартфоне или планшете, с которым связаны часы.

Для USB-отладки приложений на часах нужно разрешить её на смартфоне или планшете

Для того, чтобы проверить, распознал ли ADB умные часы, подключённые к компьютеру, можно воспользоваться командой adb devices в командной строке.

Результат выполнения команды adb devices

После этого всё готово к отладке «носимых» приложений по USB. А вот если вы решили воспользоваться Bluetooth-отладкой, то подготовка к ней будет немного сложнее. Для этого надо выполнить следующие действия.

Включение возможности отладки по Bluetooth (Debug over Bluetooth) на часах.

Включение отладки по Bluetooth на часах

Включение отладки по Bluetooth (Debug over Bluetooth) в приложении, благодаря которому смартфон или планшет взаимодействуют с часами. На рисунке выделена область, в которой отображается состояние устройств.

Включение отладки по Bluetooth на смартфоне и информация о подключении

Подключение смартфона или планшета, соединённых с часами, к компьютеру по USB и разрешение отладки по USB.

Разрешение отладки по USB на телефоне

Выполнение следующих команд ADB в командной строке:

Включение на смартфоне или планшете возможности отладки носимого устройства, подключённого к нему.

Разрешение отладки носимого устройства, подключённого к смартфону

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

Изменение информации о подключении устройств

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

Список устройств, распознанных ADB

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

Как делать скриншоты на часах?

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

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

Квадратные скриншоты часов с круглым циферблатом

Выводы

Союз современных технологий, таких, как процессор Intel Quark и операционная система Android Wear, открывает новые возможности не только для разработчиков устройств, но и для создателей приложений.

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

Источник

Она вам не Android. Особенности разработки под Wear OS

18 марта Google переименовала операционную систему для носимой электроники Android Wear и начала распространять её под именем Wear OS, чтобы привлечь новую аудиторию. Компания опубликовала новые дизайн-гайдлайны и обновила документацию. Когда я начал разработку приложения для часов, не нашел ни одной русскоязычной публикации на эту тему. Поэтому хочу поделиться своим опытом и рассказать подробнее про Wear OS, из чего она состоит и как с ней работать. Всех небезразличных к мобильным технологиям прошу под кат.

Начиная с версии Android Wear 2.0, система научилась работать с «Standalone Apps» – полностью независимыми wearable-приложениями. Пользователь может установить их с нативного Google Play прямо на часы. Wear OS – это практически независимая система, которая всё ещё продолжает работать в рамках инфраструктуры Google Services, дополняя её, но не привязываясь к ней.

Android, но не очень

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

• android.webkit
• android.print
• android.app.backup
• android.appwidget
• android.hardware.usb

Да, браузер на часах мы в ближайшее время не сможем увидеть из-за отсутствия Webkit. Но серфить на часах будет всё равно неудобно. У нас по-прежнему есть великий и ужасный Android Framework с Support Library и Google Services. Структурных и архитектурных отличий тоже будет мало.

Структура приложения

Предположим, мы решили сделать wearable-приложение. Открыли Android Studio, нажали «New project» и поставили галочку напротив «Wear». Мы сразу обнаружим, что в пакете нашего приложения появилось два модуля: wear и mobile.

Собираться эти два модуля будут в два разных .apk файла. Но они должны иметь одно название пакета, и при публикации должны быть подписаны одним релизным сертификатом. Это нужно только для того, чтобы приложения могли друг с другом взаимодействовать через Google Services. Мы к этому вернемся чуть позже. В принципе, ничто не мешает нам собрать приложение только на Wear OS, откинув мобильную платформу в сторону.

Clean architecture?

А почему бы и нет? Это такое же Android-приложение, поэтому архитектурные подходы для него могут быть схожие с Android.

Я использовал такой же стек технологий, который мы используем в Android-приложениях:

• Kotlin
• Clean architecture
• RxPM (как презентационный паттерн)
• Koin (для реализации DI)
• RxJava (просто дело вкуса)

У нас два модуля в проекте, и модели данных, скорее всего, будут одинаковые для обеих платформ. Поэтому часть логики и моделей можно вынести в ещё один модуль «common». Затем подключить его к mobile и wearable пакетам, чтобы не дублировать код.

Одна из главных особенностей Android-разработки – обилие девайсов разного размера и с разным разрешением экрана. В Wear OS, ещё и разная форма экрана: круглый, квадратный и круглый с обрезанным краем.
Если мы попробуем сверстать какой-либо лейаут и отобразить его на разных экранах, скорее всего, увидим примерно такой вот кошмар:

Во второй версии системы Google любезно решила часть UI-проблем, включив в Support wearable library новые адаптивные view-компоненты. Пробежимся по самым любопытным из них.

BoxInsetLayout

BoxInsetLayout – это FrameLayout, который умеет адаптировать дочерние элементы под круглый дисплей. Он помещает их в прямоугольную область, вписанную в окружность экрана. Для квадратных дисплеев подобные преобразования, само собой, игнорируются.

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

Выглядит лучше, не правда ли?

WearableRecyclerView

Списки – удобный паттерн, который активно используется в мобильном (и не только) UX. Wear-интерфейсы исключением не стали. Но из-за закругления углов дисплея верхние View у списка могут обрезаться. WearableRecyclerView помогает исправить такие недоразумения.
Например, есть параметр isEdgeItemsCenteringEnabled, который позволяет задать компоновку элементов по изгибу экрана и расширять центральный элемент, делает список более удобным для чтения на маленьком экране.
Есть WearableLinearLayoutManager, который позволяет прокручивать список механическим колесиком на часах и доскроливать крайние элементы до середины экрана, что очень удобно на круглых интерфейсах.

Сейчас библиотека поддержки Wear включает пару десятков адаптивных View. Они все разные, и обо всех можно подробно почитать в документации.

Рисовать данные на экране – весело, но эти данные нужно откуда-то получать. В случае мобильного клиента, мы чаще используем REST API поверх привычных всем сетевых протоколов (HTTP/TCP). В Wear OS подобный подход тоже допустим, но Google его не рекомендует.
В носимой электронике большую роль играет энергоэффективность. А активное интернет-соединение будет быстро сажать батарею, и могут регулярно происходить разрывы связи. Ещё носимые устройства предполагают активную синхронизацию, которую тоже нужно реализовывать.
Все эти проблемы за нас любезно решает механизм обмена данными в Google Services под названием «Data Layer». Классы для работы с ним нашли свое место в пакете com.google.android.gms.wearable.

Data Layer

Data Layer помогает синхронизировать данные между всеми носимыми устройствами, привязанными к одному Google аккаунта пользователя. Он выбирает наиболее оптимальный маршрут для обмена данными (bluetooth, network) и реализует стабильную передачу. Это гарантирует, что сообщение дойдет до нужного девайса.

Data Layer состоит из пяти основных элементов:

Data Item

Data Item – компонент, который предназначен для синхронизации небольших объемов данных между устройствами в wearable-инфраструктуре. Работать с ними можно через Data Client. Вся синхронизация реализуется через Google сервисы.

DataItem состоит из трёх частей:

• payload – это полезная нагрузка в 100kb, представленная в виде ByteArray. Это выглядит немного абстрактно, поэтому сами Google рекомендуют класть туда какую-нибудь key-value структуру вроде Bundle или Map .
• patch – это путь-идентификатор, по которому мы можем опознать наш DataItem. Дело в том, что Data Client хранит все DataItem’ы в линейной структуре, что подходит не для всех кейсов. Если нам надо отразить какую-то иерархию данных, то придется делать это самостоятельно, различая объекты по URI.
• Assets – это отдельная структура, которая в самом DataItem’е не хранится, но он может иметь ссылку на нее. О ней поговорим позже.

Давайте попробуем создать и сохранить DataItem. Для этого воспользуемся PutDataRequest, которому передадим все нужные параметры. Затем PutDataRequest скормим DataClient’у в метод putDataItem().

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

Теперь наш DataItem хранится в DataClient’е, и мы можем получить к нему доступ со всех Wearable-девайсов.
Теперь мы можем забрать у DataClient список всех Item’ов, найти тот, который нас интересует, и распарсить его:

Assets

А теперь давайте представим, что нам внезапно потребовалось отправить на часы фотографию, аудио или еще какой-то файл. DataItem с такой нагрузкой не справится, потому как предназначен для быстрой синхронизации, а вот Asset может. Механизм синхронизации ассетов предназначен для сохранения файлов размером более 100kb в wearable-инфраструктуре и плотно связан с DataClient’ом.
Как упоминалось ранее, DataItem может иметь ссылку на Asset, но сами данные сохраняются отдельно. Возможен сценарий, когда Item сохранился быстрее Asset, а файл всё еще продолжает загружаться.

Создать Asset можно с помощью Asset.createFrom[Uri/Bytes/Ref/Fd], после чего передать его в DataItem:

Чтобы загрузить Asset на другой стороне, нужно открыть inputStream, получить сам массив байт, а затем представить его в нужной нам форме:

Capabilities

Сеть носимых девайсов может быть гораздо шире, чем два устройства, соединенные по Bluetooth, и включать в себя десятки девайсов. Представим ситуацию, когда нужно отправить сообщение не на все устройства, а на какие-то конкретные часы. Нужен способ для идентификации устройств в этой сети. Способ есть – это механизм Capabilities. Смысл его очень прост – любой девайс-участник сети с помощью CapabilitiesClient может узнать, какое множество узлов поддерживает ту или иную функцию, и отправить сообщение именно на один из этих узлов.
Для того чтобы добавить Capabilities в наше wearable-приложение, нужно создать файл res/values/wear.xml и записать туда массив строк, которые и будут обозначать наши Capabilities. Звучит довольно просто. На практике тоже ничего сложного:

wear.xml:

На стороне другого устройства:

Если у вас, как и у меня, развился Rx головного мозга, то от себя порекомендую расширение для объекта Task. Этот объект довольно часто фигурирует во фреймворках от Google (в т.ч. Firebase):

Тогда цепочка для получения Nodes будет выглядеть красивее:

Messages

Все предыдущие компоненты Data Layer предполагали кэширование данных. Message помогает отправлять сообщения без синхронизации в формате «отправили и заб(ы|и)ли». Причем отправить сообщение можно только на конкретный узел или на конкретное множество узлов, которые предварительно необходимо получить через CapabilitiesClient:

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

Channels

Каналы служат для передачи потоковых данных в режиме реального времени без кэширования. Например, если нам нужно отправить голосовое сообщение с часов на телефон, то каналы будут очень удобным инструментом. Клиент для каналов можно получить через Wearable.getChannelClient(), и дальше открыть входной или выходной поток данных (один канал может работать в обе стороны).

Google активно развивает Data Layer, и вполне вероятно, что через полгода эти клиенты снова куда-то «переедут», или их API снова поменяется.
Разумеется, Data Layer – не единственный способ общения с внешним миром, никто не запретит нам по-старинке открыть tcp-socket и разрядить устройство пользователя.

В заключение

Это был всего лишь краткий обзор актульных технических возможностей платформы. Wear OS быстро развивается. Устройств становится больше, и возможно, скоро это будут не только часы. Support Wearable Library тоже не стоит на месте и меняется вместе с платформой, радуя нас новыми UI-компонентами и чудесами синхронизации.
Как и у любой другой системы, тут есть свои тонкости и интересные моменты, о которых можно говорить долго. Многие детали остались раскрыты не полностью, поэтому пишите в комментариях, о чем хочется поговорить подробнее, и мы расскажем об этом в следующей статье. Делитесь своим опытом wearable-разработки в комментариях.

Источник