Разработка компаньон-приложения для умных часов
Компаньон-приложение — это телефонная часть связки «телефон + часы». Его задача: принимать данные с часов, отдавать конфигурацию, синхронизировать состояние. Звучит просто. На практике — это отдельный слой архитектуры с асинхронными каналами, конфликтами версий и поведением, которое меняется в зависимости от того, подключены ли часы в момент запроса.
Где возникают реальные проблемы
Несогласованность состояния. Часы отправили данные через DataClient, телефон был в фоне и обработал сообщение в WearableListenerService.onDataChanged(). Пользователь открывает приложение — UI показывает старое состояние, потому что ViewModel не знает, что Room уже обновился. Классическое race condition, которое воспроизводится только при определённом тайминге фоновой обработки.
Решение: WearableListenerService пишет в Room через Repository, ViewModel подписана на Flow из DAO. Никаких LiveData через EventBus — только реактивная цепочка.
Версионирование протокола. Телефонное приложение обновилось, часовое — ещё нет (пользователь не заходил в Google Play на часах). Если структура DataMap изменилась — часовое приложение крашится при десериализации. Обязательно версионируем протокол: добавляем поле protocol_version в каждый PutDataMapRequest. Телефонная часть обрабатывает устаревшие версии gracefully.
Фоновая работа на Android 14+. WearableListenerService всё ещё запускается системой при получении данных — это исключение из ограничений фоновых сервисов. Но если компаньон-приложение делает HTTP-запрос в ответ на данные с часов, нужен WorkManager с setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST). Прямой вызов Retrofit из сервиса заблокируется на Android 14 с ForegroundServiceStartNotAllowedException.
Архитектура компаньон-приложения
WearableListenerService
↓ (coroutine, Dispatchers.IO)
Repository
↓
Room DAO (Flow)
↓
ViewModel (StateFlow)
↓
Compose UI
Для конфигурации (настройки, которые юзер меняет на телефоне и они должны прийти на часы) — DataClient.putDataItem() с путём /config/v2. Путь версионируем явно.
Для команд реального времени (пауза тренировки, переключение трека) — MessageClient.sendMessage(). Он быстрее DataClient, но не гарантирует доставку при отключённых часах.
Для больших файлов (обновление базы маршрутов, синхронизация медиатеки) — ChannelClient. Открываем канал, передаём через OutputStream, закрываем. Это единственный способ передать больше нескольких килобайт без риска попасть в лимиты Data Layer (100 КБ на один DataItem).
Проверка доступности часов. Перед отправкой данных проверяем CapabilityClient.getCapability(CAPABILITY_NAME, CapabilityClient.FILTER_REACHABLE). Если часы недоступны — ставим данные в очередь (Room + WorkManager), отправляем при следующем подключении через CapabilityClient.addListener().
Поддержка нескольких платформ
Если часы — Apple Watch, компаньон строится на WatchConnectivity framework (iOS). WCSession.default.sendMessage() для реального времени, transferUserInfo() для фоновой синхронизации. Логика та же, API другой.
Flutter-приложения интегрируются с Wear OS через wear пакет или прямые platform channels к нативному WearableListenerService. React Native — аналогично через native module.
Сроки
Компаньон-приложение для Android + Wear OS с двусторонней синхронизацией: 3–6 недель в зависимости от объёма данных и сложности UI. Мультиплатформенный вариант (iOS + WatchOS): отдельная оценка после анализа ТЗ.