Menu2 does not store properties like Menu? Or is it a build for device issue?

I have a timer app where I'm about to change from old menu to menu2, to be able to have checkboxes etc. At the same time, I also change to use the "new" Storage (App.Properties.setValue()) for my properties, instead of the "old" App.getApp().setProperty().

I've been trying it on my own device with "build for device" and it is a bit odd. If I start the app and make some settings in the menu, and go back from the menu, and exit the app via my onBack(), then those settings doesn't persist if I open the app again. (settings are number of periods, period length, track activity). If I do the same thing, but start my activity first and then exit the app, now the settings persist until the next time I open the app. The only thing that changes here is that I start a timer when I start the app, but that seems to be enough to actually store the settings.

Is this a known behavior? Does that have something to do with the switch from the old to the new storage? Or is it a quirk from my building for the device and placing the .prg file on my device?

Top Replies

jim_m_58 over 1 year ago in reply to fuselage +1

Is there a reason you are using Application.Properties and not Application.Storage? I only use Application.Properties if there's a corresponding setting for it (app settings from the phone or GE).
…

All Replies

fuselage over 1 year ago

I realise this might not be a menu <-> menu2 thing but rather a storage thing.

Basically, the only thing i do when a e.g. choose to track or not track activity I store the boolean from the toggle with App.Properties.setValue("key", value). Is there something subtle I'm missing for this to take immediate effect?

When I push the start button, first thing I do is to collect the properties with App.Properties.getValue("key") and it seems to get the right values. But, as I said, if I exit the app before I push start, then the old values are the ones I get when I restart the app.

jim_m_58 over 1 year ago in reply to fuselage

Is there a reason you are using Application.Properties and not Application.Storage? I only use Application.Properties if there's a corresponding setting for it (app settings from the phone or GE).

Is this in the sim or real device, or both?

Maybe add some println calls for when you are reading/storing things including what's read or stored so you can see what's happening and when..

fuselage over 1 year ago in reply to jim_m_58

Thank you Jim!

As always when I'm coding, it was me and not any issues with storage/properties/menu2. Thanks to println I noticed that I had a variable that was null before I started my activity and I made calls to this variable at exit, i.e. even when I exit before I start an activity. Which caused the app to crash, but I didn't see the crash on my device, it looked like a regular exit. When I tried the simulator, the crash was visible and I could track it down.

Actually, I don't have any specific reason for storage vs properties. It was properties in the first example I followed and then it just happened to stay that way. Maybe I should switch while I'm at it. I guess you have to do some kind of check if the variable is null the first time you try to access the variable? like
value = Storage.getValue("key");
if (value == null) {
save an initial value in storage;
}

jim_m_58 over 1 year ago in reply to fuselage

I never really liked the original Application.getApp().getProperty and setPropery() as the same call was used for things with a property (the settings/.set file) and those without (data/.str file - the object store). Application.Properties and Application.Storage is much clearer. With Application.Properties you need to be careful as changes to the property/setting in the xml file can cause a reset with with a new version of your app. Application.Storage is much safer..