I mostly work and play within the Apple ecosystem and AirDrop, Continuity and other integration between devices is extremely useful and convenient. My son recently converted himself to Linux and started to miss the ability to easily move photos, text, or url between his phone and his Linux computer. Being a hacker himself, he thought it would be a great idea to devise an app that let’s you move information from your phone to your computer, and more generally a “cross platform AirDrop substitute for geeks”…
Of course, one solution would be to google and figure out if such an app exists, but where is the fun in that? We decided to take on a Father-Son new project and build our own solution.
ConnectStats tries to maintain for each field in an activities from Garmin or Strava a list of translations and units for the metric or imperial system. I am mostly my-self using the app in English and metric but I had updated the list in different languages from some sources I had found online and the Garmin website a few years ago.
But it is now a bit dated and there are quite a few attributes for which I do not have the translations. Some users volunteered to update the translations in their native language. In addition recently I received quite a few bugs report about units being incorrect for example for elevation or weights.
Trying to understand what was wrong in my Best Rolling Curve Calculation pushed my ability to use Xcode debugger to its limit. The quirks I was trying to understand were happening on large time series after multiple level of sampling, rolling averages, etc on noisy data.
I ended up in a mixed environment so I could easily exchange time series data between Xcode and pandas in a Jupyter notebook, which enabled me to explore and get to the bottom it!
The harder category of bugs are when it is related to bad numbers generated from the more complex algorithms in ConnectStats. This is what is now happening with the best rolling plots.
The rolling best curve are one of my favorite feature in ConnectStats, they provide insight I don’t see in many other services. It’s quite common to see a power curve, but I feel the concept extended to heart rate or speed help give people a good sense of the characteristic of a workout. While the concept is simple, it actually can be a bit tricky to implement (at least for me it was). The current version of the app shows quite a few quirks that are obviously wrong, like the below.
ConnectStats has been around for a while now. It started in 2011, while the Garmin API was in a very different place as today. I have maintained it over the years, but there is still quite a bit of complexity in the code due to the history of the API evolution.
I am pushing a new version that simplifies some of the legacy internals of the code.
As any internal upgrade, it will help in the future and fixes some side effect or bugs coming from the legacy complexity. But it also comes with high risk as it is hard to test all the side effect. I’ll try to fix what comes out.
Time flies. It has been close to one year since Garmin opened its new API to third party developers and that I embarked on migrating ConnectStats to using it. I had anticipated it would be fairly straight forward, but, boy, it has been quite a ride, and the last few weeks continued to provide a lot of “excitement”. Let me share some of that story…
Quick recap of the service
In the past ConnectStats was connecting to the Garmin Connect website to extract the data for the user activities. While this was the way ConnectStats worked from the beginning (2011!!!), it was simple as I didn’t have to maintain any online servers, but it was not very robust and repeatedly created serious outage as the Garmin Connect website would change its way of getting data without any type of support or documentation. I would typically have to find out via a multitude of bug report and try to reverse engineer what had changed on the web site.
The new service is fully documented and supported, but the flip side is that it works by pushing the fit files of a user to the application web server in the cloud. Which means you need to have a web server in the cloud, which I didn’t…
I recently saw a negative review on the App Store for ConnectStats warning users that ConnectStats is not a Garmin app and therefore people should avoid giving away login information in the app as the data may get stolen.
Keeping data secure both on your phone or online has been a key guiding principle in how I tried to implement the app. So while I understand the concern, I felt it was a bit unfair.
I have been careful to make sure the data isn’t shared and the passwords are never sent to me. I also made the app open source so that people can check for themselves what it is doing.
I felt it may be worth to write a bit of details on what is ConnectStats doing with your data and password, with link to the code. So people can either let me know if I miss something or feel better about using the app.
So in the last few weeks, ConnectStats had a lot of issues related to online services. That was quite a learning experience. I hope most of it is behind, but could be a few left overs.
Strava made a change in its API related to how it authenticate users for access. This was a documented and announced changed, unlike a lot of the Garmin API changes in the past,. The issue is mostly that I hadn’t understood the change, so I didn’t get the right fix out in time. So I have only myself to blame…