User application settings

For most wanted watchface feature - look into a new ObjectStore sample how to define default properies and setting options.

Here is a color configuration example:
<resources>

<properties>
<property id="PROP_COLOR" type="number">1</property>
</properties>

<strings>
<string id="title_color">Color</string>

<string id="opt_color_1">Blue</string>
<string id="opt_color_2">Red</string>
<string id="opt_color_3">Green</string>
</strings>

<settings>
<setting propertyKey="@Properties.PROP_COLOR" title="@Strings.title_color">
<settingConfig type="list">
<listEntry value="1">Rez.Strings.opt_color_1</listEntry>
<listEntry value="2">Rez.Strings.opt_color_2</listEntry>
<listEntry value="3">Rez.Strings.opt_color_3</listEntry>
</settingConfig>
</setting>
</settings>

</resources>


Please note that property must be a number if you can use the list of options.

Then, just load your property in the code, for example:

function onSettingsChanged() {
var color = App.getApp().getProperty("PROP_COLOR");
handleYourColorChangesHere(color);
Ui.requestUpdate();
}


Awesome! Thanks for sharing!

Where do we change the settings (as a user)? GE / GCM?

Awesome! Thanks for sharing!

Where do we change the settings (as a user)? GE / GCM?

To answer my own question and assist others:

In Eclipse you have to update the Connect IQ plugin.

Under the Help menu, go to Check for Updates.
Should list two Connect IQ related items.

Once you have updated, you will find an App Settings Editor in the Connect IQ menu!

Happy coding and testing!

Woohoo it works, even on data fields. Thanks for the info Petr.Koula and HERMOT.

Don't you need to put an @ in front of the resource name?

<listEntry value="1">@Rez.Strings.opt_color_1</listEntry>
<listEntry value="2">@Rez.Strings.opt_color_2</listEntry>
<listEntry value="3">@Rez.Strings.opt_color_3</listEntry>


Travis

Don't you need to put an @ in front of the resource name?

<listEntry value="1">@Rez.Strings.opt_color_1</listEntry>
<listEntry value="2">@Rez.Strings.opt_color_2</listEntry>
<listEntry value="3">@Rez.Strings.opt_color_3</listEntry>


Travis

Not sure. I noted that it works even if you drop the @Properties. part.
Garmin's own example has it without @Properties.
Maybe the @Rez is if it is within a string, like attribute values. But as a value in an element perhaps not necessary.

Would like to learn the exact rules though.

To support backwards compatibility with projects both Rez.<Module>.<ID> and @Rez.<Module>.<ID> work. The first way will print a warning when compiling as the @Rez method is the preferred way of referencing a resource withing another resource.

There are also some instances (the icon value in the manifest file comes to mind) where we originally didn't even require the Rez.<Module> before the ID as the value had to be a reference to a resource. In these cases you should still be able to use only the ID of the resource (we really do try our best not to break projects with new SDKs) but a warning is printed indicating it would be better to switch to @Rez notation.

Something I found today in testing, is that the user settings aren't in the "data/<appname>.str" file (the Object Store) but in the "settings/<appname>.set" file in the simulator test directory. So it you want to go back to "no settings defaults" it seems you can just delete the .set file.

Something I found today in testing, is that the user settings aren't in the "data/<appname>.str" file (the Object Store) but in the "settings/<appname>.set" file in the simulator test directory. So it you want to go back to "no settings defaults" it seems you can just delete the .set file.

Noted that too. Was baffled when I couldn't find any new properties in ObjectStore editor in simulator.

To support backwards compatibility with projects both Rez.<Module>.<ID> and @Rez.<Module>.<ID> work. The first way will print a warning when compiling as the @Rez method is the preferred way of referencing a resource withing another resource.

There are also some instances (the icon value in the manifest file comes to mind) where we originally didn't even require the Rez.<Module> before the ID as the value had to be a reference to a resource. In these cases you should still be able to use only the ID of the resource (we really do try our best not to break projects with new SDKs) but a warning is printed indicating it would be better to switch to @Rez notation.

Clarified, thanks.