DataArt, like the rest of the world, is watching with interest the innovations in the field of wearable electronics.In this article, we would like to review the development for Fitbit.
Now Fitbit has a lot of different interesting devices: the Zip and One clips, the Flex, Charge, ChargeHR and Surge bracelets, and the Aria smart scales.The latest additions are ChargeHR and Surge.
Most trackers track the number of steps and stairs walked, calories spent, distance covered, duration and quality of sleep, and have an alarm clock. The new devices also have a larger display, support GPS tracking and notifications, music management and more. The data syncs with your smartphone or computer and Fitbit servers.
The first thing to note is that it is not possible to interact with the device directly. In fact, this turns out to be a serious limitation (more on this below). It would be useful to be able to communicate via Bluetooth LE, but for now it is not implemented You have to use Fitbit’s RESTful services or API client libraries available for a number of languages.
You need to use OAuth 1.0 for authentication (Fitbit has not yet switched to OAuth 2.0). Official documentation suggests not to reinvent the wheel for this purpose and to use existing solutions, giving a list of reliable and tested libraries
Consider Temboo in conjunction with Java. First you need to register your app at dev.fitbit.com and Temboo (or for another library of your choice). You will get a consumer key and a consumer secret, which you will need for authorization. You need to generate an authorization URL, with which the application will pass the first step of the OAuth process :
TembooSession session = new TembooSession(tembooUserName, tenbooAppName, tembooAppKey);InitializeOAuth initializeOAuthChoreo = new InitializeOAuth(session);// Get an InputSet object for the choreoInitializeOAuthInputSet initializeOAuthInputs = initializeOAuthChoreo.newInputSet();// Set inputsinitializeOAuthInputs.set_ConsumerSecret(consumerSecret);initializeOAuthInputs.set_ConsumerKey(consumerKey);InitializeOAuthResultSet initializeOAuthResults = initializeOAuthChoreo.execute(initializeOAuthInputs);
The output will contain the AuthorizationURL, CallbackID and OAuthTokenSecret. The user must go through the AuthorizationURL to allow access to the application. The CallbackID is used to get the callback data, which Temboo stores once the user is authorized. The temporary OAuthTokenSecret is changed to permanent tokens in the next step.
When access is granted, you can finish the authorization :
FinalizeOAuth finalizeOAuthChoreo = new FinalizeOAuth(session);// Get an InputSet object for the choreoFinalizeOAuthInputSet finalizeOAuthInputs = finalizeOAuthChoreo.newInputSet();// Set inputsfinalizeOAuthInputs.set_CallbackID(callbackID);finalizeOAuthInputs.set_OAuthTokenSecret(oAuthTokenSecret);finalizeOAuthInputs.set_ConsumerSecret(consumerSecret);finalizeOAuthInputs.set_ConsumerKey(consumerKey);// Execute ChoreoFinalizeOAuthResultSet finalizeOAuthResults = finalizeOAuthChoreo.execute(finalizeOAuthInputs);
This gives the user an access token and a token secret.
That’s it! Now you can read and update the data. Including using the same library. For example, let’s see what the user did on a particular day :
GetActivities getActivitiesChoreo = new GetActivities(session);// Get an InputSet object for the choreoGetActivitiesInputSet getActivitiesInputs = getActivitiesChoreo.newInputSet();// Set inputsgetActivitiesInputs.setCredential(yourCredentials);getActivitiesInputs.set_Date("2013-03-18");getActivitiesInputs.set_ResponseFormat("json"); // or xml - optional (default is json)getActivitiesInputs.set_UserID("123123"); // optional (default is the current user)// Execute ChoreoGetActivitiesResultSet getActivitiesResults = getActivitiesChoreo.execute(getActivitiesInputs);
The result will be in json or xml format, parse it and use it for your own purposes.
Data entry looks something like this. Record the pizza eaten for lunch :
LogFood logFoodChoreo = new LogFood(session);// Get an InputSet object for the choreoLogFoodInputSet logFoodInputs = logFoodChoreo.newInputSet();// Set inputslogFoodInputs.setCredential(yourCredentials);logFoodInputs.set_Amount("3");logFoodInputs.set_MealType("Lunch");logFoodInputs.set_Date("2011-10-14");logFoodInputs.set_UnitID("147"); // food units; 147 is for “grams”logFoodInputs.set_FoodID("10409"); // food id for pizza// Execute ChoreologFoodChoreo.execute(logFoodInputs);
As for the Fitbit API, it includes a long list of URLs (HTTPS) that can also be used to read and change data.
We want your feedback!
But we want to get the most out of our devices – find new ways to interact with them or get unconventional feedback. Most Fitbit devices have displays or LEDs, and they can vibrate – all of which seem like a good mechanism for interacting with the user.
Unfortunately, there is an obstacle, which was pointed out earlier: you cannot access the device directly, only through the API.
How do you make a device respond? Let’s take the Fitbit Flex as an example. The device vibrates when :
- the daily goal has been reached;
- the alarm clock is activated;
- (de)activates sleep mode
LEDs light up :
- for indicating progress on the daily target;
- when the alarm clock is activated;
- when the (de)activate sleep mode;
- when the device is charging;
- when an error occurs during an update.
It is not a nice solution, but you could generate such "artificial" events for your purposes. But let’s not forget that there is one more thing : after the user has updated the settings (set a new goal or alarm), you need to synchronize with the server for the updates to take effect. There are several ways to synchronize :
- via PC (you need to run the Fitbit app and keep the device close to your computer);
- Through your smartphone (run the app, enable Bluetooth pairing);
- via NFC;
- manually by pressing a button in the Fitbit app;
- in the background (making sure everything is up and running).
Thus, we get two obvious problems. First, it is quite strange to cause a vibration when, say, receiving a new message in a social network through setting the alarm clock. Secondly, the likelihood that the device will sync the data immediately afterwards is very low. As a consequence, the event will be lost.
In lieu of a conclusion
In your app, you can easily read and write Fitbit data, process it, or just show it to the user. But it’s extremely difficult to trigger a non-standard response from outside the device, mostly because you can’t communicate with it directly.
Author : Veronica Strokova