In the past few years we have seen mobile and its apps rise and shine transforming many industries in its wake. However, the growth in health and fitness category has been less spectacular at 49% compared to overall mobile app industry which grew at 115% in the year 2013 (source Flurry Analytics).
A few years ago Microsoft and Google attempted to make inroads into the health and fitness sector by bringing web based products to store and maintain health and fitness information like MS HealthVault and Google Health with not so spectacular results.
Next came innovations by Fitbit in the wearables sector for activity tracking, in 2011 and 2012 they introduced first wireless activity trackers to sync using Bluetooth. This was followed by the entry of Jawbone into health sector with its announcements of Up wristband and accompanying app. These have had better success resulting in many startups joining the wearables product bandwagon.
Late to the stage almost last ones on the scene were the giants Google, followed by Apple and finally followed by Microsoft. And hence we saw Google make forays into wearables technology in the form of Android 360, Apple announcing its wristwatch to be available sometime in 2015 and finally out of nowhere Microsoft launching its wearable fitness device - Microsoft Band at an interesting price and that too with lots of features and cross platform compatibility with Andriod, iOS and WP. It is yet to be seen who will be the final winner in this world of wearables.
However, so far these wearable products have stayed in isolation. You buy a wearable product then you use their apps to track and monitor data and that is it. There hasn't been much of a cross connection or pulling in of this valuable data to do some predictive analysis on top of these. The next logical step fitness users have been looking forward to is taking the data collected by these wearable products to next level. There has been no standard or framework by mobile platforms in this area.
So we saw Validic rise to the challenge and focus on powering the digital health ecosystem, with their core focus on providing one to many connection that allows health care companies to access mobile and digital health data across devices and platforms. However, so far the efforts in this direction have been few and scattered.
So finally the pieces seem to be falling together with past two month events -
- First Apple takes the initiative to introduce its framework Apple HealthKit for centralizing the data storage of personal health information and to make it available for collaboration by many through its proven and established mobile apps ecosystem.
- Second Google rolls out its own framework Google Fit for centralizing all of the fitness and health data from your apps and devices in one place.
The general concepts behind both these are similar -
- At the top we have a central health data store
- Next we have a standardized API to access and write to this central health data store
- Next we have native sensors in phones that are capable of storing health tracking information into the central health data store directly
- A set of permission to control who or what can access this data
- Finally a native app equipped with dashboard to show reports, charts based on the health data stored in central health data store.
Let us take a closer look at various aspects and components and compare them -
- Definition
- Google Fit is an open ecosystem that allows developers to upload fitness data to a central repository from where users can access their data from different devices and apps.
- Apple HealthKit framework provides a structure that apps can use to share health and fitness data. It is designed to manage data from a wide range of sources, capable of working with health and fitness devices.
- Data Storage
- Google Fit makes use of central data storage, this fitness store is a cloud service that is transparent to clients and available across platforms and devices. It can store data from a variety of devices and apps.
- HealthKit makes use of a central data storage that is local to the user's device and not stored in cloud. This store is also encrypted when the device is not unlocked. The data in this store is also not synced with any other devices
- Data framework
- In Google Fit, Sensor framework defines high level representations for sensors, fitness data types, data points, and sessions. These representations make it easy to work with fitness store on any platform.
- Data Sources - these represent sensors - hardware or software sensors (defined in apps). These would have a name and the type of data collected.
- Data Types - these represent different kinds of fitness data, step count or heart rate. These help establish a schema to help different apps understand each other's data. These consist of a name and an ordered list of fields, where each field represent a dimension. For example, a data type for glucose may contain two fields - fasting and non-fasting and a data type for height contains only one field.
- Data Points - these are used to read raw data from a data source and record this fitness data into the fitness store. These consist of a time-stamped array of values for a data type.
- Datasets - these represent a set of data points of the same type from a particular data source over some time interval. Datasets are used to insert data into fitness store and queries to read from the fitness store also return Datasets.
- Sessions - these represent a time interval during which users perform certain activity, like running, biking etc. These are used to perform aggregate queries on fitness store.
- HealthKit framework data types constrain the types of data and units to a predefined list. This is done to ensure sharing of data between apps happen in a meaningful way. As a result of this developers cannot create their own custom data types.
- All objects in HealthKit store are subclasses of HKObject class, allowing them to share common properties like -
- UUID - a unique identifier for an entry
- Source - The source of the data which could be a device storing data directly or an app, this information is set automatically by HealthKit.
- Meta-data - a dictionary of additional information, with predefined keys and custom keys to extend a given HealthKit object.
- HealthKit objects are divided into two main groups - characteristics and samples.
- Characteristics objects represent data that do not undergo changes like user's birth date, blood type and biological sex. This type of data is entered by the device user using Health app and cannot be changed by any other application.
- Sample objects on the other hand represent data at a particular point in time and can be updated by applications. All sample objects are subclasses of HKSample class, allowing them to share common properties like -
- Type - identifies the sample type example - sleep analysis, height, step count etc.
- Start Date - this will be the starting time for the sample.
- End Date - this will be the ending time for the sample, it will be same as start date in cases where the sample represents data point at a single point in time and will be different if the sample represents data collected over a period of time.
- Samples are further divided into four different sample types.
- Category samples - represents data that can be classified into a finite set of categories. In iOS8, there is only one type of category sample - sleep analysis.
- Quantity samples - this represent the most common data type in HealthKit and are used to store data that can be stored as numeric values like - user's height and weight, number of steps taken, user's temperature, and their pulse rate.
- Correlations - these represent composite data containing one or more samples. iOS8 HealthKit uses correlations to represent food and blood pressure.
- Workouts - these represent physical activity, like running, swimming, or even play. Workouts often have type, duration, distance, and energy burned.
- Permission set
- Google Fit Permissions - here you are required to use OAuth 2.0 to authorize requests. You need to exclusively make request to read or write fitness data. You make use of OAuth scopes that map to three permission groups with separate read or write privileges - activity, location and body. Each permission group grants apps access to a set of data types.
- Your application asks Google for a particular scope of access.
- Google will display a consent screen to the user
- If user approves then Google gives a short lived access token
- Now you make your requests for data attaching the access token to request.
- Example of scope - https://www.googleapis.com/auth/fitness.body.read and data types included in this scope are
- com.google.heart_rate.bpm
- com.google.heart_rate.summary
- com.google.height
- com.google.weight
- com.google.weight.summary
- HealthKit Permissions - Here you need to exclusively make separate request to read or to share each type of data. These are fine grained authorizations.
- To request for authorizations you use requestAuthorizationToShareTypes:readTypes:completion: method.
- You can create new sample data only if user grants permission to share a data type.
- Your app should check to see if it's authorized to share data using the authorizationStatusForType: method.
- You can query HealthKit data only if the user grants permission to read a data type.
- There is no way of knowing if the user has declined your request to read any data type.
- If users denies read permission for any data type then it behaves as if there is no data of the requested type in the store.
- Usage
- Using Google Fit is a bit involved process.
- Register your application using the Google Developers Console.
- Activate the Fitness API in the Google Developers Console.
- Ask Google for a particular scope of access
- Google displays a consent screen to user
- If the user approves you get a short lived access token
- Your application uses this access token to interact with Google Fit API.
- Using HealthKit is very straight forward.
- Enable the HealthKit capabilities in XCode
- Check to see if HealthKit is available on the device by calling isHealthDataAvailable method.
- Instantiate an HKHealthStore object for your app. This will be the primary interface with the HealthKit database.
- Request authorization to access HealthKit data.
- Check to see if authorized to share data.
- Querying data
- Google Fit queries are provided for by a very simple and generic api interfaces. These are organized by resource types.
- Users.dataSources - These queries are used to access raw data coming from sources like hardware sensors on local or companion devices. This contains enough information to uniquely identify its data, including the hardware device and the application that affected the data along with other metadata. These are accessible using - https://www.googleapis.com/fitness/v1/users/userId/dataSources.
- Users.dataSources.datasets - These provide access to a representation of projection container for data points. These do not carry info of their own but rely on underlying data points. These are accessible using - https://www.googleapis.com/fitness/v1/users/userId/dataSources/dataSourceId/datasets.
- Users.sessions - These contain metadata like user friendly name, and time interval information etc. There is again no persistent data associated with this resource. These are accessible using - https://www.googleapis.com/fitness/v1/users/userId/sessions.
- HealthKit provides for a number of methods to query its data
- Direct Method Calls - These methods found in HKHealthStore class provide direct access to Characteristic data only in HealthKit store.
- Sample query - These are general purpose queries, used to access any type of sample data. These are found in HKSampleQuery class.
- Observer query - Long running queries that monitor HealthKit store and alerts when there are any changes to matching samples. Accessible using HKObserverQuery class
- Anchored object query - this type of query is used to access data in deltas. So first time it will get all the data and next time onwards it will provide the delta of additions and changes. Accessible using HKAnchoredObjectQuery class.
- Statistics query - You use these queries to perform statistical calculations like sum, minimum, maximum, or average value over the set of matching samples. Accessible using HKStatisticsQuery class
- Statistics Collection query - You can use these type of queries to run multiple statics calculations over a series of fixed length time intervals. Accessible using HKStatisticsCollectionQuery class.
- Correlation query - use this query to perform complex searches of the data contained in correlations using HKCorrelation class.
- Source query - You use these query to search for sources (apps and devices) that have saved a matching data. Accessible using HKSourceQuery class
- App
- Google Fit has its own app that provides a comprehensive view of users fitness. It is compatible with all of the android wear devices. You can access this app from all mobile devices, and tabs.
- Apple's HealthKit app is bundled in with iOS8, and appears simply as Health on the iPhone home screen, and provides easy to access dashboard where you can monitor important health metrics on a daily basis. It also helps users to examine fitness trends over a longer period of time.
- Cross Platform Availability
- Google Fit - most available since data store maintained in cloud
- Rest API ensures availability on all google and none google devices
- Rest API ensure availability on all PC
- Health Kit - very restricted.
- Only available on iPhone device
- Not available on iPad
- Data cannot be access from Mac
- Data cannot be made available remotely
- Cannot sync between multiple phones.
In conclusion both seems to have done an excellent job when it comes to introducing a standard way of sharing fitness tracking information. They both have areas that need maturing. If Google Fit's strength lies in its cloud enabled data store coupled with cross platform availability enabled using rest based api then Apple's HealthKit is more secure with encrypted local storage isolation and much more mature, detailed, predefined data structure and querying interface.
References -
- http://www.flurry.com/blog/flurry-insights/health-and-fitness-apps-finally-take-fueled-fitness-fanatics#.VG4JsMmvP43
- https://developer.apple.com/healthkit/
- http://www.theverge.com/2014/6/2/5772074/apple-healthkit-ios-8-announcement
- http://mashable.com/2014/06/27/healthkit-google-fit-apps/
- http://www.pcadvisor.co.uk/features/software/3532886/google-fit-vs-apple-health-kit/
- http://www.forbes.com/sites/dandiamond/2014/09/26/apples-healthkit-finally-arrives-after-bugs-botches-and-boatloads-of-apple-hype/
- http://www.slideshare.net/geneleybzon/google-fit-developers-view
- http://www.slideshare.net/Leybzon/apple-health-kit-from-the-application-developer-point-of-view
- https://play.google.com/store/apps/details?id=com.google.android.apps.fitness&hl=en
- https://developer.apple.com/library/ios/documentation/HealthKit/Reference/HealthKit_Framework/index.html#//apple_ref/doc/uid/TP40014707
- https://developers.google.com/fit/overview

Comments