Google announced Google Fit at this year's I/O but there wasn't much to say other than it would be launched some time towards the end of the year. Now we have the preview SDK ready for the Fall final release.
The SDK includes the APIs for Android, but not for Android Wear or the REST API. For these we will have to wait for the final release. To make use of the SDK you simply download it using the SDK manager, and Android Studio seems to be the preferred IDE.
It also won't work on a current Android OS. You need to install a preview of Android L. If you want to try your programs out on a real device then you also need to make use of the system images that have been provided for the Nexus 5 or Nexus 7(second model WiFi only).
The key feature of the architecture seems to be the use of the Google Fitness Store, part of Google Play services, which the mobile device connects to store the data from the sensors. To make use of it you have to have a Google account and log in using OAuth 2.0 and the certificate generated by the Google Developer's Console.
At the moment all you can do is work with local data as the cloud backend isn't ready. Google promises that it will be available soon. The History API lets your app access data so that you can analyse a user's performance and make helpful suggestions.
The Google blog outlines the three APIs:
Sensors API provides high-level access to sensors from the device and wearables—so with one API your app can talk to sensors, whether on an Android device or a wearable. So if you’re making a running app, you could register it to receive updates from a connected heart rate monitor every 5 seconds during a user’s run and give immediate feedback to the runner on the display.
Recording API allows apps to register for battery-efficient, cloud-synced background collection of fitness data. For example, a running app could ask to store user’s location so it can map the run later. Once it registers for these data types, collection is done by Fit in the background with no further work needed by the app.
History API allows operations on the data like read, insert and delete. When the exerciser finishes her run, the running app can query the History API for all locations during the run and show a map.
The sensor framework provides the connection to the sensors in the wearable devices. And this is where the real problems start. In principle it will work with any Bluetooth LE device with a GATT profile. It seems that the LG or Samsung Android Wear watches ??do work with it. In time the intention is to make Google Fit work with a wide range of fitness devices. The big problem is that most fitness devices don't make a big deal of whether they are GATT compatible or not. Even those that do have a GATT profile sometimes user proprietary properties. Currently there is no list of what works well and what doesn't. There is also the problem that the API doesn't support every data type. For example there is no temperature data type - although this will probably be added before the final version is produced.
You can develop code to interface with devices that don't support a GATT profile
The big question is - will users be happy to let their fitness data be stored by Google?
My guess is that the answer will be "yes", as long as the apps are good.
Version 1.7 of the Perl 5 to C/C++ optimizing compiler, codenamed Tycho was released earlier this month. The issue RPerl tries to address is Perl's slow performance, sufficient for most cases, bu [ ... ]