getProperty() giving error

Former Member over 10 years ago

Having saved a small 2D array (50 * 3) with setProperty(MYKEY) by app is now giving the warning "Unable to deserialize the Application properties" when trying to load it back in with getProperty(MYKEY). The app keeps running, but getProperty() returns null. Depending on the array contents it seems like it either works, or fails 100% of the time.

Do you want a copy of my properties file? Or the data I saved into the array?

travis.vitek over 10 years ago

It has been mentioned that the size of the property data file (including the names of the properties themselves) cannot exceed 8192 bytes. Are you exceeding this limit? Out of curiosity, how are you serializing/deserializing the arrays?

Former Member over 10 years ago

Thanks, I hadn't seen the 8192 byte limit - would be nice to have that added to the API docs. I haven't checked, but I'm assuming that (50 * 3 * float) won't even come close to 8192 bytes.

As for serializing/deserializing, I'm just calling setProperty()/getProperty(). I assumed that they could handle 2D arrays, but perhaps that is the problem? They can definitely handle a 1D array. The API docs simply say "store the given data in the object (cannot be a Symbol)".

Kyle.ConnectIQ over 10 years ago

If you want to give us your properties file we can see what the specific issue is that is preventing you from being able to retrieve the data.

Former Member over 10 years ago

Thanks Kyle, can you confirm please which data types are supposed by setProperty()/getProperty() ? Is it just the simple data types Number, Float, String ? Or do they support 1D/2D arrays, Moments, etc.

I've looked at the APP.STR properties file, and when I'm getting the "Unable to deserialize the Application properties" error on app loading the properties file is of 0-length, suggesting that something went wrong while writing it, rather than the problem being with the reading functions.

Kyle.ConnectIQ over 10 years ago

You can store Strings, Numbers, Floats, Booleans, and null values. They can be individual values or in an array or dictionary.

Former Member over 10 years ago

There shouldn't be any issues with storing a 2D array as long as all the elements are one of the allowed types.

Former Member over 10 years ago

OK, thanks. So this is a bug then? As I understand it info.position.toDegrees() returns an array with 2 elements of Float:

locs = info.position.toDegrees();

app.setProperty(TEST_KEY, locs);

doesn't give a runtime error, but causes a 0-length APP.STR properties file to be written (this is with Windows 7).

Former Member over 10 years ago

But this does work by writing a correct properties file that can then be read back in:

var a = [locs[0].toFloat(), locs[1].toFloat()];
app.setProperty(TEST_KEY, a);

Sorry, I thought locs[] was an array of Float, but it is actually an array of Double. Forcing the array to be Float allows setProperty() to work.

So the bug is that setProperty() can't handle objects of type Double? It wipes out the entire contents of the properties file, and it doesn't give an error message.

Former Member over 10 years ago

It looks like the documentation does not specify this, but when we added long and double support to Monkey C, we updated the positioning APIs to use doubles for toDegrees and toRadians. These values need to be doubles because the quantization error on floats is greater than the accuracy of GPS, which will cause a loss of resolution.

If you can accept some loss of precision (which I unfortunately can't quantify for you because I can't find it), then you should convert to float as in your second post.

If the precision loss will cause problems, there isn't a good way to save them in properties at this time, but we will be supporting longs and doubles for serialization (and subsequently the object store) in a future release.