Wear OS home workouts with Health Services

[ad_1]

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:

  1. Screen interactive
  2. 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.

Illustration of data delivery for both screen interactive and screen ambient/off with Health Services, showing batching in the latter case.
Illustration of data delivery in interactive vs non-interactive modes

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.

Illustration of data delivery using Health Services and the new BatchingMode, showing how data is still delivered at a 5s interval with the screen off
Illustration of data delivery with HEART_RATE_5_SECONDS BatchingMode

Configuring BatchingMode

As with most things in Health Services, a capabilities-based approach is taken, so the first step is to determine which additional BatchingMode definitions are supported:

Once support for the required batching mode has been confirmed, specify that it should be used, via the new property in ExerciseConfig:

Notice that although the new batching mode is aimed at providing guarantees only for the heart rate reporting frequency, additional metrics can be included as per normal. These will be delivered at least as often as the default batching behavior.

In the example above you can see the aggregate data type of TOTAL_CALORIES, as it could be useful to show the total calorie expenditure in the final summary screen.

Performance considerations

It’s worth pointing out that while this is perfect for the home workout app use case, by the very nature of the new batching behavior, the app will be woken up more often. As the name implies, HEART_RATE_5_SECONDS aims to deliver data every 5 seconds, which is a great tradeoff between near-real time data, and battery savings.

For standalone workout apps, you should use Health Services with the default behavior — use HEART_RATE_5_SECONDS only when absolutely necessary, to ensure the best battery performance.

Bringing your devices together

The HEART_RATE_5_SECONDS batching mode represents the first step for Health Services into supporting a greater range of use cases, in a world of increasingly interconnected workout devices, to ensure they can work better together.

A related area for home workout apps is discovery and installation: Once you’ve got your Wear OS app published, you want it to be easy to discover, install and launch from other connected devices, to ensure maximum ease of use for your users.

Some valuable additions to the user experience could include:

  • Automatically detecting the Wear OS device from the phone app
  • Detecting whether the app is already installed on the Wear OS device and providing the user with the option to do so.
  • Launching the app automatically on the watch when the user starts a workout on the phone.

Horologist is a library for Wear OS which — amongst many other things — can provide this functionality.

As an example, adding detection for the Wear OS device and app is as simple as:

Each connected device shows some details about its status:

From here, the phone app could display a button which when clicked would install the Wear OS app, using:

And then launched using:

Incorporating these conveniences into the watch and phone app help bring a smooth experience to the user.

Streaming data to the main device

With the app installed and launched, we need to consider how best to transmit data to the main device, be that a tablet, phone or TV.

Some options include:

  • Bluetooth LE (low energy) — using standard Android Bluetooth APIs to transmit to the main device.
  • Network — utilizing the Wifi connection on the watch.
  • DataLayer Connectivity — ChannelClient, part of the Wear DataLayer, allows the phone and watch to communicate using streams.

The most appropriate choice for your app depends on the specifics of your app.

Summary

We looked at how Health Services can help bring Wear OS into your workouts, and also some techniques for allowing the phone and watch to work better together.

Keep an eye out for further enhancements to Health Services and Batching Modes, and it would be great to hear your experiences via the comments below!

Code snippets license:

Copyright 2023 Google LLC.
SPDX-License-Identifier: Apache-2.0

[ad_2]

Source link


Leave a Reply

Your email address will not be published. Required fields are marked *