Wear OS home workouts with Health Services
How metrics from connected Wear OS devices can enhance the workout experience
When building health and fitness apps on Wear OS, Health Services provides great functionality covering many scenarios.
One area that has seen an explosion of interest in recent years is home workouts, with apps for a diverse range of exercise types and styles. This blog post takes a look at how to incorporate Wear OS support in home workout apps, to further enhance the experience for users.
Workouts in a connected world
Typically for an at-home workout, the user experience is centered around a phone, tablet or TV, on which the main instructional content is shown.
The Wear OS app serves as a companion: Using the sensors on the device, data, such as heart rate, is streamed to the main device, where it is shown on the screen.
ExerciseClient for all your exercise needs
With the launch of Beta03, Health Services now provides enhanced support for connected home workouts, through the introduction of BatchingModes, as will be explained below.
Health Services is already well-established at tracking workouts of many different types, and provides a whole bunch of workout-related functionality.
In the standalone scenario, for example, if you were building a running app to track your run outdoors, ExerciseClient provides the following functionality:
- Active duration tracking, across different states (active/paused etc)
- Statistical metrics built-in, such as average pace, total distance
- Auto-pause
- And many more…
However, the key difference between a running scenario and the home workout scenario is that in the former, the Wear OS device is working standalone, whereas in the latter, the device is a companion.
To see how Health Services Beta03 can help with this scenario, it’s first necessary to look at some background on the different operating modes of ExerciseClient:
Battery savings and data batching
The scenario described could actually be a challenge for ExerciseClient, and here’s why: ExerciseClient works in two modes, depending on the screen state:
- Screen interactive
- Screen in ambient/off
Let’s look at each in turn:
- When the screen is interactive: Health Services provides high-frequency updates to your app. So if a sensor is operating at 1Hz, you’ll typically be receiving individual readings at this rate.
This is great for your app and the user, as you’re getting near instantaneous data on your progress or performance. - When the screen is ambient/off: This occurs typically when you’re not looking at the device. In this scenario, by default, Health Services switches to batching mode.
This means that the data from that 1Hz sensor will continue to be collected, but won’t immediately be delivered to your app. Why? Because this allows your app and main processor to sleep, resulting in battery savings for your users.
However, the moment the user interacts with their device again, and the buffered data will be delivered — and your users will be none the wiser!
This default behavior of Health Services allows apps such as running apps to operate very efficiently, sleeping for minutes at a time with no loss of data collection.
The companion challenge
Unfortunately, if you look back at our scenario, this is a problem: In a home workout, metrics from Wear OS are displayed on another device, such as the phone or TV. Typically the user won’t be looking at their watch whilst in the workout — they’ll be focussed on the primary device, for both instruction and overlaid metrics.
After a short while, the watch app would go to sleep, Health Services would start batching data, and the user would no longer see regularly updated metrics on the main device.
Instead, they’d get updates less frequently, when the buffer is full and the app is forced to wake up as the buffer is flushed. This is good for battery power but not ideal for user experience
Introducing BatchingMode
With Health Service beta03 comes the addition of different BatchingMode support. BatchingMode allows your app to override the default batching behavior described above to get data deliveries more often. This recognizes that whilst the default behavior is great for most scenarios, it won’t be ideal in all cases.
The first batching mode released is aimed specifically at the home workout scenario: BatchingMode.HEART_RATE_5_SECONDS, though the API has been designed with the future in mind and further BatchingMode definitions may be added in due course.
Instead of heart rate batching for potentially minutes at a time when the screen leaves interactive mode, BatchingMode.HEART_RATE_5_SECONDS guarantees that heart rate data will continue to be delivered regularly throughout the workout.
Note that just as with regular batching, the sampling rate is unaffected, so the app will still typically get heart rate data at 1Hz — just delivered every 5 seconds when not in interactive mode.
Configuring