Settings and Dependent Lists

Hi everyone,

Is it possible to create dependent lists in settings for a watch face?

I would like to be able to have 2 lists, the results of the first list effects what is shown on the second list.

For example in list 1 Produce List, I select Fruit. Then the second list Food, only shows fruit e.g. Apple, Banana etc? Conversely, if I select Vegetable in list 1, I only see Cabbage, Green Beans in the second list?

1.Produce List

2.Food List (dependent on list 1)

0 9635560 over 5 years ago

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.)

0 jim_m_58 over 5 years ago

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

0 9635560 over 5 years ago in reply to jim_m_58

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

0 harpo666 over 5 years ago in reply to jim_m_58

Thanks Jim and 9635560!

I am using it for a clock face for the settings that come with the Connect IQ app so it sounds like a static file will not work.

This would be a nice feature for clock faces.

0 jim_m_58 over 5 years ago in reply to harpo666

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)

0 9635560 over 5 years ago in reply to jim_m_58

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.

0 jim_m_58 over 5 years ago in reply to 9635560

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.

0 9635560 over 5 years ago in reply to jim_m_58

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.