User settings destroying watchface (white screen) only with Connect app

When I checked this morning of course somebody managed to not read my description, change settings via the connect app and give me a 1 star rating in return...

Has anybody experienced the same problem?[/B]

Yes. Be certain of this fact. Lots of people will NOT read anything helpful you have written. Fact.

I had one user who couldn;t download the watch because of Garmin server issues and left my watchface a bad rating. Go figure. It is annying and lots of people have asked Garmin to allow users to leave a contact email address. Best thing is to ask Garmin to remove the bad rating.

As for the user settings you might want to take a look here, I'm told there is a problem that Garmin are aware of...

https://forums.garmin.com/showthread.php?335934-Major-bug-in-user-configuration-settings

specifically...

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)

Yes. Be certain of this fact. Lots of people will NOT read anything helpful you have written. Fact.

I second that!!


And NO, there is no way (that i know of) to be able to test user settings w/o uploading it to the store.

For me, eclipse is broken.
Command line, the user settings thing does not work.
it's a hack... (change properties.xml, delete the SET file from the Garmin Directory and then recompile and run)

That's what i'm doing..

FUn! Fun!! Fun!! L:-p

Hi RUPERTHAWKES

Thanks for your answer. This seems to be a different problem. As I understand it it occurs when you add new settings to a watchface that already used settings.

For my watchface this can't be the case since it doesn't have any predessecors using settings. So there can't be any version conflicts. And it's also not about certain settings. Any setting can fail when trying to be sent with the phone/tablet app.

Something during the sending of settings to the watch from the Connect app seems to go wrong. With Garmin Express it's no problem at all...

There is a known issue with Garmin Connect Mobile that causes the value for a property to get the wrong value. If you are using a settingConfig of type list, the value of the property is set to the index of the property in the dropdown, not the value of the listEntry. Could this be affecting you?

I believe the following is an example of the problem. If you use the following setting/property definitions...

<properties>
<property id="Option" type="number">0x0000aa</property>
</properties>

<settings>
<setting propertyKey="@Properties.Option" title="@Strings.OptionTitle" prompt="@Strings.OptionPrompt">
<settingConfig type="list">
<listEntry value="0x0000aa">@Strings.Blue</listEntry>
<listEntry value="0x00aa00">@Strings.Green</listEntry>
<listEntry value="0xaa0000">@Strings.Red</listEntry>
</settingConfig>
</setting>
</settings>


and the user selects Red, the value returned by App.getApp().getProperty("Option") will be 2 (because the user selected the second option in the dropdown) and not the expected value 0xaa0000. This only happens when the setting is changed from Garmin Connect Mobile and it works fine from Garmin Express.

The current workaround is to use values that map to the indexes in the property definition, and then map the values back to the appropriate values in your application code...

<properties>
<property id="Option" type="number">0</property>
</properties>

<settings>
<setting propertyKey="@Properties.Option" title="@Strings.OptionTitle" prompt="@Strings.OptionPrompt">
<settingConfig type="list">
<listEntry value="0">@Strings.Blue</listEntry>
<listEntry value="1">@Strings.Green</listEntry>
<listEntry value="2">@Strings.Red</listEntry>
</settingConfig>
</setting>
</settings>


var option = App.getApp().getProperty("Option");

//
// work around garmin connect mobile bug(s)
//

// order of elements in this table must match list entries in resource file
var option_lookup_table = [
0x0000aa, // Blue
0x00aa00, // Green
0xaa0000 // Red
];

// in some cases values are coming back as strings instead of number. force
// the value to a number
option = option_lookup_table[ option.toNumber() ];


when I do changes on the settings it either doesn't work at all (iPhone Connect app) or the watchface gets broken (Android Connect app). Also the order of the settings gets totally mixed up. When using Garmin Express, everything works like a charm, correct order and fully functioning

I have a user reporting exactly the same thing. Change a setting on the Garmin Android connect app and a COMPLETELY DIFFERENT setting gets changed. However it works fine with Garmin Express. This does NOT sound like the list issue reported already as it's not that you get a different item in the list from the one you selected BUT it changes a different setting altogether.

Is there anyone from Garmin that can test, comment, verify, fix, etc?!?!?

I've added this to the top of my watchface descrription to help users...

****** THERE IS A MAJOR BUG IN GARMINS CONNECT APP ON ANDROID / IOS THAT MEANS CHANGING SETTINGS FOR A WATCHFACE ISN'T WORKING. UNTIL THEY FIX THIS PLEASE CHANGE SETTINGS VIA THE GARMIN EXPRESS APP ON PC / MAC. PLEASE DO NOT LEAVE BAD RATINGS BECAUSE THIS IS A GARMIN BUG NOT A BUG IN MY WATCHFACE - THANK YOU!!!

HAHAHA. I ask about this 2 week ago:

https://forums.garmin.com/showthread.php?333976-Android-CGM-write-strange-values-to-properites

sounds familiar?

HAHAHA. I ask about this 2 week ago:

https://forums.garmin.com/showthread.php?333976-Android-CGM-write-strange-values-to-properites

sounds familiar?

Can you pls provide an actual example of how to code a fix for this broken behaviour? Or Garmin, can you provide a fix?

Garmin has ciq programmes know where.
I write now rugged watchface, and change property used 'user profile' as key:value :) this work offline and need less power (blutooth and wifi/lte/3g in phone)

I wanted to chime in here and let everyone know that we are aware of the issues both users and developers have encountered with app settings. Many of these issues are related to pieces of the Connect IQ ecosystem that are outside of the SDK (e.g. App Store, Garmin Connect Mobile, Garmin Express), so though your app may be written properly and function fine in the simulator, users can have a different experience. We're working to get these things addressed, and I apologize for any delay in getting fixes out.

We're also aware of the frustration many developers have had testing app settings. We are working with the app store team to allow submitted, pending-approval apps to be available to the developer for testing app settings. In fact, this has always been the intent, but it has not worked as expected. In the short term, I recommend that developers continue to test app settings in the app settings editor within Eclipse since that has been proven to be most reliable and accurate (I can't claim it's entirely bug free, of course!). This will ensure that your apps are coded correctly even if a bug in the app store -> device pipeline causes an issue for customers.

I definitely empathize with everyone, and don't want to make any excuses. There are some bugs related to app settings, we're aware of them, and we're working to get them addressed.