• State Verified Answer
  • Replies 6 replies
  • Subscribers 16 subscribers
  • Views 1134 views
  • Users 0 members are here
Options
Related

When is persistent not persistent? Storage.getValue versus Application.getProperty

9635560
over 4 years ago

Hi,

I'm having some issues with watch faces whereby persistence seems to be rather overtly unreliable. I won't do it today, but I will investigate further next week and might put together a bug report next week if I can narrow it down.

This is what I see:

1. I use a mix of Storage.setValue and Application.setProperty in my WF.

2. If I swap out to a new WF and return, then the Application.getProperty accurately reflects what I had previously stored but Storage.getValue seems to be unreliable.

So the question (because I couldn't see it in docs): under what circumstances are storage and properties reset? I had previously thought both were only wiped in response to either an uninstall or an occasional bug with updates.

Thanks,

G

  • 0 over 4 years ago

    Couple things..

    You should be using Application.getApp().getProperty() and not just Application.getProperty()

    And when you're using that call is it the object store (no propert in the xml file) or for a setting (the propertis defined.

    It's probably not a good idea to mix Application.getApp().getProperty()/setProperty() and Storage.getValue()/setValue()

  • 0 over 4 years ago in reply to jim_m_58

    For the getapp thing, yes, I know. Typing quickly etc. 

    For the rest:

    1. Yes, properties are defined in XML

    2. Why can I not mix properties (visible to user in settings page) with storage (internal to the app)? Why is that not a good idea?

    ETA: My understanding is storage and properties are independently managed stores occupying different locations and using different apis to manage them. Nothing in docs even hints at issues with combining their usage. 

  • +1 over 4 years ago in reply to 9635560

    Actually, Application.getApp().getProperty/setProperty are used for both the object store (the .str file) and properties (the.set file) and it's based on if there is a property defined in the XML file.  So it may not be clear in the code which you are using.

    While Apllication.Storage.getValue/setValue is only used for storage and Apllication.Properties is used for properties (the same .set file).

    You really want to be consistent and use getProperty()/setProperty() calls or getValue()/setValue() calls on a specific device.

  • 0 over 4 years ago in reply to jim_m_58

    That's...

    That's a very important thing to know. :( 

    Thanks,

  • 0 over 4 years ago in reply to 9635560

    Back to your original question 2, using Storage should always be persistent though - if you write something to storage, then you should always be able to read the same value back from storage.

    The only times I've heard it not working is if the storage file becomes corrupt (somehow ...), or I've seen some system errors reported in ERA which say something like "file does not exist".

  • 0 over 4 years ago in reply to 9635560

    If you look in a 3.1.x SDK programmer's guide, you find this kind of info.  I'm not sure where it is in 3.2.x with the way things have been split up 

    But basically, on pre 2.4 devices, you use getProperty/setProperty while on newer devives, getValue/setValue, and you really don't want to mix them up for the same target.

    and with getProperty/setProperty, you want to pay attention to fif there is a property defined.  My general rule is there should only be a property if there's a setting (app settings) for that, and don't want to use the .set file for general storage.  No property, things are stored in the .str  Both those files are limited to 8k, and you won't want to use space in the .st if you don't need to.

    With Application.Storage and Application.Properties, it's much clearer which is being used (Storage is no longer a .str file for - it's stored differently and can be much larger than 8k, but the .set file is still 8k at most.)