Swift Runner API

When I first had the idea to make this game, I had never imported data using API requests and thought I would not be able to use Strava in the way I wanted. I learnt how to use the Strava API and persevered until I was able to make it function. This is the most fun and interesting project I've worked on as it required creative solutions, a lot of problem solving and learning how to do new things.

The game pulls walking, running and cycling data from the player's Strava profile. Originally, points were given by saving the player's total run, walk and cycle distances and compared against the player's current distances when they next open the game to calculate the difference and how many points the player has earned.

However, some of the activities were missed from the total distance. Testing showed that this was a bug within Strava as it was not displaying correctly on the Strava app itself. To fix this, I decided to change the system to save the ID of the most recent Strava activity. When the player opens the game, it looks at their activities with an ID number higher than the saved one and gives points using the new distances. This works because a higher activity ID is always a more recent activity.

When first using the Strava API, developers are in ‘Single player mode’ and need to apply to the Developer Program to allow other users to connect. I applied to and was accepted into the Developer Program, enabling me to add other users.

After Strava accepted my application to increase the number of users, I adapted my API systems to accommodate multiple users. The API request had been using a url with my user ID, but I changed the system to save the user ID when they authenticate and use that to pull the Strava data for the correct user. After 6 hours, the access token is no longer valid. The game uses the refresh token to generate a new access token and saves it so that the new token can be used.

On 1st June, Strava announced changes to the API. This removed free access to the API and required a Strava subscription to use. These changes came into effect on 30th June, giving one month to adapt. I decided to keep using the API as it was an integral part of the game. Strava offered a free trial of the subscription, and I then paid for access to the API after the trial period. 

I updated the API request system to scale for the future. The game had sent an API request every time the game was opened. This worked to pull in Strava data, however in the future this could exceed my request limits. If the maximum number of users I am currently allowed are playing the game, it only requires a few requests a day from each of them to exceed the limit.

I decided to restrict the API requests to a maximum of one per hour per user. The first time the game is opened always sends an API request to get the initial data. This also saves the unix time of the API request. When the game is opened again, the current unix time is compared to the saved unix time. If at least one hour has passed, another API request is sent.

If the player opens the game before one hour has passed, there is not another API request until the game is closed and reopened after one hour has passed. I decided to do it this way instead of sending an API request if the game is open once one hour has passed. This is because any player that leaves the game on will use up several unnecessary requests, and players are unlikely to open the game, do an activity and then open the game again in under an hour, so it wouldn’t affect the experience for most players. Some players would be affected by the 1 hour delay, but the positives of reducing demand on the API outweighs the small additional waiting added before these players are given their points.