What is best method for persistent storage?

Hello!

in my watch face, I would like to retain variable values when user switches to application or widget or activity and back to watch face. If I understand correctly the watch face memory may be destroyed if OS needs it and then watch is re-initialized.

I have read about Property.get/setValue and Storage.get/setValue. Which one is the bast and where to put it? I would like to avout setting and getting values every second in powerOn mode - would it be better to put it to on hide/unhide, or somewhere else?

Thanks, Jan

0 Alan.raceQs over 5 years ago

Storage set/getValue is the way to go, and save the values when they change.

0 JayBee over 5 years ago in reply to Alan.raceQs

Thank you very much. At the beginning I would like to check if property is set by

if (app.getProperty("number_prop") == null ) {

as in examples, but I get runtime error "Unexpected Type Error". How do I check if property exists - if it has been set before? Thank you

0 forandy over 5 years ago in reply to JayBee

try Application.getApp().getProperty(.....

0 jim_m_58 over 5 years ago in reply to JayBee

getProperty() is the old method. While it's available on everything, you really want to use Application.Storage.getValue() instead if you can.

0 Travis.ConnectIQ over 5 years ago

You want to use the functionality of the Storage module if possible.

https://developer.garmin.com/connect-iq/api-docs/Toybox/Application/Storage.html

The getProperty/setProperty functionality still exists, but you should only use it if the device you are working with does not support Application.Storage. The Storage module is more robust and supports serializing additional value types, requires less memory at runtime because it doesn't keep all properties in memory, but is slower because it must read/write values from/to file. Keep this last detail in mind when writing code... reading from file is not cheap.

If you need to work with old and new devices alike, I suggest you write wrappers that give you the same interface for either system and use jungles to switch between them at compile time.

0 JayBee over 5 years ago in reply to jim_m_58

Seems that getValue and setValue works fine and I keep the rule "do not mess up with what is working well" :-)

0 JayBee over 5 years ago in reply to Travis.ConnectIQ

Thanks. Properties work well and I understand they are cached in RAM. So if I read/write values, is it better to use properties, so it is faster and do not harm NAND memory? I use it and never had problem with lost value, Garmin watches do not crash (without bad code :-). Jan