How to create a menu that is similar to the save/discard menu in native app

I forked a Monkey C project which implements something similar (in look and feel) to Menu2, for older devices which don't have it:

https://github.com/flowstatedev/Dmenu

It still has the behavior you don't want (where the title scrolls out of view), but you can take a shot at modifying the code to have a fixed title as an option.

I totally get it, there are tons of devices and I kinda understand how painful it is to make controls that satisfy all of them. What seems odd to me is that default applications are using something that is not in the 3rd party developer's toolbox. 

I'm a mobile (iOS/Android) developer and I'm new to Garmin development. When I develop an app, I do my best to offer the best user experience and IMO a role model here is default / native applications (not necessary because they offer the best possible UX, but because all users are used to use them).

Do I understand correctly that you're suggesting not to try to replicate them but stick to those few controls that are available? (Even that the look and feel will be noticeably worse?)

Oh I badly want to hear from someone from Garmin team...

Native apps are not written in CIQ.  There are many things a native app can do that a CIQ app can't

I find it very interesting that the Connect IQ developer documentation has style guides ("personalities") for the various devices, but CIQ doesn't provide standardized controls for all the different UI components outlined in the style guides.

For example, a confimation (which gives you the choice between confirming or cancelling an action) looks and behaves very differently in older watches vs newer watches, but CIQ doesn't give you confirmation UI component.

Older Forerunners:

https://developer.garmin.com/connect-iq/user-experience-guidelines/forerunner-2018/

developer.garmin.com/.../

Newer devices (Forerunner 945 LTE / newer Fenixes):

So if you want to have a confimation that works like native confimations in all devices, you'll have to reinvent the wheel.

I don't understand the point of telling us about device personalities and not giving us the tools to easily replicate their UX.

Surely we're not expected to reimplement all of the relevant components to make our app fit the personalities of all the devices we support? Obviously most (or all) devs are not going to do that. (Especially since in some cases you won't be able to get a full handle on the UI/UX unless you own the device.)

I saw one CIQ app which had its own menu implementation (which looks very nice), but with completely different look and feel than any native app on any device. It was a bit jarring, like when you run certain cross-platform apps on Windows or Mac, and they don't look like they belong on either OS.

For one of my apps, I did the following compromise to implement a settings menu:
- For the oldest devices which don't support Menu2, I used DMenu, which approximates native menus for 935 devices. (Menu didn't have the functionality or cosmetics that I needed)

- For all other devices, I just used Menu2

There was talk of Garmin providing barrels with the personality stuff, but it never happened,  You can do this yourself, but I'm not going to change anything until it actually happens

jim_m_58 said:

There was talk of Garmin providing barrels with the personality stuff, but it never happened,

That would be pretty cool, and it would make a lot of sense in the context of Garmin pushing devs to adopt device personalities for a consistent experience.

I'm guessing there's not enough resources to do it right now.

I find this hard to believe tho. They made a language for external devs to work on their devices and they use something else? I'm not buying it.

What I am buying, or what is my theory: We get a subset of the tooling they use. They implemented the optimization and typechecking into CIQ to scratch an internal need and exposed it to the public. Their toybox (who invented this name btw? I kept writing toyboy in the beginning) is bigger and has more capabilities. Probably a little less limitations because they are first class citizens. 

waterkip said:

I find this hard to believe tho. They made a language for external devs to work on their devices and they use something else? I'm not buying it.

I see some anecdotal evidence for this tho. Like a CIQ data field's activity data is only updated once per second, yet the native time field is updated far more quickly than that (initially, when it displays 100ths of seconds).

There's a thread in one of the watch forums where people talked about how native Garmin stuff is written in C.

I don't see why they wouldn't use something else, since the design of CIQ seems to be very much intended to be locked down and restricted in scope, both for stability and marketing reasons. (I always had the impression that Garmin doesn't want 3rd party devs to be able to seamlessly implement features that you would normally have to pay for by buying another watch. For example, dwMap is great for navigation if your watch doesn't support it, but it can't replace the built-in navigation feature.)

waterkip said:

Probably a little less limitations because they are first class citizens. 

From my POV CIQ seemingly has a huge amount of limitations compared to native stuff.

waterkip said:

They implemented the optimization and typechecking into CIQ to scratch an internal need and exposed it to the public.

But type checking is buggy and incomplete right now. e.g. dc.fillPolygon requires an Array of Arrays to be passed in, but you can't specify that kind of nested type in the Monkey Types system without the use of a workaround.

If they ate their own dogfood, I'd expect bugs like that to be fixed before devs could even see them.

There's also the fact that CIQ has been around for such a long time (7.5 years), yet has been very slow to even approach any kind of feature parity with native stuff:

e.g.

- Initially there was no Char type, and it was basically impossible to convert from String to Number (interpreted as Unicode/ASCII) and vice versa.

- CIQ didn't support detecting workout steps until fairly late, so data field apps were unable to react to the press of the Lap key during a workout

Plus Garmin has never claimed that they use Monkey C / CIQ internally. You'd think that would be something they'd brag about, to try to attract devs. You'd also think they'd expose all their UI components, to achieve their stated goal of having a consistent UI experience in CIQ apps, as opposed to just telling devs "here's what we do, pls make your apps consistent. GL".