Checkbox settings and colour configuration

If they need to be able to edit the lists on the device (in the sense of add/deleting items or changing labels), then you can't use the old Menu as it isn't dynamic. (I don't think it's feasible/desirable to destroy and recreate the whole hierarchy every time the user makes an edit on the watch).

You would need something like DMenu or your own custom view.

What I do works on old and new devices, touch and non touch,  Maybe 20 lines of code.  The first example app I posted is less than 14k.

That's no problem, even if you don't use a menu

If you then decided that you wanted to show the next 10 days and today on your app, instead of the next 5 days, would your code be able to handle them all by scrolling through the list of data?

You're omitting some of the things that Menu2 would give you such as:

- Automatic wrapping / formatting. (e.g. "A longer line of text" which doesn't fit on a single line would automatically be displayed as a truncated single line when the menu item is not focused, and displayed as two lines when the item is focused.)

- Nice UX for things like toggles

- Animations (including touch-specific "bounce" animations for when you try to scroll past the ends of a menu)

- Device-specific look and feel (at least for devices that aren't too new)

- Device-specific touch handling (this applies more to DMenu, as the newer watches are fairly consistent with touch interaction). If you wrote a list view for the original Vivoactive, you would have to make sure it scrolls horizontally, as vertical swipes aren't supported on VA.

I find that when I code my own views / controls, I spend a bit of time handling edge cases, tweaking things to try to make them look nicer, etc. The advantage of using a native view is I don't have to care about any of that.

But yeah, if you just want a simple list, it isn't too hard to implement yourself.

And I agree that maybe a menu isn't always the best solution for displaying some random list in an app.

Yes.  But my weather source only supplies the next 5 days. Making it 10 would be a minor change in my app, but I don't have that data.

All are trivial and if they bother you, can be done outside a menu.

In terms of the automatic wrapping, I found different experiences based on the device.  Some of them showed the whole long text when focused and truncated when not; and others showed the whole text only when NOT focused.  I found it on those on larger displays like Fenix etc, where the focused item had bigger text.  It would be nice if it was easier for users to see as much text as possible clearly, focused or not.

Yeah it's definitely not consistent.

Yes, but I wonder how many of those "trivial things" actually get reimplemented by devs who write their own views. Especially when animation was broken in old devices, and trying to use it actually caused the view in question not to update.

When you add the time it takes to implement and test every one of those trivial things (which are not even consistent across Garmin devices), I bet most ppl won't bother to do all of them. For example, if you want to implement a toggle which looks like the native toggle, are you going to run Menu2 in the simulator for every device family to see what the toggle looks like? Probably not.

I saw a pretty nice custom menu implementation with toggles / dynamic labels, etc. It looked nice but it was also jarring because it looked different than the native menu.

I'm just saying that "implement your own view" isn't necessarily as simple as it sounds. It can be if you want, or it can involve a lot of attention to detail, testing across different devices and screens/etc.

For example, something as "simple" as auto-selecting a font to fit within a certain bounding box actually isn't that simple, because devices such as Vivoactive 3/4 have a significant amount of padding above the visible pixels in their fonts. So if you use the API-reported font height, you'll end up picking a font that's too small and users will complain (this actually happened to me). I ended up hardcoding the font height for that kind of device.

Something that "sounds" simple is vertically aligning text with big fonts and small fonts so that their top edges are aligned. For reasons similar to the previous issue (padding around fonts), this isn't possible unless you add in a manually hardcoded fudge factor. You can see in the screenshots for Garmin's own Stopwatch app that the FR235 has this issue -- when they put a large font digit next to a small font digit and try to vertically align them, they don't appear aligned. The code probably thinks they're aligned, because of the padding. But to the end user, it just looks bad.

My point is this stuff can be as simple or as complicated as you want, depending on how much you care about cosmetics, UI and UX.