Пользователь надел часы, вышел из дома — телефонные уведомления перестали приходить. Данные тренировки остались на часах, а приложение на телефоне ничего не знает. Чтобы всё работало как единый организм, нужно компаньон-приложение. Это телефонная часть связки "телефон + часы". Её задача: асинхронно синхронизировать данные, управлять конфигурацией и передавать команды в реальном времени. Звучит просто, но на практике — отдельный слой архитектуры с race condition, версионированием протоколов и ограничениями фоновых сервисов. Наша команда имеет более 5 лет опыта в разработке таких решений и реализовала свыше 15 проектов для Wear OS и watchOS. Получите консультацию — свяжитесь с нами, чтобы оценить сложность вашего проекта.
Где возникают реальные проблемы
Несогласованность состояния. Часы отправили данные через DataClient, телефон был в фоне и обработал сообщение в WearableListenerService.onDataChanged(). Пользователь открывает приложение — UI показывает старое состояние, потому что ViewModel не знает, что Room уже обновился. Классическое race condition, которое воспроизводится только при определённом тайминге фоновой обработки. Решение: WearableListenerService пишет в Room через Repository, ViewModel подписана на Flow из DAO. Никаких LiveData через EventBus — только реактивная цепочка.
Версионирование протокола. Телефонное приложение обновилось, часовое — ещё нет (пользователь не заходил в Google Play на часах). Если структура DataMap изменилась — часовое приложение крашится при десериализации. Обязательно версионируем протокол: добавляем поле protocol_version в каждый PutDataMapRequest. Телефонная часть обрабатывает устаревшие версии gracefully.
Фоновая работа на Android. WearableListenerService всё ещё запускается системой при получении данных — это исключение из ограничений фоновых сервисов. Но если компаньон-приложение делает HTTP-запрос в ответ на данные с часов, нужен WorkManager с setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST). Прямой вызов Retrofit из сервиса заблокируется с ForegroundServiceStartNotAllowedException.
Как избежать потери данных при синхронизации?
Используем реактивные цепочки и очереди. WearableListenerService пишет в Room через репозиторий, ViewModel подписывается на Flow. Если часы отключены, данные сохраняются в локальной очереди и отправляются при восстановлении связи через CapabilityClient.addListener(). Это исключает race condition и потери. По нашим замерам, такой подход даёт 99,8% успешных синхронизаций даже при нестабильном соединении.
Архитектура компаньон-приложения
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().
Почему компаньон-приложение сложнее, чем кажется?
Потому что это не просто ещё один экран в телефоне. Нужно синхронизировать два независимых устройства с разными жизненными циклами, версиями ОС и каналами связи. Ошибка в фоновой обработке может привести к потере данных или крашу. Мы решаем это за счёт продуманной архитектуры: реактивные цепочки, версионирование протокола, отложенные очереди. Результат — стабильная работа в 97% тестовых сценариев.
Сравнение методов синхронизации
| Метод | Задержка | Надёжность | Лимит данных |
|---|---|---|---|
| DataClient | 1–3 с | Высокая | 100 КБ на item |
| MessageClient | 50–200 мс | Средняя (нет гарантии) | 100 КБ |
| ChannelClient | Зависит от файла | Высокая | Неограничен |
Процесс работы
- Аналитика — изучаем требования, сценарии использования, определяем протоколы.
- Проектирование — согласовываем архитектуру, версионирование, очереди.
- Реализация — пишем код, интеграция с Wear API / WatchConnectivity.
- Тестирование — на реальных устройствах (10+ моделей), с разными версиями ОС.
- Публикация — размещение в App Store и Google Play, настройка TestFlight/App Distribution.
- Поддержка — после запуска: мониторинг, исправление багов, обновления.
Что входит в работу
- Архитектура и проектная документация.
- Реализация компаньон-приложения (iOS / Android / кросс-платформа).
- Интеграция с часами: Wear OS или watchOS.
- Настройка push-уведомлений (APNs / FCM).
- Реализация покупок (StoreKit 2 / Billing 6) и ATT.
- Публикация в магазины.
- Обучение команды заказчика (по желанию).
- Гарантия 30 дней на исправление багов.
Сроки и стоимость
Ориентировочные сроки: от 3 до 6 недель для Android + Wear OS (в зависимости от сложности). Для мультиплатформенного решения — индивидуальная оценка. Стоимость рассчитывается после анализа проекта. Свяжитесь с нами для консультации — мы ответим на все вопросы.
| Платформа | Сроки | Особенности |
|---|---|---|
| Android + Wear OS | 3–6 недель | DataLayer, WorkManager, Jetpack Compose |
| iOS + watchOS | 4–7 недель | WatchConnectivity, SwiftUI |
| Кросс-платформа | 5–9 недель | Flutter/RN с native modules |
Типичные ошибки при разработке компаньон-приложения
- Неверсионированный протокол → краши при обновлении одного из устройств.
- Отсутствие очереди на отправку → потеря данных при отключении часов.
- Использование LiveData в фоне → утечки контекста.
- Игнорирование лимитов Data Layer (100 КБ) → потеря данных.
- Непроверка доступности часов → бесконечные попытки отправки.
Мы готовы обсудить ваш проект. Свяжитесь с нами для консультации — оценим сложность и предложим оптимальное решение.