Is Application.Storage updated during application execution?

It's been a couple of years since I explored this question, and I recall that the answer then was (surprisingly): "No it's only updated when the app closes".

It seems that might have changed, and that the answer now may be "Yes".

And I'm specifically referring to CIQ 2.4+ watchApps.

I would like to use Storage.setValue() in my app and later, in the the same application execution, use Storage.getValue() to retrieve the value, i.e. both persist the value over multiple executions and be able to retrieve the value fn the current execution i.e. treat it like a global. (I assume there's some processing overhead, which I can live with.)

There is an obscure reference to data being "written to disk", which hints at read/write latency, and describes its use when retrieving in a later execution, with "The next time the application is launched, the stored location value can be retrieved..", but it makes no reference to retrieving in the current execution.

Is there a reliable explanation of the behaviour?

Top Replies

FlowState over 2 years ago +2 verified

Well, the documentation says:

Information is automatically saved on disk when Storage.setValue() is called.

If you take that at face value, it seems to imply that the write is immediate (and that getValue…
SirLancelot over 2 years ago +1

Yes, storage is updated during execution. I've never had a problem with setting and retrieving values on the same app run.

All Replies

0 SirLancelot over 2 years ago

Yes, storage is updated during execution. I've never had a problem with setting and retrieving values on the same app run.

+1 FlowState over 2 years ago

Well, the documentation says:

Information is automatically saved on disk when Storage.setValue() is called.

If you take that at face value, it seems to imply that the write is immediate (and that getValue() will always retrieve the last-written value).

(I don't use Application.Storage because all my apps support CIQ 1 devices, which don't support Application.Storage.)

Alan.raceQs said:
It's been a couple of years since I explored this question, and I recall that the answer then was (surprisingly): "No it's only updated when the app closes".

You might be thinking of the object store (AppBase.getProperty()/setProperty()), which is cached in RAM and is only persisted when the application closes.

Accessing Properties and Settings: Object Store

Prior to API level 2.4.0, all content was persisted in the object store. If your app runs on Connect IQ System 1 devices, you will need to use AppBase.getProperty() and AppBase.setProperty() to persist data. These functions allow access to both settings and persisted data.

The object store is a Dictionary that lives in memory until your app terminates, at which point it is saved to disk. Because the object store costs against your runtime memory, do not use these methods unless you are running on System 1 devices.

Reading between the lines, a crucial difference between the object store (pre-CIQ 2.4) and application storage (CIQ 2.4+) is that the object store is cached in RAM and application storage is not.

0 Alan.raceQs over 2 years ago in reply to FlowState

FlowState said:
You might be thinking of the object store (AppBase.getProperty()/setProperty()), which is cached in RAM and is only persisted when the application closes.

I think you are right, thanks.

0 jim_m_58 over 2 years ago

That was the case with Application.getApp()/setProperties, (the old object store) but isn't the case with Application.Storage.setValue()

0 _psx_ over 2 years ago in reply to Alan.raceQs

operations on storage are very expensive so make some tests before choosing storage as globals

0 flocsy🤠 over 2 years ago

Sounds like you might have a similar problem to this: https://forums.garmin.com/developer/connect-iq/f/discussion/297635/the-properties-won-t-change-after-the-saving-action-if-the-memory-usage-is-near-the-limit You can test it by logging the free memory, ie:

var stats = System.getSystemStats();

System.println("free: " + stats.freeMemory);

just before you call Storage.setValue()

0 Alan.raceQs over 2 years ago in reply to _psx_

_psx_ said:
operations on storage are very expensive

I wonder if you could quantify that? Expensive in memory, processing cycles, wear and tear?

0 flocsy🤠 over 2 years ago in reply to Alan.raceQs

In disk IO.
However given the miniature memory size we get I mostly optimize for memory size (code+data) even when I know it's not the best choice for battery or even "disk" size. One example of that was when I removed lots of code from my fitContributor. The old code was something like:

var mLastHr;

function compute(hr) {
if (hr != mLastHr) {
mHrField.setData(hr);
}
}

But I have lots of fields in the fit file so this kind of "optimizing" the code enforces me to knowingly waste on at least these things: 1. more data written to the fit file => 2. more data transferred on BT to the phone => more data uploaded to the internet. All this will effect the watch battery + phone battery (less of an issue probably)

0 Alan.raceQs over 2 years ago in reply to flocsy🤠

flocsy🤠 said:
In disk IO.

How does that translate to performance? Are you saying the saveValue() function is blocked until the write is complete? We're talking solid state memory. What's the latency milliseconds,microseconds? Do you have any test results?

0 jim_m_58 over 2 years ago in reply to Alan.raceQs

With the object store using setProperyty, the storage was loaded when the app started, and written only when the app exited. With Application.Storage, the data is loaded for a key when it's requested (getValue) and written if there is a setValue call. The reason being the data for a given key can be larger than the whole old object store. So lots more filesystm IO with Application.Storage.