Little fitbit cool spring

DataArt, like the whole world, watches with interest the innovations in the field of wearable electronics. In this article, we would like to consider developing for Fitbit.

About Fitbit

Now Fitbit produces many different interesting devices: clips Zip and One, bracelets Flex, Charge, ChargeHR and Surge and smart scales Aria. Latest news - ChargeHR and Surge.
')
Most trackers track the number of steps and steps, calories burned, distance covered, duration and quality of sleep, have an alarm clock. The new devices are also equipped with an enlarged display, support GPS tracking and notifications, music management and more. The data is synchronized with a smartphone or computer and Fitbit-servers.

About development

First of all, it should be noted that it is impossible to directly interact with the device. In fact, this turns out to be a serious limitation (we'll talk about this later). It would be useful to be able to communicate via Bluetooth LE, but so far this has not been implemented . You have to use Fitbit's RESTful services or client library APIs available for a number of languages.

For authentication, you need to use the OAuth 1.0 protocol (OAuth 2.0 Fitbit has not yet been transferred). Official documentation suggests not reinventing the wheel for this purpose and using existing solutions, providing a list of reliable and proven libraries .

Consider Temboo in conjunction with Java. First you need to register your application on dev.fitbit.com and Temboo (or for another library of your choice). You will receive a consumer key and consumer secret, which will be needed during authorization. You need to generate the authorization URL with which the application will pass the first stage of the OAuth process:

TembooSession session = new TembooSession(tembooUserName, tenbooAppName, tembooAppKey); InitializeOAuth initializeOAuthChoreo = new InitializeOAuth(session); // Get an InputSet object for the choreo InitializeOAuthInputSet initializeOAuthInputs = initializeOAuthChoreo.newInputSet(); // Set inputs initializeOAuthInputs.set_ConsumerSecret(consumerSecret); initializeOAuthInputs.set_ConsumerKey(consumerKey); InitializeOAuthResultSet initializeOAuthResults = initializeOAuthChoreo.execute(initializeOAuthInputs); 

The output will contain AuthorizationURL, CallbackID, and OAuthTokenSecret. The user must go through AuthorizationURL to allow access to the application. The callbackID is used to retrieve callback data that Temboo saves as soon as the user has logged in. The temporary OAuthTokenSecret is changed to permanent tokens in the next step.

When access is allowed, you can finish authorization:

 FinalizeOAuth finalizeOAuthChoreo = new FinalizeOAuth(session); // Get an InputSet object for the choreo FinalizeOAuthInputSet finalizeOAuthInputs = finalizeOAuthChoreo.newInputSet(); // Set inputs finalizeOAuthInputs.set_CallbackID(callbackID); finalizeOAuthInputs.set_OAuthTokenSecret(oAuthTokenSecret); finalizeOAuthInputs.set_ConsumerSecret(consumerSecret); finalizeOAuthInputs.set_ConsumerKey(consumerKey); // Execute Choreo FinalizeOAuthResultSet finalizeOAuthResults = finalizeOAuthChoreo.execute(finalizeOAuthInputs); 

As a result, we get access token and token secret for the user.

That's all! Now you can read and update 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 choreo GetActivitiesInputSet getActivitiesInputs = getActivitiesChoreo.newInputSet(); // Set inputs getActivitiesInputs.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 Choreo GetActivitiesResultSet getActivitiesResults = getActivitiesChoreo.execute(getActivitiesInputs); 

The result will be obtained in json or xml format, parsing it and using it for our own purposes.

Data entry looks pretty much the same. Let's write down the pizza eaten for lunch:

 LogFood logFoodChoreo = new LogFood(session); // Get an InputSet object for the choreo LogFoodInputSet logFoodInputs = logFoodChoreo.newInputSet(); // Set inputs logFoodInputs.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 Choreo logFoodChoreo.execute(logFoodInputs); 

As for the Fitbit API, it includes a long list of URLs (HTTPS), which can also be used to read and modify data.

We want your feedback!

But we want to squeeze the most out of the device - find new ways to interact with them or get non-standard feedback. Most Fitbit devices are equipped with displays or LED indicators, they can vibrate - all this seems to be a good user interaction mechanism.
Unfortunately, there is an obstacle indicated earlier: you can not directly access the device, only through the API.
How can I make the device respond? Consider the example of Fitbit Flex. The device vibrates when:

• achieved daily goal;
• the alarm is activated;
• (de) activated sleep mode .

LEDs light up:

• to indicate progress on the daily goal;
• when the alarm is activated;
• when (de) sleep is activated;
• when the device is charging;
• when an error occurs during the update.

This is an ugly decision, but one could generate such “artificial” events for one’s own purposes. But let's not forget that there is one more thing: after the user has updated the settings (set a new goal or an alarm clock), 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 application and keep the device close to the computer);
• via smartphone (launch the application, allow Bluetooth connectivity);
• via NFC;
• manually by pressing a button in the Fitbit application;
• in the background (making sure everything is up and running).

Thus, we get two obvious problems. First, it is rather strange to cause vibration when, say, a new message is received in a social network by setting an alarm clock. Secondly, the likelihood that immediately after this the device synchronizes data is very small. As a result, the event will be lost.

Instead of conclusion

In your application, you can easily read and write Fitbit data, process it or just show it to the user. But to cause a non-standard reaction of the device from the outside is extremely difficult, mainly because it is impossible to communicate with it directly.

The author: Veronika Strokova