This chapter will introduce you to new ways of working with sensors. We will learn about the new Google Fit platform and how it can be used to manage fitness sensor data efficiently. We will explore the different APIs provided by the Google Fit platform. In this chapter, we will learn new concepts, such as how we can request the automated collection and storage of sensor data in a battery-efficient manner, without your app being in the background all the time. We will also learn how to get data from a remotely connected device, such as Android Wear. In this chapter, we will mostly deal with fitness sensors and as a learning exercise, we will develop a fitness tracker application that will collect and process your fitness data.
The topics you will learn about in this chapter are:
- What is the Google Fit platform?
- How the Android fitness APIs, Rest APIs and Google Fitness Store fit together into the Google Fit platform
- The details of six Android fitness APIs and the fundamentals of the Android fitness platform
- The user authorization process, required fitness scopes and permissions to use Android fitness APIs, and how to register your application with the Google developer console
- The implementation of Android fitness APIs inside the fitness tracker application, which will collect and process your fitness sensor data
- Getting the list of available fitness data sources on local or remotely connected devices and getting live fitness data from them
- Requesting the automated storage of fitness sensor data in a battery-efficient manner and retrieving fitness history data for a particular date range
Google Fit is a platform that allows developers to manage user fitness data effectively. Developers, on behalf of users, can upload, download, and persist their fitness data to a central repository in the cloud. This fitness data can range from simple height and weight numbers to individual step information. The fitness data can come from various data sources, such as fitness apps, Android sensors, Android wear sensors or any other device that can connect and upload data to the Google Fit platform. The data sources can be present either locally on the phone or can be in remote devices in the form of any app or hardware sensors. This fitness data management is done using three key components, as shown in the following diagram: the first is the Google Fitness Store, which resides in the cloud; the second are web-based REST APIs; and the third are Android Fitness APIs which are on the Android devices. Now let's discuss each one of them separately in detail.
All user fitness data is stored in the cloud on servers maintained by Google. Both REST APIs and Android Fitness APIs can manage data that is independently stored inside Google Fitness Store. If the user upgrades his Android phone, or removes any old fitness app or devices, then this data is persisted in the Google fitness store. This fitness data can be accessed from any platform, including Android, iOS or the Web, using one of these two APIs, but the user has to grant permission to the app before using either of these two APIs.
REST APIs are provided to support platforms other than Android. They can be used in an iOS native app or any web-based app. They are RESTful-based web services and use JSON for communications. They use the OAuth 2.0 protocol for authorization from users. REST APIs allow us to read, write and delete fitness data, but have some limitations when compared to Android Fitness APIs, such as not being able to discover fitness devices connected via Bluetooth and read their live sensor data streams. A detailed discussion and implementation of REST APIs is out of the scope of this book. We will mostly focus on Android Fitness APIs in this chapter.
Android Fitness APIs are part of Google Play Services, which comes as a part of the Android SDK. These APIs provide access to fitness data from two different sources: the first is a local source, which is any fitness Android app installed on the phone or any local sensor of the phone, while the second is a remote source, which is any fitness app or sensor installed on any other device. The Google Fitness platform doesn't differentiate between local or remote sources; it has its own categorization of data sources, which we will discuss in the coming sections. Android Fitness APIs can be used in Android applications after getting the required permissions from the user. They provide access to read, write, and delete fitness data. It also allows developers to create new fitness data types, scan for new BLE (Bluetooth Low Energy) fitness devices, and connect to them to get fitness data. There are six Android Fitness APIs to support this functionality. We will discuss each one of them in detail.
The Sensors API provides a list of available data sources that can provide live data streams. These data sources can be on a local device or on connected devices. It also allows the adding and removing of data listeners on a data source to read the live data stream coming from a sensor. This API is useful when we need to process live sensor fitness data. We will look at the implementation details in the fitness tracker application discussed in the second half of the chapter.
The Recording API allows your app to request the automated storage of sensor data in a battery-efficient manner by creating subscriptions. A subscription is a form of request, which instructs the Recording API to save the data from different types of data sources or data types. It doesn't matter if your app is active or not; once a data type is subscribed successfully, it's the responsibility of the Google Fit platform to save the data of the requested data type until that data type is unsubscribed. The Recording API allows three major tasks: adding subscriptions, removing subscriptions, and listing active subscriptions. The data saved using Recording API subscriptions can be read using the History API. This API is useful when your app needs fitness data continuously in a battery-efficient manner and doesn't want to stay in the background forever to manage the storage of data.
The History API allows your app to read, write, and delete fitness history data. It supports the batch importing of data from the fitness history. Through the History API, your app can read the data generated by any fitness app or sensor, but it can only delete the data generated by your own app. This API is useful when we need fitness data from any past date. We will look at the implementation details in the fitness tracker application discussed in the second half of the chapter.
Sessions are time intervals during which users perform any fitness activity, such as a run, a bike ride, or a game. Sessions help organize data and perform detailed or aggregate queries for a fitness activity. Sessions consist of a start time, an end time, a user-friendly name, a description, an activity type, and a unique identifier. Sessions do not contain fitness data themselves. Sessions can be considered as metadata objects with information that helps you query data from the fitness store later. The sessions API allows your app to create sessions in the fitness store using real-time data, or data you previously collected using the sensors API or from outside Google Fit. The API also allows your app to read, write, and delete the session data. This API is useful when we need to work with fitness metadata.
The Bluetooth Low Energy(BLE) API allows your app to scan for any available BLE devices. Once a BLE device is found, the API also allows your app to claim the device. Once it's successfully claimed, the device can be used to get data via the Sensor API or Recording API. This API is useful when your app needs to connect to any new BLE device.
The Config API allows your app to create your own custom data type for your private app usage. This custom data type is not available to other apps. It also allows your app to retrieve shareable data types added by other apps or custom data types added by your app. This API is useful when there is no existing data type available that fits your needs and you want to create a new data type.