Dealing with Object Store Save on User Reboot

I believe I read it somewhere here that a save does not happen until the watch face exits. However I am finding that the object store data does not get saved if the user does a reboot. Maybe I am wrong here .. I will have to do some more testing.

I did find this thread but it is a bit old now .. https://forums.garmin.com/showthread.php?284612-Persistent-Storage-App-Setproperty-where-is-data-stored&highlight=object+store+save

As the developer .. I need to make sure that my data is being saved.

So do I need to do the app.saveProperties() myself. I am looking for some feedback if this is indeed an issue ?

I just tested and confirmed that the VAHR DOES NOT do a save to the object store when a user does a reboot. The object store data is not retained.
However, if you do a swipe for example first .. the data is retained.

I have been told this is how it is .. and I guess one of the consequences of a user just rebooting their device.

I don't think the way that works is limited to the vivoactive HR as I'm pretty sure my D2 Bravo also functions as such. And I don't think it's just reboots. If the Connect IQ app crashes I've found that and changes to the properties are also lost.

Cheers,
Douglas

I don't think the way that works is limited to the vivoactive HR as I'm pretty sure my D2 Bravo also functions as such. And I don't think it's just reboots. If the Connect IQ app crashes I've found that and changes to the properties are also lost.

Cheers,
Douglas

Correct... The OS (the .str file) is only written to mass storage when something exits cleanly. It's the same on all Connect IQ devices from what I've seen.

I don't think the way that works is limited to the vivoactive HR as I'm pretty sure my D2 Bravo also functions as such. And I don't think it's just reboots. If the Connect IQ app crashes I've found that and changes to the properties are also lost.

Cheers,
Douglas

I personally have an issue with it .. as sorry there are 3 items in that 'system menu' that comes up, and they are all valid selections much the same as a swipe or a right button press.

One of the options just happens to be a power off but I expect that the data is not being saved no matter which option the user chooses.

That does not excuse Garmin from saving the data when exiting in this case. Another issue .. is that as the developer I cannot force a save in this case, knowing that the data will be lost.

Just pretending that a user should not go and do it and suffer the consequences does not give me a warm fuzzy feeling. :eek::eek:

I can understand if it crashes .. that is a different issue and likely caused by the application itself. I wonder why when you do a setProperty that it does not do a save right then and there ? I am sure it is for performance reasons but I would be very interested in what Garmin has to say about the lack of saving on this one.

If anything .. it is an interesting and not talked about item it appears, that people just live with.

Does Eclipse save your code if you power off your PC while editing a .mc? :)

The reality is, you got to ask why someone is powering off the watch to begin with. I don't think it's all too common, unless the watch is having problems already. For an IQ!, do you want the changes to the .str to stick around, not knowing the state of those changes (the change could have caused the IQ!)? Same with a full crash of the watch, or an auto shutdown due to low battery...

Worst case is the OS will only have the data from the last time there was a clean exit. You'll only miss what you are trying to change.

Does Eclipse save your code if you power off your PC while editing a .mc?

The reality is, you got to ask why someone is powering off the watch to begin with. I don't think it's all too common, unless the watch is having problems already. For an IQ!, do you want the changes to the .str to stick around, not knowing the state of those changes?

Worst case is the OS will only have the data from the last time there was a clean exit. You'll only miss what you are trying to change.

I suppose when you put it that way .. and yes for the user, they will just have to deal with it I guess. Thanks.

I have history here with .str files. I used to email them out to customize things before there were app-settings (1.1.x days), and when saveProperies() was removed (you can still make the call, but it's a NO-OP in the sim and on watches) I wasn't happy as it made creating my custom .str files harder and there was a discussion about this (early 2015 IIRC)

I still use Object Stores in a number of things (just not for configuration stuff as I use the real app-settings!), and never heard a peep from any user that lost their data because they just decided to turn off their watch...

IQ!, yes, but that means I have a bug and fix it. Full Crashes? Sure, but lots of things loose data then. Low battery? Some watches warn of this on their own, but I try to warn the user it's coming where it's important...

Ok .. no more peeping from me then. Thanks.