Smartwatch Companion App Development
Companion app — phone part of "phone + watch" pair. Its task: receive watch data, send configuration, sync state. Sounds simple. In practice — separate architecture layer with async channels, version conflicts, behavior changing based on whether watch connected at request moment.
Where Real Problems Arise
State inconsistency. Watch sent data via DataClient, phone was background and processed message in WearableListenerService.onDataChanged(). User opens app — UI shows old state, because ViewModel doesn't know Room already updated. Classic race condition, reproduces only at specific background processing timing.
Solution: WearableListenerService writes to Room via Repository, ViewModel subscribed to Flow from DAO. No LiveData via EventBus — only reactive chain.
Protocol versioning. Phone app updated, watch app — not yet (user didn't go to Google Play on watch). If DataMap structure changed — watch app crashes on deserialization. Must version protocol: add protocol_version field to each PutDataMapRequest. Phone side gracefully handles old versions.
Background work on Android 14+. WearableListenerService still launched by system on data receive — exception from background service limitations. But if companion app makes HTTP request in response to watch data, need WorkManager with setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST). Direct Retrofit call from service blocked on Android 14 with ForegroundServiceStartNotAllowedException.
Companion App Architecture
WearableListenerService
↓ (coroutine, Dispatchers.IO)
Repository
↓
Room DAO (Flow)
↓
ViewModel (StateFlow)
↓
Compose UI
For configuration (settings user changes on phone, sent to watch) — DataClient.putDataItem() with path /config/v2. Path versioned explicitly.
For real-time commands (pause training, skip track) — MessageClient.sendMessage(). Faster than DataClient, but no delivery guarantee when watch disconnected.
For large files (route database update, media library sync) — ChannelClient. Open channel, transfer via OutputStream, close. Only way to transfer more than few kilobytes without risk of Data Layer limits (100 KB per DataItem).
Watch availability check. Before sending data check CapabilityClient.getCapability(CAPABILITY_NAME, CapabilityClient.FILTER_REACHABLE). If watch unavailable — queue data (Room + WorkManager), send on next connect via CapabilityClient.addListener().
Multi-Platform Support
If watch — Apple Watch, companion built on WatchConnectivity framework (iOS). WCSession.default.sendMessage() for real time, transferUserInfo() for background sync. Logic same, API different.
Flutter apps integrate with Wear OS via wear package or direct platform channels to native WearableListenerService. React Native — similarly via native module.
Timeframes
Companion app for Android + Wear OS with two-way sync: 3–6 weeks depending on data volume and UI complexity. Multi-platform (iOS + WatchOS): separate assessment after TS analysis.