Settings and Dependent Lists

If only... if you create a feature request, I'll vote for that. (I've voted for some similar ones, not sure if I've voted for that one specifically.)

With settings, what's defined in the XML becomes a json file when you compile (it's in the bin directory for your project).  The app settings editor in eclipse uses that.

When you build an iq file, the json files for settings are included in that.

And when a user wants to change settings, that info is pulled down from the app store.  This is why app settings don't work with sideloads.  So it's static info defined when you upload your app to the store.

For the above, you could use 3 lists. If Produce is Fruit, use the item picked in the fruit list, for example.

For device apps and widget, you could move the logic to menus within the app

All the same, would be nice to extend the schema a little to allow for more nuanced settings. 

While this may seem simple to add, it's really not as a bunch of things would be impacted.  CIQ to generate things needed, and be done in a way that existing apps aren't impacted, possibly something in the app store, then the Connect IQ app, Garmin Connect Mobile, and Garmin Express, so 4 different groups within Garmin that would have to coordinate the change and fit it into their own schedules.

Like I said, you can do what you want with 3 lists today:

1) type of Produce

-Fruit

-Veggie

2) type of Fruit

-Apple

-Banana

-Lemon

-Peach

3) type of Veggie

-Cabbage

-Beans

-Lettuce

-Rutabaga

Or, you could do it with just 1 list:

1) which produce?

-Apple (Fruit)

-Banana(Fruit)

-Lemon (Fruit)

-Peach (Fruit)

-Cabbage (Veggie)

-Beans (Veggie)

-Lettuce (Veggie)

-Rutabaga(Veggie)

It’s a “workaround” at best, though. 

I appreciate the difficulty, and that it cannot happen tomorrow, but it is one area where Garmin is utterly left behind by competitors where it could and should be the other way around. 

Extending the schema in the right way would allow backward compatibility so then it is just the coordination with the various groups to extend for new features. 

As I say, I appreciate the difficulty, but I believe this is one Garmin needs to be working towards. 

The “simple” list solution you propose only works with a very limited subset of use cases. 

There's a lot that could be done, and there things to watch out for - be sure to check the New Developer FAQ and this  section:

https://forums.garmin.com/developer/connect-iq/w/wiki/4/new-developer-faq#settings-crash

I know one of the things that's been requested since day 1 is "reusable lists".  Say you have a list of colors, and there are options for 5 different field colors.  You need to have the same list in your settings 5 times, instead of just having a common list you reference 5 times.

And sometimes, it's a matter of just thinking about how best to use what's available.  Maybe changing what you use for properties, so it works better for the user.

And sometimes, it is the reality that there are mutually incompatible option sets.

This is not rocket science.

This is Garmin's customer experience.

Can I build a workaround that "sorta" works? Yes, of course I can.

Does that improve the customer experience? No, not really.