Major bug in user configuration settings

There is an oddness with user settings and GCM. It's been reported to Garmin.

Let's day you have a "version 1" in the store with user settings, and it's installed on a watch. All is fine.

But then "version 2" is put in the store. There is a time where a user may still have "version 1" on their watch (or "auto update apps" is turned off - it will stay "version 1")

With GCM, you can be in a state where "version 1" is on the watch, yet when you go into user settings on GCM, you get the "version 2" version of user settings.

So, there is a chance that something in "version 2" settings isn't compatible with "version 1" on the watch and causes a crash.

The way to avoid this is to make sure that "version 1" has proper range checking and can handle something it doesn't expect.

There is an oddness with user settings and GCM. It's been reported to Garmin.

The way to avoid this is to make sure that "version 1" has proper range checking and can handle something it doesn't expect.

Can you provide an example? I'm not too sure this si the dame issue but might be ;-)

Let's say that in version 1, you have a "list" that can return 0,1,2,3 (4 different options), but in version 2, you added 2 more options, so the "list" could return 0,1,2,3,4,5.

If the user picked one of the new options in version 2 (4 or 5), you want to make sure in version 1, that it's only using 0,1,2,3 and ignoring 4 or 5, as it doesn't know what to do with 4 and 5, but in this case, it could get a 4 or 5 in user settings.

But that would only happen if the the phone app was out of sync with the watch no? How could that happen?

It does seem like a similar issue, but in my case

1) version 1 installed with an option that had 5 choices

2) version 2 installed, the option now has 6 choices

3) user selects one of the options from the list of 6

4) default watch face shown

Selecting my watch face again everthing works as expected.

But that would only happen if the the phone app was out of sync with the watch no? How could that happen?

It does seem like a similar issue, but in my case

1) version 1 installed with an option that had 5 choices

2) version 2 installed, the option now has 6 choices

3) user selects one of the options from the list of 6

4) default watch face shown

Selecting my watch face again everthing works as expected.

Maybe you're "onSettingChanged()" code doesn't deal the new option (unknown) correctly, but your start up code does? Or maybe during that time the watchface on the device was updated to version 2.

Also, see this thread about earlier versons of Garmin Express and "lists"

https://forums.garmin.com/showthread.php?335701-USER-SETTINGS-Elements-disappear-after-configuring-colors-FIX-AVAILABLE&p=764731#post764731

I dont do anything in onSettingChange other than this ...

hidden var observer;

function initialize() {
AppBase.initialize();
}

function getInitialView() {
var view = new BigTimeView();
setObserver(view);
return [view];
}

function onSettingsChanged() {
self.broadcast(:settingsChanged);
}

function setObserver(observer) {
self.observer = observer;
}

hidden function broadcast(symbol) {
observer.notify(symbol);
}

function getUserSelectedFont() {
return app.getProperty("PROP_FONT");
}

Another user has reported

t's working well on my Vivoactive once configured, however to get it to show the activity tracker, the date in the correct format and using kcal I need to ensure that I set those (i.e. change them from another value) to my preference on the last change. If I get them right, then go back in to the settings just to change the font then the settings looking right in Connect on Android but the watch defaults those other settings.

Whilst that isn't clear there clearly is a problem with the way settings are working

In addition to the code I've already posted I'm doing this in the onUpdate.

var app = App.getApp();
var cfg_colour = WB;//app.getProperty("PROP_COLOUR");

I did take a look at the object store example but it looks much different to how it's been suggested to do it on the forum.

The problem does seem to be when someone installs a new version, and I'm having trouble recreating the issue.

Let's say that in version 1, you have a "list" that can return 0,1,2,3 (4 different options), but in version 2, you added 2 more options, so the "list" could return 0,1,2,3,4,5.

If the user picked one of the new options in version 2 (4 or 5), you want to make sure in version 1, that it's only using 0,1,2,3 and ignoring 4 or 5, as it doesn't know what to do with 4 and 5, but in this case, it could get a 4 or 5 in user settings.

I dont understand how the connect app and the watchface could get so out of sync in the this example. Surely when you download the watchface the app gets updated at the same time. How is it possible for the app to be on the new version of the apps config but the watch have the old version of the app. ?! Confused.

I dont understand how the connect app and the watchface could get so out of sync in the this example. Surely when you download the watchface the app gets updated at the same time. How is it possible for the app to be on the new version of the apps config but the watch have the old version of the app. ?! Confused.

GCM gets the settings data json from the app store, and it's for the current version in the app store, and NOT the version on the watch after an update in the app store all the time.

So you got version 1 on the watch and it's not been updated, but the settings logic comes from the app store for the newest version in the app store, not the version on the watch.

It's a bit hard to reproduce as you have to update the app store for it to happen, but I've seen it myself. It's been reported and is an open problem right now with Garmin. The fix is to make sure each version of something only accepts settings that make sense for that version.

Since I started doing that, I've not had a problem due to these things being out of sync.

I'll admit there are some rough edges with "User Settings" right now, but most can be avoid based on coding to avoid them. (the problem with GE a while back where it wasn't return the "value" for a list item, but instead the index to the list item, for example - See HermoT's post I linked here on how code for that)

Ah makes sense, a bit of an oversight by Garmin methinks.

Anyhow out of interest what do you do if you read in an invalid value? Do you just force the first acceptable value? Thanks as ever! :-)