Posted by Breana Tate, Developer Relations Engineer
The Health Services API enables developers to use on-device sensor data and related algorithms to provide their apps with high-quality data related to activity, exercise, and health. What’s more, you don’t have to choose between conserving battery life and delivering high frequency data–Health Services makes it possible to do both. Since announcing Health Services Alpha at I/O ‘21, we’ve introduced a number of improvements to the platform aimed at simplifying the development experience. Read on to learn about the exciting features from Health Services Beta in Android Jetpack that your app will be able to take advantage of when you migrate from Alpha.
Capture more with new metrics
The Health Services Jetpack Beta introduces new data and exercise types, including DataType.GOLF_SHOT_COUNT, ExerciseType.HORSE_RIDING, and ExerciseType.BACKPACKING. You can review the full list of new exercise and data types here. These supplement the already large library of data and exercise types available to developers building Wear OS apps with Health Services. Additionally, we’ve added the ability to listen for health events, such as fall detection, through PassiveMonitoringClient.
In addition to new data types, we’ve also introduced a new organization model for data in Health Services. This new model makes the Health Services API more type-safe by adding additional classification information to data types and data points, reducing the chance of errors in code. In Beta, all DataPoint types have their own subclass and are derived from the DataPoint class. You can choose from:
- SampleDataPoints
- IntervalDataPoints
- StatisticalDataPoints
- CumulativeDataPoints.
DataTypes are categorized as AggregateDataTypes or DeltaDataTypes.
As a result of this change, Health Services can guarantee the correct type at compile time instead of at runtime, reducing errors and improving the developer experience. For example, location data points are now represented as a strongly-typed LocationData object instead of as a DoubleArray. Take a look at the example below:
Previously:
exerciseUpdate.latestMetrics[DataType.LOCATION]?.forEach {
val loc = it.value.asDoubleArray()
val lat = loc[DataPoints.LOCATION_DATA_POINT_LATITUDE_INDEX]
val lon = loc[DataPoints.LOCATION_DATA_POINT_LONGITUDE_INDEX]
val alt = loc[DataPoints.LOCATION_DATA_POINT_ALTITUDE_INDEX]
println("($lat,$lon,$alt) @ ${it.startDurationFromBoot}")
}
|
Health Services Beta:
exerciseUpdate.latestMetrics.getData(DataType.LOCATION).forEach {
// it.value is of type LocationData
val loc = it.value
val time = it.timeDurationFromBoot
println("loc = [${loc.latitude}, ${loc.longitude}, ${loc.altitude}] @ $time")
}
|
As you can see, due to the new approach, Health Services knows that loc is of type List<SampleDataPoint<LocationData>> because DataType.LOCATION is defined as a DeltaDataType<LocationData, SampleDataPoint<LocationData>>.
Consolidated exercise end state
ExerciseState is now included within ExerciseUpdate’s ExerciseStateInfo property. To give you more control over how your app responds to an ending exercise, we’ve added new ExerciseStates called ExerciseState.ENDED and ExerciseState.ENDING to replace what was previously multiple variations of ended and ending states. These new states also include an endReason, such as USER_END, AUTO_END_PREPARE_EXPIRED, and AUTO_END_PERMISSION_LOST.
The following example shows how to check for exercise termination:
val callback = object : ExerciseUpdateCallback {
override fun onExerciseUpdateReceived(update: ExerciseUpdate) {
if (update.exerciseStateInfo.state.isEnded) {
// Workout has either been ended by the user, or otherwise terminated
val reason = update.exerciseStateInfo.endReason
}
...
}
...
} |
Improvements to passive monitoring
Health Services Beta also transitions to a new set of passive listener APIs. These changes largely focus on making daily metrics better typed and easier to integrate. For example, we renamed the PassiveListenerConfig function setPassiveGoals to setDailyGoals. This change reinforces that Health Services only supports daily passive goals.We’ve also condensed multiple APIs for registering Passive Listeners into a single registration call. Clients can directly implement the desired overrides for only the data your app needs.
Additionally, the Passive Listener BroadcastReceiver was replaced by the PassiveListenerService, which offers stronger typing, along with better reliability and performance. Clients can now register both a service and a callback simultaneously with different requests, making it easier to register a callback for UI updates while reserving the background request for database updates.
Build for even more devices on Wear OS 3
Health Services is only available for Wear OS 3. The Wear OS 3 ecosystem now includes even more devices, which means your apps can reach even more users. Montblanc, Samsung, and Fossil are just a few of the OEMs that have recently released new devices running Wear OS 3 (with more coming later this year!). The newly released Pixel Watch also features Fitbit health tracking powered by Health Services.
If you haven’t used Health Services before, now is the time to try it out! And if your app is still using Health Services Alpha, here is why you should consider migrating:
- Ongoing Health Services Development: Since Health Services Beta is the newest version, bug fixes and feature improvements are likely to be prioritized over older versions.
- Prepares your app infrastructure for when Health Services goes to stable release
- Improvements to type safety - less chance of error in code!
- Adds additional functionality to make it easier to work with Health Services data
You can view the full list of changes and updated documentation at developer.android.com.
- David Stevens, Google Ads API Product Manager
