Feature request: Enum option for app configuration

Help & Feedback Feedback
1

The pre-release version of the app store and application configuration has configFields supporting string / bool / int / float (see App Configuration Fields). Looking at the existing apps and thinking about where it’s heading, I think an enum is a relatively high ROI improvement.

Right now the only workaround is string + pattern (like “north|south|east|west”), which works but isn’t great:

  • the companion app renders a free-text box instead of a picker
  • there’s no way to attach a friendly display label to each option
  • a typo that happens to satisfy the pattern is indistinguishable from a real choice

Something minimal, e.g., an enum type that mostly rides on the existing string plumbing:

{
  "id": "barcodeFormat",
  "type": "enum",
  "label": "Barcode format",
  "description": "Symbology the scanner should expect.",
  "default": "code128",
  "values": ["code128", "ean13", "upca", "qr"],
  "labels": ["Code 128", "EAN-13", "UPC-A", "QR Code"] // optional, for display
}

id / label / description / default / required / validationMessage would all work exactly as they do for string today. The only new bits are values (the allowed tokens, default must be one of them) and an optional labels array for display text. Stored on the watch as a plain JSON string, same as now.

I’m aware that dynamic configuration is a rabbit hole

  • ranges
  • date of the week pickers (for schedules)
  • times
  • coordinates (something the existing Waypoint app could use)
  • workout builders (blocks of types/durations/paces

All in due time, I think, but enums would (I think) be a pretty straightforward and high value addition.

4 Likes
2

I would second this as a really useful configuration feature. I would certainly be making use of it.

4

@craig.nakamoto this looks awesome, is it perhaps a reply on a different topic than intended? This is an ask for an enum config value type.

5

Thanks, not sure how that happenned. Yes, it was a reply for a different post about watch faces.

1 Like
6

You’ve got my vote on this one for sure, and I can put some numbers to it from two of the apps I have published.

Between Ebb and World Clock I have 22 config fields, and 6 of them are already enums written as a pattern: off|moderate|strong, m|ft, gps|system, smile|emotional, and off|always|night in both apps. So a third of my string fields are @shatter_poetry’s case exactly, and none of them gains anything from being free text.

The display-label point is the one I feel most. My values are lowercase machine tokens because the app reads them, so the wearer is shown emotional and moderate and asked to type one. label and description already exist per field; there is just nowhere to put per-value text.

One case where the pattern approach is worse than it looks. World Clock takes an airport code for a timezone, validated as [A-Z]{3}. That pattern accepts 17,576 strings and the app recognises 147 of them, so over 99% of what the phone will happily accept is a typo the app has to reject after the fact – and it cannot tell the wearer whether they mistyped or asked for a city that is not carried. @shatter_poetry’s third bullet, at its worst.

I would not suggest 147 values in a picker solves that one; it may be that very large sets want something else entirely, and the minimal enum is worth having on its own for the small fixed sets that are most of the real cases, but it would be useful in my case.

Two things I noticed while counting, just observations rather than requests:

  • Multi-select is the same shape. World Clock has a shortlist field, currently [A-Z, ]*, which is a comma-separated set drawn from those codes. If enum ever grows a multiple-selection form it would land straight onto that like butter on toast.
  • Some string fields are not the wearer’s at all. Three of Ebb’s fields are state the app persists – a remembered GPS fix and a UTC offset – and they appear in the phone app as things to fill in. I have labelled them “(automatic)” because that is the best that can be done today. Different problem from enums, mentioned only because both surface in the same list.

I’m more than happy to be a test case for whatever shape it takes; every one of those six fields is a one-line change at my end.