wear хранилище что это
Где приложения хранят свои данные
Андрей Подкин
При использовании приложений под Android иногда появляются вопросы: «А где приложение хранит созданные файлы?», «Можно ли до них достучаться?» и «Удалятся ли файлы при удалении приложения?» Давайте попробуем посмотреть, где же приложение может хранить свои данные и какие последствия это имеет для пользователя.
Внутреннее хранилище данных
Смысл следует непосредственно из названия. Внутреннее хранилище (internal storage) располагается всегда в памяти смартфона вне зависимости от того, есть ли возможность установки карты памяти (и тем более того, вставлена ли она). Эта область памяти является защищенной. Находится в системном разделе /data. По умолчанию все файлы, которые там располагаются, доступны только тому приложению, которое их создало. Разумеется, можно сделать файлы доступными для других приложений, но это надо делать специально. Если приложение не открывает файлы для доступа извне, достучаться к ним можно будет только получив root.
Назначение хранилища понятно: внутренние защищенные данные, к которым не должно быть нерегламентированного доступа. Проблемы (с точки зрения пользователя) могут быть в следующих случаях:
Пример: приложение «Лекции по истории России». В приложении хороший контент (и по содержанию, и по качеству звука). Но сохраняется он во внутреннюю память. На бюджетных устройствах, где этой памяти мало, становится затруднительным закачать заранее много лекций, а потом, отключившись от интернета, слушать их. Второй проблемой становится собственно регламент доступа к данным. Даже если ограничиться тематикой истории, у меня есть аудиофайлы, полученные из трех источников: данное приложение, подкасты и аудиоверсии роликов с youtube. Хочется взять и объединить навек в их земной юдоли под владычеством всесильным Властелина Мордора их все в единый плейлист, и слушать его одним аудиоплеером. Но на смартфоне без root это сделать невозможно.
Внешнее хранилище «личных» данных
С точки зрения разработчика, кроме внутреннего хранилища данных, для персональных целей приложения есть еще внешнее хранилище. Оно необязательно размещается на карте памяти. Это может быть и внутренняя память смартфона, но весь раздел с такими данными размещается в общем доступе. В корне раздела есть папка Android/data, а в ней — подпапки с именами пакетов приложений.
Плюсы такого подхода очевидны: данные доступны извне для целей пользователя. А если это карта памяти, то и емкость может быть ограничена только вашими финансами (в продаже уже можно найти карты памяти на 400 гигабайт). Минусы тоже понятны: в любой момент любое приложение (конечно, имеющее разрешение на доступ к «внешним» данным) может взять и стереть чужие файлы. Также файлы будут удалены системой при удалении приложения (или при очистке его данных).
Пример приложения: подкаст-менеджер BeyondPod (более-менее свежей версии, раньше файлы хранились по-другому). Пользователь имеет доступ к скачанным подкастам и может легко удалять их (например, в целях экономии места) или слушать их во внешнем плеере.
Общее внешнее хранилище
Располагается в корне «внешнего» раздела на одном уровне с папкой «Android». Предназначается для хранения данных, разделяемых между разными приложениями. Обычно в документации Google в качестве примера приводят картинки (фото с камеры — папка DCIM). Основная проблема данных файлов: они никогда не удаляются автоматически. Даже если приложение вы удалили.
Пример: мессенджер Telegram. После того, как вы удалили приложение, загруженные файлы никуда не исчезают. Они продолжают спокойно лежать на накопителе данных, занимая драгоценное место.
Как можно удалить файлы, не удаляя приложения
Здесь важно ввести еще одну классификацию файлов приложений. Она справедлива для внутреннего хранилища и для внешнего хранилища личных данных. Все данные делятся на два типа: собственно данные и кэш.
Данные (папка data) — некие файлы, которые, по логике Google, нужны для постоянной работы с ними. Если полностью их удалить, то приложение поведет себя точно так же, как если бы его переустановили (удалили и заново установили). Частичное удаление файлов может не привести ни к каким неприятным последствиям. Но важно понимать, какие конкретно данные вы удаляете (например, очевидно, что скачанные файлы подкастов можно удалять совершенно свободно — это не повлияет на работоспособность подкаст-менеджера).
Кэш — временные данные, которые сформированы в ходе работы приложения и нужны для ускорения этой работы. Например, данные, которые часто нужны в интернете, загружаются и в дальнейшем вместо загрузки открываются локально (разумеется, кэш может обновляться, чтобы не показывать устаревшие данные). Удалять кэш любого приложения можно совершенно спокойно, это штатная операция.
Очистка памяти и кэша вызывается из настроек приложения. Кнопка «Очистить кэш» очищает только кэш, а кнопка «Очистить данные» — и кэш, и данные приложения.
Удаление файлов приложения из общего внешнего хранилища выполняется только вручную. Более того, даже оценка того, от какого приложения эти файлы остались, тоже выполняется вручную.
Android Wear: как это работает и чего ждать
Сама по себе идея смарт-часов — уже далеко не новость даже с практической стороны: тут вам и великолепные Pebble, и недавно обновлённые Gear от Samsung, и другие решения. Но недавно в данном сегменте рынка произошло событие если не эпохальное, то как минимум знаковое: Google «выкатила» вариацию своей мобильной ОС — Android Wear — созданную специально под «носимые аксессуары». Мало того: в тот же день свои решения под Wear анонсировали LG и Motorola. Вкратце мы об этом уже писали, а сейчас попробуем внимательнее взглянуть на новую версию знакомой операционки.
Само собой разумеется, что мобильная ОС для смарт-часов должна отличаться (причём довольно значительно) от системы для смартфонов — оригинальный форм-фактор диктует свою специфику. В общих чертах рекламные материалы по Wear описывают эту специфику следующим образом:
Компактные и мощные устройства, носимые на теле. Полезная информация именно тогда, когда она нужна. Умные ответы на заданные вопросы. Инструменты для фитнесса. Ваш ключ к «многоэкранному миру».
В качестве иллюстрации к тому, как именно это должно работать, компания выпустила несколько видеороликов. Вот, к примеру, один из них, рассчитанный на широкую общественность; он уже фигурировал на нашем сайте, однако, думаю, не грех и повторить:
Для тех, у кого нет времени или желания смотреть ролик целиком, выделю один ключевой момент, озвученный дизайнером Алексом Фааборгом (Alex Faaborg). По его словам, для новой операционной системы был создан принципиально новый пользовательский интерфейс, главным требованием к которому было сочетание простоты, скорости и удобства. Этого удалось добиться за счёт того, что работа системы, по сути, ограничивается всего двумя ключевыми моментами: выводом наиболее актуальной для текущих условий информации и поддержкой голосового управления.
Более подробно эта особенность раскрывается в полной версии анонса для разработчиков. Документ подчёркивает, что все приложения должны вписываться в набор из двух базовых функций, названных «Предложение» (Suggest) и «Спрос» (Demand).
Режим Suggest описывается как «поток контекстных данных». Он построен по принципу «одно сообщение за раз» и представляет собой набор «карточек» с важной в целом или значимой на данный момент информацией. Прокручивая сообщения в вертикальном направлении, пользователь может переключаться между карточками, а перемещения по горизонтали открывают дополнительные возможности. Предусмотрено и удаление ненужных карточек — «до тех пор, пока в них не появится новая полезная информация».
Выглядит всё это приблизительно вот так:
Режим Demand предназначен для случаев, когда «контекстный поток» не может предсказать, что именно требуется пользователю в данный момент. Он активируется традиционной фразой «OK, Google» или тапаньем по значку «g» на домашнем экране. После этого можно отдать устройству голосовую команду или воспользоваться списком действий с открывшейся «карточки подсказки»:
Как мы видим, выбор из списка осуществляется классическим тапаньем. Что же касается голосовых команд, то в Google обещают SDK под Wear, который даст и сторонним разработчикам полноценный доступ к этому виду управления. При этом даже допускается возможность использования одной фразы несколькими приложениями — пользователь сам сможет выбрать желаемого «исполнителя».
Раз уж мы вспомнили SDK, нельзя не отметить одно интересное событие. Сама Google пока предлагает лишь предварительную версию комплекта разработчика — она позволяет редактировать уведомления от уже существующих Android-программ, а также оценивать, как эти сообщения будут выглядеть на условном экране смарт-часов. Полноценный комплект ожидается «позже в этом году». В то же время создатели приложения Pocket, предназначенного для сохранения интересных материалов «на потом», уже представили своё программное решение для Wear. Что примечательно, речь идёт не об отдельном приложении, а именно об SDK, который позволит всем желающим встраивать в свои творения отдельные функции оригинального Pocket.
Возвращаясь к интерфейсу, стоит сказать, что Google выработала довольно чёткое и своеобразное видение по поводу user experience на носимых устройствах. Это видение включает в себя 4 основных принципа:
Оперативность и самостоятельность. В данном случае эти два понятия тесно связаны: гаджет с Android Wear не столько реагирует на команды пользователя, сколько сам следит за окружающей обстановкой и выводит уведомления «на своё усмотрение», в нужном месте и в наилучшее время. Необходимые данные система может получать с самых разнообразных сенсоров, начиная от акселерометра и заканчивая фитнесс-датчиками.
Минимум действий со стороны пользователя. Этот принцип логически следует из предыдущего. Ввод требуется лишь тогда, когда без этого никак не обойтись, и осуществляется максимально простыми методами — голосом и элементарными жестами, которые не требуют высокой точности движений.
Читабельность. Экран носимых устройств невелик, а пользоваться ими приходится постоянно. Поэтому все уведомления должны быть максимально лаконичными, информативными и удобными для восприятия. (Кстати, эту особенность неплохо видно на приведённой выше иллюстрации к режиму Suggest: даже фон, на котором располагаются карточки, подбирается под ту или иную текстовую информацию).
Полезность. Google прямо сравнивает свою разработку с личным помощником, который знает хозяина и его предпочтения, всегда готов ответить на вопрос и даже «перебивает лишь тогда, когда это абсолютно необходимо».
Именно на эти принципы и советуют ориентироваться разработчикам сторонних приложений под Android Wear.
Итак, что же мы имеем в итоге? Несмотря на то, что смарт-часы с Android Wear явно не рассчитаны на роль самостоятельных гаджетов, Google замахнулась на нечто ощутимо большее, чем простой наручный экран для уведомлений с набором внешних датчиков. И лично по моему скромному мнению, это «большее» получилось достаточно самобытным и в хорошем смысле двойственным. С одной стороны, Android Wear предлагает обширные возможности для дополнительных приложений, с другой — предусматривает для них чёткие рамки, вполне соответствующие особенностям смарт-часов как отдельного класса гаджетов. Не стану однозначно предсказывать новинке коммерческий успех, однако повод для беспокойства у конкурентов определённо имеется. И как знать: возможно, благодаря Android Wear мы увидим долгожданные iWatch от Apple хотя бы на пару недельраньше, чем изначально предполагалось.
Похожие статьи
Поиск Google научили искать информацию в личных данных пользователя
Создатель Android представил смартфон Essential Phone
Каким будет Android O и стоит ли продавать свой iPhone
Дешевле некуда. IKEA начала продавать лампочки, совместимые с Apple HomeKit
10 главных анонсов конференции разработчиков Google I/O
Честно говоря, очень странно, что не показали ничего про столь модный нынче ЗОЖ.
Самое главное теперь — дождаться первых живых часов (июнь), а вместе с ними — информации о времени автономной работы и возможности взаимодействия с iOS. Особенно было бы интересно увидеть способ зарядки этих штук. Надеюсь, что Motorola и LG не будут изобретать велосипед, а просто реализуют Qi
Ну, в первом видео отчасти показали — забег на посадку в самолёт и полсотни сожжённых в процессе калорий 🙂 Хотя в самом деле могли бы и полнее раскрыть тему.
Насчёт зарядки — встречал инфу, что у Моторолы вообще не планируется внешних портов. Так что Qi выглядит вполне вероятно.
Android Wear и все, что с ней связано на Google I/O
Некоторым пользователям, по словам Google, приходится доставать смартфон из кармана по 125 раз на день. В современном мире, где вместо «спасибо» мы говорим «спс», это для многих непозволительная трата драгоценного времени. Поэтому в марте этого года Google представила Android Wear – модификацию «зеленого робота» для носимых устройств. А на прошедшей накануне презентации компания познакомила нас со всеми ее составляющими уже окончательно.
Android Wear
Нельзя сказать, что о носимом Android мы узнали много нового. Интерфейс Android Wear представляет собой карточки из Google Now, вертикальными свайпами их можно пролистывать, а горизонтальными – получать более детальную информацию. При смахивании уведомления оно пропадает и со смартфона, это грамотно.
Входящий вызов можно принять или отклонить, потянув, соответственно, зеленый или красный кружок с края экрана. Если потянуть шторку сверху, то можно отправить звонящему один из шаблонов СМС. Если вытягивать ту же верхнюю шторку на домашнем столе, то включается/выключается беззвучный режим.
Несмотря на обилие жестов пальцем, управление в основном строится на голосовых командах. Тем не менее заметку с помощью голоса на презентации сделать так и не получилось, часы упорно воспринимали команду как поисковый запрос. 
Видимо, именно для таких случаев немного ранее старта Google I/O клавиатура Minuum анонсировала поддержку Android Wear. В версии для смартфона она, к слову, уже имеет русский язык, но удобной от этого не кажется. На маленьком экране часов все, вероятно, будет и того хуже. Печатать, по-моему, приемлемее на смартфоне.
После демонстрации интерфейса зрителям представили SDK, который позволит разработчикам не только научить их приложения отправлять уведомления на умные часы, но и писать приложения конкретно под Android Wear. В частности, нам показали следующее:
Зачем это делать с помощью часов, рассказывать не стали.
Первые представители
Как изначально и предполагалось, одним из первых устройств на Android Wear стали LG G Watch. Устройство работает на процессоре Snapdragon 400, имеет 512 МБ оперативной памяти и 4 ГБ на внутреннем хранилище, диагональ LCD-экрана составляет 1,65 дюйма, а разрешение – 280 х 280. Емкость аккумулятора составляет 400 мАч, что должно обеспечивать 36 часов работы в режиме ожидания. Не так уж и много, вообще-то. Кроме того, они оснащены Bluetooth 4.0, гироскопом, акселерометром и компасом.
Весят часы 63 грамма, а габариты составляют 37,9 x 46,5 x 9,95 мм. Материалами служат нержавеющая сталь и силикон. Изначально часы будут доступны в черном и белом вариантах исполнения. Важно также отметить, что G Watch обладают защитой от пыли и влаги по стандарту IP67.
Уже сейчас LG G Watch доступны в Google Play для предзаказа по цене 229 долларов для таких стран, как США, Великобритания, Франция, Германия, Италия, Испания, Южная Корея и Япония. Отправлять заказанные часы начнут после 3 июля. Немного позже в розничной продаже часы также появятся еще в 27 странах, в том числе в России.
Вместе с LG представила свои первые часы на Android Wear и Samsung, аксессуар которой получил название Samsung Gear Live. Строго говоря, это все те же Gear 2 Neo, с той лишь разницей, что место Tizen OS заняла ОС от Google.
Отсюда и соответствующие характеристики: 1,63-дюймовый AMOLED-дисплей с разрешением 320 х 320 точек, процессор с частотой 1,2 ГГц, 512 МБ оперативной памяти, 4 ГБ внутреннего хранилища, батарея на 300 мАч, рассчитанная на один день автономной работы. Среди прочего: Bluetooth 4.0, гироскоп, акселерометр, компас и датчик сердцебиения.
Габариты устройства составляют 37.9 x 56.4 x 8.9 мм, а вес – 59 грамм. На выбор два цвета устройства: черный и цвета красного вина. Так же, как и часы от LG, Gear Live защищен по стандарту IP67 и уже доступен для предзаказа в Google Play по цене 199 долларов. Отправление – после 7 июля. О продажах на других рынках пока не сообщается, но вряд ли нас обойдут стороной.
Что касается предмета страсти большинства, Moto 360, то на презентации объявили, что они поступят в продажу позже этим летом. Однако после мероприятия на стенде можно было, что называется, пощупать демонстрационный образец. Он, конечно, не дает какого-либо пользовательского опыта, но привносит капельку понимания, как будет выглядеть круглый интерфейс и как устройство будет сидеть на руке.
Отметим также, что все присутствовавшие на презентации в этом году получили в подарок на выбор LG G Watch или Samsung Gear Live как образец квадратных часов на Android Wear, а позже получат по почте и Moto 360 как образец круглого интерфейса. Следовательно, в скором времени у нас будет возможность ознакомиться с реальными опытами использования.
А вы собираетесь приобрести часы на Android Wear? На какие пал ваш выбор?
Она вам не 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 почти не отличается от своего «старшего брата», за исключением отсутствия некоторых пакетов:
Да, браузер на часах мы в ближайшее время не сможем увидеть из-за отсутствия Webkit. Но серфить на часах будет всё равно неудобно. У нас по-прежнему есть великий и ужасный Android Framework с Support Library и Google Services. Структурных и архитектурных отличий тоже будет мало.
Структура приложения
Предположим, мы решили сделать wearable-приложение. Открыли Android Studio, нажали «New project» и поставили галочку напротив «Wear». Мы сразу обнаружим, что в пакете нашего приложения появилось два модуля: wear и mobile.
Clean architecture?
А почему бы и нет? Это такое же Android-приложение, поэтому архитектурные подходы для него могут быть схожие с Android.
Я использовал такой же стек технологий, который мы используем в Android-приложениях:
У нас два модуля в проекте, и модели данных, скорее всего, будут одинаковые для обеих платформ. Поэтому часть логики и моделей можно вынести в ещё один модуль «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 состоит из трёх частей:
Давайте попробуем создать и сохранить 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-разработки в комментариях.