Since recently Toybox.SensorHistory.getPressureHistory crashes I haven't changed any code and it works perfectly in the simulator, but it fails on the watch. Is there a know issue or a change in how this is supposed to work?
Is it the vahr? I seem to recall there's a bug in the last FW, where there's no pressure history. You can make the call, but you get a null back and not the iterator.
You actually get an iterator, and the iterator returns next, but the actual data is null. If I loop through, I eventually find a value of 24.1 for example, where it supposed to be about 100,000 (since it's in Pascals and the pressure around should be around 100kPa).
People are reporting crashes. I changed to code with additional checks.
However, my watchface crashes now because of other things on other people's watches which I can't even check or simulate. It's a bit crazy.
In a case like this, I set a default value showing "Not Available" in some way. Then check if getPressureHistory is available. (I set some booleans for things when the app starts using "has")
if it is, I call getPressureHistory and check the return for null. If it's not null, I check the first sample. And then only change the default if the sample isn't null and the data in the sample isn't null. That's why I didn't recall what exactly was null, as I check a few things.
For now, I just show "not available" for pressure on the vahr, but when the FW is updated with a fix, it will work again and nothing in the code will need to be changed..
For you're looking for just the current pressures, look at Activity.getActivityInfo() and ambientPressure as well as meanSeaLevelPressure. They are available on watches with a baro, and a 2.4.x VM or greater. (check the API documentation)
Thanks - that's what I did in the end, but this is a little mad to be checking for nulls every step of the way in case SDK or FW fails. Thanks for your help though. Much appreciated.
With multiple devices and new FW, it's really just a thing to do in the code - null checks or catching exceptions If something can be null, check for it. Instead of a user seeing an IQ!, it's better if they see a "not available" for a field and can ask why...
If you ever start using Activity.Info in a watch face, that for sure is something you want to null check, as things like "currentLocation" will go null after a period of time (you'ed use it for things like sunrise/set). For currentHeartRate, it will go null if the user just takes the watch off.
