Monthly Archives: June 2014

FitRPG: The Gamification of Fitness

An RPG mobile app like no other – get fit and turn your fitness data into skills, experience points, and HP to engage in battles against your friends

Fitness trackers like Fitbit, Nike FuelBand, and Jawbone all work to solve a common problem– motivating users to get fit and stay fit. When I first started using Fitbit, I was inspired by seeing my data every single day. My dashboard was either a blunt reminder that I was not moving very much, or a beautiful screen filled with all the goals I’d accomplished that day. I felt rewarded when I received a badge or passed a fellow Fitbit friend in the rankings. But after a while, the badges were all the same, and I lost motivation to try to surpass my friends.

Screen Shot 2014-06-09 at 12.20.15 PM

Why? Because a fitness tracker is just that–it tracks your fitness, but it doesn’t add any additional features or rewards for motivation. That’s where FitRPG comes in, a mobile app that uses the data from Fitbit and turns it into a fun game that constantly inspires the user to walk more, sleep more, and work out more.

Our team (Amira Anuar, Conor Fennel, and Matt Gutierrez) worked for 2.5 weeks on this Hack Reactor group project. We created an app that allows you to sync your Fitbit and see your steps, sleep, logged workouts, and more become transformed into strength, endurance, HP, dexterity, and other attributes your character can use to battle your friends or go on quests.

   screen1 screen2




















Sleep to revitalize your HP. Log workouts to increase your strength and dexterity. Increase your steps to improve your experience and endurance.  Battle your Fitbit friends to steal their gold. See how you rank against other players in the leaderboard and increase your ranking by battling bosses and leveling up. Go on timed solo quests, which range from walking 5,000 steps to running a marathon. Win gold and experience if you succeed.

To get started, just download the app from the Google Play Store and log in with your Fitbit account. For any further questions, you can view the FAQ here or email our team at iOS version coming soon.

Take fitness to another level, literally.

Mobile Authentication in Ionic with OAuth Through External APIs: Fitbit Pt 2 (Client)

In this post I talk about how to hook up the server to the client side so a user can open your app on their phone and log in through their Fitbit account. If you haven’t read the post on setting up server for mobile OAuth, I recommend you start with that first.

Client-Side (Requirements: angular.js and ionic)

Step 1: Create the Login Service 

First, you will want to create the login service, in which you inject localStorageService, which you would need to install from here and then require in your index.html. Once you’ve done that, this is what your service should look like:

Screen Shot 2014-06-15 at 8.47.54 PM

 The url is what the server url you have that redirects a user to be logged in.  Line 9 will open an in-app browser with no toolbar or url displayed. Line 10 adds a listener called ‘loadstart’ which is called every time a new url is being loaded in the in-app browser. When this in-app browser opens, the view should look something like this:

Screen Shot 2014-06-15 at 8.53.23 PM
















Once the user logs in, he/she is redirected, as per the server. The url will change, as per the server. The rest of the code basically listens for the url that will eventually have the oauth_token that we want, as well as the user id. This particular code also listens for the JSON web token. Once you receive the token/information you want, via the URL from the server, you use localStorageService, which is basically a caching service, to store the tokens locally.

Step 2: Authenticate the User

We then want to have a controller that checks for the locally stored tokens, and if they’re there, we can direct the user to the authenticated view (line 7), and if not, we let the scope know that the user is not authenticated (line 11). All line 6 is doing is retrieving the user information from the database, using the userId to make that query.Screen Shot 2014-06-15 at 8.59.05 PM

On line 14, we have the function for logging out, which simply clears the localStorageService of all saved information, and essentially resets the ‘session.’ Line 16 basically refreshes the page, which would be unauthenticated, and line 11 would be true, and the user would be redirected to the login page, where they will be given access to something to click that will run line 21.

Step 3: Putting It All Together

Finally, we just need to hook up the views and the controllers.

Screen Shot 2014-06-15 at 9.02.49 PM

Line 4 is where we can insert our views for the app, and no user can see them unless they are authenticated. If there is no user saved to local storage, then lines 7 to 18 would show, which would be your splash screen with a button allowing the user to log in, such as our app shows below:

Screen Shot 2014-06-15 at 9.07.07 PM










And there you have it! Shameless plug: If you have a Fitbit and want to make fitness more fun, check out my app in the Google Play Store!

Mobile Authentication in Ionic with OAuth Through External APIs: Fitbit Pt 1 (Server)

Shameless Plug: The following steps were used in the creation of FitRPG, a fitness gamification mobile app. Download it in the Play Store now!

During a 24 hour Hackathon, I was able to fairly efficiently allow users to authenticate through Fitbit login via a web browser. I primarily used OAuth and passport. However, when I decided to create an Ionic mobile app that allowed users to authenticate client-side through Fitbit/Jawbone (and really any external API that does authentication through OAuth 1.0/2.0), I ran through several issues and could find very little online support. In the end, it’s really not all that complicated–the key is we have to use our server-side to authenticate users, and we need an in app browser client-side.  It’s important to note that every API is a little bit different, and while I cover only Fitbit authentication in this post, the same general concepts can be used for other APIs as well. This post covers the setting up of the back-end, my next post covers the setting up of the friend end. You must do both for this to work as they depend on each other. Make sure you get your consumer key and secret from Fitbit upon registering your app.

Server-Side (Requirements: node.js and express 4.0)

Step 1: Set up Passport  First, we set up Passport, authentication middleware for node. Passport authenticates requests through ‘strategies’ you provide. In other words, we tell Passport what requests to authenticate, and it provides hooks for controlling what happens when authentication succeeds or fails. To do this, we jus require and then initialize it. Screen Shot 2014-06-07 at 12.55.24 PM


Step 2: Set Up Your Strategy with Passport Strategies are what Passport uses to authenticate requests. You can use them to verify a username/password combination, for instance, or to delegate authentication to OAuth, which is what we are doing in this situation. Before passport can ‘use’ a strategy, we have to configure it. Usually you do not have to create the strategy yourself–Passport has a pretty comprehensive set of over 140 authentication strategies that cover social networking, API services, and so on. I used the fitbit-passport strategy. On web, the fitbit-passport works fine as is, but on mobile, there is a tweak we want to make so that the login page shows up as mobile-friendly. I ended up having to make a copy of the node module and storing it in the body of my app files. Change the line that assigns options.userAuthorizationURL to:

Screen Shot 2014-06-09 at 2.28.32 PM


Step 3: Configure Your Strategy with Passport To configure the strategy, you must create a new strategy and pass in a) an object with your Fitbit consumerKey, consumerSecret, and callbackURL (more on that later), and b) a callback function that occurs once authentication is successful–this function will receive the token, tokenSecret, and profile from passport. Finally, you tell passport that it needs to ‘use’ that strategy.

Screen Shot 2014-06-07 at 2.07.11 PM

Step 4: Create Your Routes I used Express 4.2, and express.Router() to handle my routes. When my site goes to ‘/’ it uses the FitbitRouter. I could have also done “app.use(‘/fitbit’, FitbitRouter)” and that would have handled all of the routes on my site that start with ‘/fitbit’. In this particular case, my authentication page is just at, so that is where I will direct my mobile app to when I want to authenticate the user (more on that later). Step 5 covers the logic behind lines 4 and 5, but if you just want the code, skip to step 6 for the function in line 6. Screen Shot 2014-06-07 at 2.14.43 PM

Step 5.1: Get the Temporary Access Token The only endpoint we need to write is for that last route, as the first two just use the passport middleware. However, it is important and useful to understand what is going on. First, when we have a route that uses ‘/auth’,  which is the route we direct users to when we want them to authenticate via Fitbit. On our client side, we will be opening an in-app browser that goes to this url (see Pt 2). When we go to this page, we use passport.authenticate(‘fitbit’) as middleware, with ‘fitbit’ referring to the strategy we’ve declared earlier. Passport does work in the background to do the first step of the authentication process. What’s basically happening is passport then sends a post request to Fitbit (taken directly from Fitbit API documentation):

Screen Shot 2014-06-09 at 2.13.08 PM

Fitbit then sends back a response with a temporary OAuth token, which Passport receives and then uses to recreate a redirect url with, which looks like this: The temporary oauth_token expires upon usage or within a few minutes. So to summarize, the middleware works to create that token and redirects users to a Fitbit login page where they can fill in their username and password.


Step 5.2: Get the OAuth Verifier Once the user is successfully signed in, Fitbit will redirect the user to the callback that you have provided, which in this example is the route to ‘authcallback’ (see step 3 above). The callback URL also includes Fitbit’s response, with the temporary OAuth token and a token verifier, which looks like this: With this verifier, passport (which is again included as middleware for that callback route) does another POST request to Fitbit, which looks like this. Screen Shot 2014-06-09 at 7.33.01 PM

Step 6: Save the OAuth token and OAuth token Secret Fitbit’s request comes back with the OAuth token and OAuth token secret, both of which you will need to access the user’s data in the future. Passport sends the token and tokensecret to the callback function shown in step 3. Passport also does additional work of getting the user’s profile for you.  From this point, it’s up to you what you do with that information, but I recommend saving the token and tokensecret, and then using fitbit-node‘s requestResource function to retrieve data for that user. Once you have the token/tokenSecert, it’s pretty straightforward from there.

Step 7: Respond to the Client At this point, our client is waiting for a response from our server, which is the responsibility of our function ‘getOuthToken.’ All that function needs to do is redirect to a url that will basically notify the client that the process has completed, and the in-app browser can be closed. In my example below, we use JSON web tokens, which are tokens generated to ensure the security of our app (the user must make resource calls with this JSON web token). Your app can capture the ‘oauth_token’ in the request, and send that back to the client to save, or your app can merely redirect to any link, as long as you check for that in the client side. My app sends the JSON web token back in the url for the client to capture. Screen Shot 2014-06-09 at 7.59.56 PM
That’s it! 
You’re done (sorta – you need to implement the client side on ionic – see next blog). Once you complete these steps, your user has signed in via Fitbit! As I said before, if you want to make resource requests on behalf of the user, I’d recommend using fitbit-node. Good luck, and please comment if you have any questions.