Just over a week ago, the Google Fit Preview SDK went available to all Android developers that own Nexus 5 or Nexus 7 2013 devices. (You can start developing right away: https://developers.google.com/fit/)

Google Fit provides a single set of APIs for apps and device manufacturers to store and access activity data from fitness apps and sensors on Android and other devices.

What does it mean? Imagine you have Bluetooth Low Energy (BLE) heart rate monitor device along with one of the new smart cycling sensors attached to your bike. These 2 devices are then hooked up with the Android application that makes use of the new Google Fit SDK. Prior to the Fits release, managing and representing data from different devices was quite a challenge.

With Google Fit, accomplishing such tasks became really easy. We can pick which sensors, from which device should our app use, and it’s all just a few lines of code away. In order to present how it can be achieved, we need to understand how the new Fit SDK is designed.

1. Data Types

Think of them as things you can measure in your fitness activities. They define the format of the values inside data points. They’re also used to subscribe/unsubscribe to Data from sensors. A data point can represent:

  • An instantaneous reading or observation (like the user’s current Location, Speed or Weight)
  • An aggregate with statistics over a time interval (like user’s Weight Summary – Average, Maximum and Minimum values over a given period of time)

There are different predefined Data Types. To make use of our Heart Beat Monitor and Smart Cycling devices in our app, we can use:

  • DataType.HEART_RATE_BPM – where each data point represents an instantaneous measurement of the heart rate in beats per minute.
  • DataType.CYCLING_PEDALING_CADENCE – here each data point represents an instantaneous measurement of the pedalling rate in crank revolutions per minute.

These are just 2 Data Types, but many more are available (according to the needs of particular use case scenarios). The full list can be found here: https://developers.google.com/fit/android/data-types

In addition to predefined Data Types, we can create new ones, suited to our needs.

2. Subscriptions

When we’ve chosen the Data Types we’re going to use in our app, we can start recording their readings. The Recording API enables your app to request automated storage of sensor data in a battery-efficient manner by creating subscriptions. A subscription is associated with an Android app and consists of a fitness data type or a specific data source.

In other words, the only thing we need to do to record specific Data Type is to subscribe to their readings, and all the data will be recorded for us.

For example, if we want to start recording the Heart Beat readings, all we need to do is simply subscribe to the relevant data type:

PendingResult<Status> pendingResult = Fitness.RecordingApi.subscribe(mClient, DataTypes.SPEED);

To stop recording, we simply unsubscribe from that Data Type:

PendingResult<Status> pendingResult = Fitness.RecordingApi.unsubscribe(mClient, DataTypes.SPEED);

Quite convenient, isn’t it?

All gathered data is then available within the History API. We’ll get to that later.

Let’s go further with our recording scenario. Assume that we’ve already recorded the HEAR_RATE_BPM, CYCLING_PEDALING_CADENCE, and with the use of Android Devices GPS – SPEED, LOCATION and DISTANCE_DELTA (which allows us to know the total distance travelled, by summing up all delta readings).

After having these data recorders, that would be very nice to group them, into a single workout session. Google thought about that, introducing Sessions.

3. Sessions

They help you organize workouts by easily adding time interval metadata to fitness data in the fitness store. There are several reasons why your app should use sessions with Google Fit:

  • You do not need to implement your own metadata schema and storage.
  • You can interact with other apps using session intents.
  • You can show available sessions along with the app that created each session.
  • Other apps can launch your app to show details about sessions created by your app.

Creating sessions is a very handy way of grouping all gathered fitness data during a given time interval, into a single, easily accessible data structure.

Sessions can be created at a later time, from any Data Types recorded.

In our particular scenario, creating a session after a workout will give us access to data from Android GPS readings, Heart Beat Monitors and Bike Smart Sensors.

This session can be then presented within the app, stored in cloud storage, or be available for other apps.

The availability of sessions between different apps is a new feature, that allows the creation of new types of statistic or summary apps, that gather data from all other fitness apps that are installed on the device.

Starting and stopping sessions is pretty straightforward. After starting recording (see point 2 – Subscriptions), all we have to do is:

Accessing Raw Sensor Data

It is used to get real-time sensor reads, to show them to the user. The sensors API does not persist any data. We have to use Recording API to persist data gathered from Raw Sensors Data API.

Different devices may have the same sensor types. Thanks to Sensors API, we can get specific data from a specific device and its specific sensor.

Sensors API is a great place to show how the Google Fit magic happens. Obtaining real-time reading is extremely easy:

Getting all kinds of fitness data in just a few lines of code. That’s handy.

5. Bluetooth Sensors

If we have Bluetooth Low Energy sensors that implement a standard GATT Profile, they can also be used with the Google Fit API. Finally, we can easily search for all the available BLE devices, a claim which one to use and immediately start using data from the device.

That’s a huge change, as for the first time in history we’re able to gather data from all different sensors, using a single API. Unification will surely allow for new workout data measurements and analysis to arise.

If your BLE sensor does not have the GATT Profile, it can still be used, by extending the ApplicationSensorService class and managing the sensor use manually.

6. Fitness History API

It enables your app to perform bulk operations on the fitness store: inserting, deleting, and reading fitness data. The data request can specify multiple data types to return, effectively combining multiple data queries into one call.

Using History API we can also create sessions from already recorded data, and make them available for other apps to be used. It’s a big change, as Sessions recorded by other apps (that are relevant to your app profile) can also be used within your own app. It will allow giving the user the best feedback possible, from all his fitness activities, recorded using different apps.

To sum it up.

We’re very excited about the new possibilities Google Fit SDK gives to developers and users. It’s a big step to unify data from different sensor technologies, into a single insightful summary, that will allow new types of inferring, leading to a better understanding of our workouts, training, and individual needs of every sportsman.