Artificial Runkeeper Data for Software Development

In this post, we are going deeper into the Dynamic Data project, looking at the Runkeeper dynamic data (library available here on GitHub and at NPM). Opening the library, you’ll see there is one type of data file: CardioActivity

Learn more about dynamic data generators and the benefits of artificial data in software development.

About the data source

Runkeeper is a GPS fitness-tracking application available on smart devices (iPhone, Apple Watch, Android, etc.) track the user's progress against their running and training goals. Data can also be manually input into their browser platform. Their platform provides other services: training plans, guided workouts, monthly running challenges, etc. The application allows the user to record the type of activity or equipment used, (when applicable) plot a GPS route, and other details, such as date, duration, start time, calories burned, distance (if no map), average heart rate, and a descriptive note. The user can also connect and integrate their data with several other health sources: Fitbit, Garmin, MyFitnessPal, Apple Health, etc.

​Approach used

Runkeeper allows for the user to export their data, which downloads a copy of their master CSV files for all activities and the individual GPX activity files associated with GPS activities. The CSV files can be converted into JSON objects to create the data mockups. A simple data model of these objects can be seen below. This mockup file makes up the runkeeper-data package.

The runkeeper-mockups package imports the aforementioned file and goes through each attribute of it, generating artificial (new) data using proprietary functions, such as those found in the utils package.

For example, with the CardioActivity object:

Static CardioActivity Object

Artificial CardioActivity Object

Use case ideas

• Health/Fitness Apps
• Data Visualization Widgets
• etc.

Explore entirely new use cases

• An app that provides to-do lists of workout activities that need completing and strikes them off once the activity of the correct type has been recorded.
• An app that recommends activities and diet based on current fitness progression.
• An app that could warn the user if the app thinks they are spending too much attention on a particular activity, e.g., too much upper body workouts and not enough leg workouts.
• An app that displays information about the route taken: e.g., any noticeable landmarks, history of nearby places, weather at the time, and forecast for coming days of route.

Ideas to combine with some other data sources

Combing with other Health devices to provide greater context towards some activities e.g., Fitbit, Garmin, Oura, or Strava.

Combine route information with destination, trivia, or weather apps to provide greater context to route taken. 

Open-source data library

We welcome contributions and forks to this data set and look forward to seeing what developers build in our Liberty. Equality. Data. Slack channel.

Considerations for next version/improvements

General Improvements

• While the CSV files are faked, there could be a desire to fake the GPX files. However, these are XML files so they would require conversion to a JSON object and reverting back to an XML file after faking. 
• Another file that needs to be faked is the Measurements CSV file which records the user's weight and fat percentage
• Greater reliance on the utils package where appropriate
  
  

Object-Specific improvements

• CardioActivity
  • Have averageHeartRate be context sensitive (makes sense with the rest of the object)
  • friendsTagged needs to return faked data

Join our Slack community; Liberty. Equality. Data. - to ideate and collaborate with other app developers, designers, and our team.