SetPropperty() - unable to set value defined in properties as a list

Hi, I'm not able to set propperties that are not a number, but as a list.

example:

This is how I defined the properties:

<settingConfig type="list">
<listEntry value="0x000000">@Strings.ColorBlack</listEntry>
<listEntry value="0x555555">@Strings.ColorDarkGray</listEntry>
<listEntry value="0xAAAAAA">@Strings.ColorLightGray</listEntry>
<listEntry value="0xFFFFFF">@Strings.ColorWhite</listEntry>
<listEntry value="0xFFFFAA">@Strings.ColorSand</listEntry>

</settingConfig>
</setting>

//in my code I have something like this

var bgColor = 0x000000;

apProperties.setProperty("BackgroundColor", bgColor );

but it doesn't work.

I need to set the value in settings programmaticaly.

Have you anyone some hint? There is no info in the documentation how to manage the settings.

second question:

Why the simulator doesn't change the settings values (I tested numbers), It works in my watch, but not in the simulator .

Top Replies

FlowState over 4 years ago in reply to FlowState +1

This is how my "c" setting is defined.

<properties>
	<property id="c" type="number">0xaa0000</property>
</properties>

<settings>
	<setting propertyKey="@Properties.c"
		title="@Strings…

All Replies

0 jim_m_58 over 4 years ago in reply to Windy945

Do you close the app settings editor and open it again?

0 Windy945 over 4 years ago in reply to jim_m_58

I did. Thanks to you I will be able to test it in my PC. BTW the settings of my big app change only partially. Which is weird, I would suppose that in case of memory leak, they will not change at all. I will test it more and will report my result later, because it is a little complicated than the example and I'll have to check all the things from your postst.

Thank you for now! I'm your debtor.

0 FlowState over 4 years ago in reply to Windy945

Windy945 said:
1) I didn't know how to refresh the App Settings editor - your last gif helped me very much, so thank you and now I'm going to test my big application. This could be the answer to my very first question. Why the settings in the Settings editor don't change.

So: after each "send settings" it necessary to "reload" the settings, while the checkbox "rebuild" is not checked.

You're welcome!

Well, the way I did it in the GIF is the "fast" way, although it's not intuitive. The other way (as I mentioned before and as Jim mentioned) is to close the editor and reopen it, but it's very slow. I'm very impatient, so I choose to do the fast way which is totally not obvious.

Yeah, it's necessary to reload the settings because the app settings editor is not expecting the settings to change immediately after you send them. Notice that the workflow is "optimized" for pushing settings to the device and not vice-versa, because it assumes that settings usually go in one direction only. There's a button to send settings, but not a button to receive settings.

You'll notice this isn't too different from the real user experience on Garmin Connect Mobile. When you open an app's settings, it loads them from the watch (this takes a couple of seconds). When you press Save, it pushes settings to the watch and *closes the current view*. Note that it doesn't stay on the same view, nor does it refresh the view (if it did, you would have to wait several seconds for the settings to reload anyway).

In other words, Garmin isn't trying to prevent you from doing what you're trying to do, but it also isn't optimizing for that use case. You can do "bidirectional settings" if you want, but the user/dev experience won't be optimal.

What would've been better is if "local" settings rules/dependencies could've been defined which work 100% on the phone, so that no communication is necessary between the phone and the watch for this kind of thing. e.g. It would be great if 1 group of settings could be hidden based on the value of another setting, or if 1 setting could determine the value of other settings (all within the phone app.) But that's obviously something Garmin isn't going to implement, either.

Unfortunately, things like this aren't documented, they're just the kind of thing you have to figure out as you go along.

0 jim_m_58 over 4 years ago in reply to Windy945

You really don't want to do setProperty very often in your app. When you do, it causes a file system write (expensive). And when you set a property, make sure they are the proper type. So for booleans, true or false, not the strings "true" and "false". if the settings are a list, it needs to be a number, like 0xAAAAAA and not the string associated with that list entry..

As far as memory, when you change settings with either the app settings editor or GCM/the Connect IQ app, it will be seen as an increase in peak memory in your app, and how much varies by the number of properties. 5 is less of a peak than 50. Watch "view memory" in the sim, and watch the peak.

0 FlowState over 4 years ago in reply to Windy945

Windy945 said:
I have many settings in my app and for the case that that user gets confused and sets the values in a weird way, I want him to have the possibility to get back to the default values in one step. And because the values are diferent for each size of display, I can't do it in the code by some default variables, because the default values are stored in resources. So I load them from the resources (no problem) and try to set the values to the default. And the dafault values are not necessay the default, they can be for example any other set of values that it also stored in my resources, but the principle is the same. Load and put.

That's interesting, thanks.

Well, to return values to defaults, there is one possibility which isn't perfect: uninstall and reinstall app.

As far as not putting defaults in code, you should also be aware there is/was a design issue in Garmin Connect where you can receive null for a number setting, in which case you would have to either use the default or keep the current value anyway: if the user types an invalid value for a number setting (like "A"), Garmin Connect unfortunately sends null, which can crash your app if you're expecting a number.

Which means that sometimes you may have to put defaults in your code anyway (i.e. your code may duplicate defaults which are already in resources.)

It would've been better if GC would've sent either the default value or the previous value in that case....

It also would've been nice if the API allowed us to get the default value for a given property, but that's also not possible.

I think uninstall + reinstall is the best solution here.

You could even put instructions as "help" using a long label in the settings, although long labels are also an issue in GC (GC iOS will wrap them, and at one point GC Android would cut them off, if I recall correctly.)

So probably the best solution would be to put the instructions for resetting to defaults in the store description and hope people read it.