UnexpectedTypeException in ActivityMonitor.getHeartRateHistory()

The following code throws "UnexpectedTypeException: Expected an object of type Time.Duration".
I checked the type of the duration variable and it is in fact Time.Duration.
If duration is null or a number, the function works as expected.
I have tested it only in the simulator on FR645 device.

using Toybox.ActivityMonitor;
using Toybox.Time;

var duration = new Time.Duration(60); // seconds
ActivityMonitor.getHeartRateHistory(duration, false);
  • What happens on a real device? If it's a sim only bug, seeing a fix could be faster than if device FW is involved.

    The older data/duration thing also shouldn't happen on a device. as the history will be getting updated.
  • Doesn't seem to crash on a real device. I tried both 120 and 60 on my 935, immediately after boot and after waiting 120 or 60 seconds, and it didn't crash. So it could be a combo of not having data and also doing the wrong math/comparison on a duration. Thanks for the suggestion!

    I haven't really tested extensively, so I can't say for sure tho. I'm looking at debug statements in the sim, but not on the device, because I really can't be bothered.
  • One of the Garmin folks first told me years back "It's a Simulator and not an Emulator", and that's something to remember, as the sim doesn't always act the same as an app on the device and it never hurts to check a real device when you see something. I know I have some apps where anything more than some basic testing I do on an actual device.

    You've already gotten much further on a device than on the sim, which says to me "sim specific". The app shouldn't crash in the sim with a duration, but as far as data you get could be a sim vs real world thing.



  • Yes, I agree that it seems to be sim-specific, I just mean that I haven't tried it as extensively on the device as I did in the sim, because obviously it takes much more time and effort. I'm not even looking at the data, I'm just curious about the crash, and only because it's come up in the past.

    Anyway, considering that this issue has been coming up every now and then for about 2 years, that tells me that if a function crashes in the sim, most people will assume that it will also crash on the device. Unless of course it also crashes or otherwise fails on a real device, and I didn't notice because I really haven't tried that hard.

    Even if it works on the real device, how do you test your code in the sim if it's going to crash? Constantly change your code every time you switch from sim to real device? I see a few issues with that.

    Of course it would be best to check everything on a real device, but then again, most devs don't have more than one or two Garmin devices, so testing device-specific or CIQ-version-specific behaviour becomes problematic. I had to borrow a friend's 230 when I tracked down some CIQ 1-only issues in the past. The other alternative is to ask users to help you debug, which is annoying and time-consuming for them. This is where it would be really nice if the simulator had the same "broad strokes" behaviour as the actual device, down to the same bugs/limitations. And I'm just saying this as a guy who really only had one "hobby" app on the store, and a handful of "one-liners" that users requested. If this was a chunk of my livelihood....
  • This is definitely a simulator bug. The bug is caused by a less than ideal simulation back end for these histories. If you look at the data closely over time, you will notice that the simulator is generating 4 hours of history when it starts up, and then fails to add any additional points. If you wait 60 seconds, and then request the full history, there won't be any points in the most recent 60 seconds. If you only request data from a period that doesn't have any data, then this crash occurs.

    There are two issues here.
    1. You should not be getting a crash if you request a period that doesn't have any data points.
    This shouldn't be something that is a complex fix, but I thought it had already been investigated, so there might be more here than at first glance.
    2. The simulator should be generating additional data after startup.
    This is borderline a feature thing, as opposed to a bug, but it doesn't emulate the device very well, and would definitely be good to improve.
  • This is one of a few bugs, limitations or unexpected behaviours that people have been "rediscovering" over and over again, sometimes for years.

    Hah yes! I have just spent "some time" on "rediscovering" this bug and trying to work out what on earth was going on!

    So it still exists (8 months later) Slight smile