parsing string to dictionary object or persisting dictionaries

You can definitely persist dictionaries. Have a look at the documentation for setProperty.

var val = { 1 => "abc", "def" => 2.0 };
setProperty(0, val);

var dup = getProperty(0);
Sys.println(val.toString());


Travis

I remember having lots of trouble persisting dictionaries and arrays earlier; the values wouldn't really persist, e.g. truly sync to disk. I guess that's been fixed?

I have some pretty ugly code that works around arrays not persisting correctly in order to implement a PersistentSet. Would love to nuke that from orbit.

I remember having lots of trouble persisting dictionaries and arrays earlier; the values wouldn't really persist, e.g. truly sync to disk. I guess that's been fixed?

I have some pretty ugly code that works around arrays not persisting correctly in order to implement a PersistentSet. Would love to nuke that from orbit.

In the simulator, you must ctrl-k the app for the .str to be saved (it happens as part of "onStop()").

Could this be what you see? Also, with 1.1.2, when you start the simulator, it tends to wipe out any .str files that weren't actually written by the a program..

Case in point. I have a couple of things that require an "API key" to work, and I have that .str file saved off with that key, and copy it to the location needed by the simulator for testing. If I shut down the simulator and then restart the simulator, that .str file is deleted, but if I simply re-add the key from the .prg, it's saved and hangs around....

In the simulator, you must ctrl-k the app for the .str to be saved (it happens as part of "onStop()").

Could this be what you see? Also, with 1.1.2, when you start the simulator, it tends to wipe out any .str files that weren't actually written by the a program..

Case in point. I have a couple of things that require an "API key" to work, and I have that .str file saved off with that key, and copy it to the location needed by the simulator for testing. If I shut down the simulator and then restart the simulator, that .str file is deleted, but if I simply re-add the key from the .prg, it's saved and hangs around....

Interesting. It's been quite a while since I last tried this, but I vaguely remember it not working on a Vivoactive either. Led to really funky behavior where the value would appear to be persisted, but when you swiped away and swiped back, the old value would return.

My work around is to only ever use strings. If I want to persist an array, I concatenate the elements with a comma, and then persist that. To deserialize, I just do a split on the comma. Again, pretty ugly, but so far works 100% of the time.

Interesting. It's been quite a while since I last tried this, but I vaguely remember it not working on a Vivoactive either. Led to really funky behavior where the value would appear to be persisted, but when you swiped away and swiped back, the old value would return.

My work around is to only ever use strings. If I want to persist an array, I concatenate the elements with a comma, and then persist that. To deserialize, I just do a split on the comma. Again, pretty ugly, but so far works 100% of the time.

On the va, I'm now using the Object store for a bunch of different things, and with FW 3.00 - CIQ 1.1.2, I have found it to to VERY consistent on how it does things and find the OS consistently stored correctly in the OS when I change it. And I often don't use strings for the key value. I only store things that are strings as strings!

There were bugs serializing Array and Dictionary objects if they had not been reallocated or if you persisted them in onStop(). I had workarounds in place that made a deep copy of the Array/Vector, and then serialized that. I'm fairly sure the workaround is no longer necessary and that these bugs have been fixed.