Exciting Bug Reports

You may wonder how bug reports can be exciting. Most of the reports I get are about people having trouble to login or set up the app. Usually either because people Bugsuse the wrong device (vivofit or vivosmart), or have special characters in the password. I actually just fixed the latter, which is great news.

So once in a while I get a bug report from someone that spotted some inconsistency in the stats or numbers reported in the app. This is exciting because it is usually somewhat interesting to track down and also because it helps get the app better and better. It even sometimes happens that people spot inconsistency with other apps or report, and when the other apps was wrong it’s quite satisfying 🙂

Inconsistency between Time in Zone Graphs and Laps

An often overlooked feature of the app is the ability to compute statistics over arbitrary laps. You can of course record laps while you do an activity. But what if later you want to see how you did by kilometres or miles? You may also want to get your stats for all the times you were in a given heart rate zone. Or your half distance split, etc. The app lets you do that, by tapping on the lap header and selecting the type of lap you want.

Someone just noticed that the time in zone was inconsistent between the computed lap and the time in zone graph. As you can see in the graph for instance the 149 to 158 zone is reported with less than 10:00Simulator_Screen_Shot_15_Apr_2016__20_31_00

While the graph is clearly more than 10:00

Simulator_Screen_Shot_15_Apr_2016__20_28_59

Bug feels always silly once you found them. Here I was not accounting properly for each point of the activity where the value changes zone. The laps calculation is somewhat more involved than the time in zone graphs, because it requires keeping track of bunch of stats, like distance, speed or pace, average heart rate, etc. Note that the activity don’t report when the timer was stopped on the watch, so there is also some logic to account for the point where the timer appears to have stopped (long delay between points). It’s not exact and sometimes the logic does not work well.  But here I was just missing one point all together. It’s fixed now for the next version. Here is the correct laps after the fix

Simulator_Screen_Shot_15_Apr_2016__20_29_15

Fast Mile starts in slow section

Sometimes what appears to be a bug, is just a side effect of a feature. One user noticed that sometimes the fastest mile on the map appears to start in a section that is slow (blue). It would appear to not make sense as given the section at the end is faster it should more the fastest mile to be starting on the next point as here:

FastBikeSmoothing

Well, in that case actually the pin is at the exact right location. The blue section is also correct, given how it’s calculated: The gradient color represent the speed modulo some small level of smoothing. Here is the same picture without the smoothing

FastestBikingNoSmoothing

You can see that in that case, the fastest mile start correctly in a red (faster) section. It is hard to decide if this is a bug or a feature. It’s also interesting to see that in the case of a cycling activity (as in the above pictures), the speed is actually quite smooth already, so the smoothing probably not that critical. But in the case of a run, it tends to be much noisier. Given I am first a runner, it was quite obvious to me that without smoothing the gradient was less useful in identifying speed zone.

Here is a running activity with smoothing

SmoothingRun

And the same activity without smoothing, with a much noisier gradient

RunNoSmoothing

ConnectStats does not let you control the smoothing of the gradient on the map. Maybe I’ll add an option for that, or I’ll disable it for biking activities.

 

ConnectStats 2.5 rejected…

shutterstock_310884725So as per last week post, I had submitted to the apple review process a new version of connectstats with the 3D flyover feature…

Unfortunately, Apple rejected this version. The reason is that the code is using some of the HealthKit API. Actually it is appears to be using it because I am currently working on a version that will let you look at the steps and other information recorded via the Apple Health App or your Apple Watch. It is not yet enabled as I am still working on it and I am waiting until it’s ready for prime time. But the Apple review team rejected it on the basis that my code should not appear to potentially use health data if it’s not clear to the user why.

So I will wait until the next version is ready to release the 3D flyover, at this point would be too painful to patch an old version or  remove that code that I know I will need soon.

Website change

So today this website is hosted by a new service. The intention was that it would be transparent, but it took a bit of time to remap the domain name to the new host and it resulted in quite few temporary outage.

After many years as a loyal customer to yahoo for the hosting of this website, I switched away because the iOS 9 release is coming and Apple introduced a change to improve the security of interaction between apps and website. It will now require a site with a secure connection (https). Yahoo unfortunately didn’t support https in a way that enabled me to support some of the new features of iOS 9 I intend to leverage.

It is possible to continue to interact with an insecure website from an app by registering an exception, but two main reason led me to make the change:

  1. It’s just the right thing to do. There are a few informations sent from the app to the website when you send a bug report or use google earth, and it’s just better to secure it going forward.
  2. It will allow some interesting interaction between the web and the iOS9 version of the app, where by I could write an explanation of a screen and link it directly to opening the app on your device with the matching report or graph. Given some of the graphs and analysis are a bit involved and I didn’t figure out a nice way to integrate a help on a small screen like the phone, I am hoping this will be quite helpful for people to have more fun with the app.

Note that the secure uploads and the new features I mentioned above will not likely be included in the first version for iOS9, but hopefully shortly after.

 

How to track the non reproducible bug in version 2.1

So, version 2.1 was crashing for quite a few users on startup. Obviously the app wasn’t crashing for me in any of my tests.

First line of defence when crashes happens is to ask the user what they were doing and try to replicate the same action to see if I can recreate the crash. But here they weren’t doing anything it wasn’t starting.

Second is to look for patterns in the crash. The first few users reporting the issue were all using an iPad. There are a few differences between the iPhone and the iPad, mainly that the iPad displays an activity detail at the same time as the activity list. This can result in some difference in logic and makes the startup on iPad marginally more prone to issues. This can lead to hard to reproduce bugs too as it is a function of the type of activity the user would load on startup (the last one downloaded)

Another help is the crash report from apple. In this case, they were very few and reporting crash in location that are not triggered at start up or inside apple libraries. So not helpful to pinpoint the problem.

Some users affected by the issue kindly sent me their activity data so I could try to see if the problem was linked to their specific activities data. It wasn’t, I could start the app with their data fine.

This leaves one other possibility, a thread concurrency issue. This can be really random, and a function of both the speed of the hardware and the exact activities you have. ConnectStats is quite multi-threaded to try to keep the app responsive as many calculations are performed in parallel. So it is possible that some of this parallel activity result in a collision or some instructions run too early (when required data is not ready).

I try to be very careful on collision conditions and to make the code robust to data not being ready. In version 2.1, in order to optimise the startup, I had done a clean up of all the notifications between events in the app to limit them to the minimum needed. So likely the problem was linked to that: issue affecting random users, not a logic issue (users data didn’t let me reproduce it), but the issue was systematic for some users: so this gives another hint. The one issue that can exhibit these symptoms is if you trigger a User Interface event not from the thread dedicated to the UI (main thread).

I did a review of all the events that happen on start up and found one that, in the clean up of 2.1, wasn’t not forcefully directed to that main thread…

So while I couldn’t reproduce, I feel strongly that this must be the issue:

  • linked to some change I made in version 2.1,
  • random: depends of when precisely event get triggered
  • systematic for a given user: for a set of hardware speed and size of data, always happens or not

I submitted a fix for that event issue to apple, let’s cross fingers until version 2.1.1 is approved by apple and hope the issue is indeed resolved. I requested an expedited review, but it’s not always granted.