Can you help me solve strange set/getProperties behaviour?

This post had been a reply to spam.

Have you tried calling loadProperties() before calling getProperty()? It doesn't make sense that it would work given you are able to load the settings on the second run, but it is worth a shot.

Yes I have. Although the fact that it loads the changed settings on the second run has indicated to me that this is possibly unnecessary (bad practice?).

I also note that if I save and get the settings as an operation they reflect the changes, eg

function showSettings()
{
for(var i = 0; i < SETTINGS_QTY; i++)
{
System.println(mSetting.toString());
}
setProperty(SETTINGS, mSettings);
mSettings = getProperty(SETTINGS);
for(var i = 0; i < SETTINGS_QTY; i++)
{
System.println(mSetting.toString());
}
}[/CODE]

Both printouts contain the same data.

I figured out what I was missing, although I think it's a hack rather than correct procedure. Seems the problem is setProperty() can't overwrite the settings array. By calling clearProperties() before setProperty() it works.

Which definitely seems like a bug to me. I hope it is as I have several modules that each save/load properties (via App.getApp()) and I would very much want to avoid coordinating this...

Yes. But calling clearProperties() was a bit extreme on my part. You can of course just call deleteProperty() on the line before setProperty(). If I have understood what you're saying then I think that should take care of your sync worries.

Yes. But calling clearProperties() was a bit extreme on my part. You can of course just call deleteProperty() on the line before setProperty(). If I have understood what you're saying then I think that should take care of your sync worries.

Yes, you're right!

There's no need to call loadProperties and saveProperties as it's done automatically for you. Doing it won't cause any issues, it's just not recommended and in a future release those calls will probably be no-ops.

We'll look into the other issues. Thanks for the report.

Thanks Kyle. So just to be clear, it was only happening to the array. I split it into individual items and they work as normal.

I spent a good amount of time looking into this yesterday afternoon, and tracked down the root of the problem. While I was experimenting, I discovered that if I copy the values from the settings array into a new temp array and save that back to the object store, it would work fine.

Behind the scenes, Connect IQ is checking to see if the array being saved is the same as the one that's already stored since there's no reason to re-save if it's the same. We do this to avoid excessive re-writes to the flash storage. The problem is that the comparison uses .equals(), which just checks the reference to the array, not the values in the array. Reading the settings out of the object store into an array, changing the values, and then saving the array results in no changes since the reference is unchanged. Of course, clearProperties() and deleteProperties() sidesteps the problem, since the test would evaluate to false once the array in the object store is gone.

I'm filing a bug report to get this addressed, but in the meantime using separate values like sharkbait ended up doing will work best. Using a temp array or clear/delete will also work, but this will trigger a re-write every time even if settings have not changed, which introduces slight risk of shortening the life of the flash storage in a customer's device.