Use symbols for keys/values of application state dictionnary

Hi there!

I'm building my first application and I'm trying to store/restore the state of the application.

I was thinking to use symbols for keys or values for the state dictionary, but it does not work.

This works perfectly:

function onStart(state) {
	if(state != null) {
		Sys.println(state.get("hey")); //print "ho"
	}
}

function onStop(state) {
	state.put("hey", "ho");
}

This does not work:

function onStart(state) {
	if(state != null) {
		Sys.println(state.get(:hey));
	}
}

function onStop(state) {
	state.put(:hey, "ho");
}

Much more embarrassing, it is also not possible to store symbols as values of the state dictionary:

function onStart(state) {
	if(state != null) {
		var ho = state.get("hey"));
		Sys.println(ho == :ho); //print false
	}
}

function onStop(state) {
	state.put("hey", :ho);
}

Moreover, in the last two cases, the simulator has a very confusing behavior: it returns the last valid state (i.e. if you execute these three pieces of code one after the other, you get {"hey" => "ho"} for the state in the second and third example).

Is it a bug? My understanding is that symbols are managed at compile time. So it should not be a problem to use them as key or value for the application state.

Matthieu.

travis.vitek over 10 years ago

You are dealing with several different things here. The type of the object behind the name state is Dictionary. Do you have problems using symbols as keys or values with a Dictionary directly? I'm betting that you do not.

The second area of concern is that the state object is coming from the persisted object state. I'm betting that the state object is stored to the object store via setProperty() and getProperty(), which have restrictions on the use of symbols. Have a look at the documentation here. I'm betting that this is where the problem is coming from.

Former Member over 10 years ago

Symbols are not allowed in the object store because they can change values when an app is recompiled.

You are also encountering an outstanding issue with the object store. Changes made in onStop are not saved because the store was being committed to disk prior to that function executing. This issue was fixed after the 1.1.1 update, and should roll out with the 1.1.2 release.

travis.vitek over 10 years ago

Brian,

Is an application/widget expected to save/restore its settings via the state parameter, or via setProperty/getProperty?

matcora over 10 years ago

Thanks for your replies.

@TRAVIS.VITEK Of course, I have no problem with classic dictionaries.

@Brian.ConnectIQ I understand this can be a problem for application settings which must persist even after an update of the application. But for temporary state storage, it should be allowed. That kills a little bit the principle of symbols, as I will need to create constants to represent my symbols in the state dictionary.

travis.vitek over 10 years ago

I think the current documentation is lacking in this respect. If the state object is supposed to be serialized and deserialized automatically by the framework, then it needs to be something that a later version of your application will be able to read. This isn't clearly spelled out, but I believe this is happening.

This is not a use case where symbols make sense, so while it may be more work to create enumerators (or other constants), doing so is a more appropriate choice.

Travis

Former Member over 10 years ago

Thanks for your replies.
@Brian.ConnectIQ I understand this can be a problem for application settings which must persist even after an update of the application. But for temporary state storage, it should be allowed. That kills a little bit the principle of symbols, as I will need to create constants to represent my symbols in the state dictionary.

There is no temporary state storage. There is only the object store. If you want to store something during run time, you can save it in any app variable. Storing symbols in the object store would require converting them to strings, which would also kill the principle of symbols.

Brian,

Is an application/widget expected to save/restore its settings via the state parameter, or via setProperty/getProperty?

I'm not certain what you are referring to with the state parameter. saving and restoring settings should be done with the object store.

travis.vitek over 10 years ago

I'm not certain what you are referring to with the state parameter. saving and restoring settings should be done with the object store.

Perhaps it will make sense to ask a slightly different question. The onStart() and onStop() methods have a state parameter that may be null. Why would a developer bother storing data into state? Provided that state is non-null, the developer has two options; they can put/get the data from the state Dictionary, or they can just access the object store methods setProperty/getProperty. If there is only the object store, why two methods for doing the same exact thing? If it is more efficient for the application to put/get properties from state, then why not just always give the user the state parameter and let them use that, and then allowing the framework to serialize that state as needed?

Former Member over 10 years ago

Ah,

That state is for app suspend and resume support. The documentation explains:

onStop

If the state parameter is not null, then the app is being suspended with the intention of starting again. This allows for the app to be restored to its previous state. This state is separate from the object store in that this data will only be available if the app is resumed.

onStart

It is also possible to be given a dictionary of state data, indicating that the app was previously closed with the intention of allowing it to return to its previous state. The state parameter may be null, indicating that the app was previously fully stopped.

The dictionary may or may not be passed to these functions, and I don't believe it is guaranteed that the app will be resumed if it is suspended. This is however, is also a feature of the system that isn't used anywhere in products yet, so for now it is safe to ignore this argument.