Menu options on Connectiq 1.4

I have a FR630 and i'd like to use the default menu's in an connectiq app i am coding, like the menu's which are in the FR firmware itself. The nice thing in the normal menu is that apart from the menu item text, there are also icons and values. e.g.:
- when you press menu on the normal clock. You will see the word clock, but also an icon of a clock.
- When you hit that menu item, you will see the text "watchface", but also a subline at that menu item stating the current selected menu item.

If i look at the API, i only see something like:

[FONT="Lucida Sans"]function onMenu() {
var menu = new WatchUi.Menu();
var delegate;
menu.setTitle("My Menu");
menu.addItem("Item One", :one);
menu.addItem("Item Two", :two);
delegate = new MyMenuDelegate(); // a WatchUi.MenuInputDelegate
WatchUi.pushView(menu, delegate, WatchUi.SLIDE_IMMEDIATE);
return true;
}[/FONT]



This menu.additem only allows for an item text, not an icon and also not a subvalue.

Does anyone know how I can add this to a custom coded menu?


KR ARnold
(PS i know the menu2 has more functionalities, but this a FR630. So this class is not available)

  • If there's an issue with the 235, the 230 is probably the same (the main difference there is the OHRM), and possibly the 735 as semi rounds seem to have a bunch of common code in the FW. And there's the 920 and original vivoactive, and non-wearables (Edge, etc) would be another thing to consider.

    As far as native menu differences, the original vivoactive may be the most unique.(right/left swipes, with dots to indicate which menu item you are looking at)

    With Menu in the sim, that's always just been a generic look common to all devices in the sim, and often doesn't reflect the native menu on real devices, so don't go by that, but it has the native look on the actual devices. Menu2 in the sim looks like it does on devices though.
  • GThanks jim_m_58. To be clear I looked at YouTube videos to see the difference between Fenix 3, 230 and 935.

    Yes, to expand on that, VA doesn’t support up/down swipes. I have handled this in the menu by adding the “tap above or below center item to scroll” behaviour for all touchscreens. However, VA users may be unfamiliar with this....

    Now I’m starting to see why nobody wanted to use Dynamic Menu >_<. Garmin is getting better, but Garmin made it very hard to emulate native look and feel in the past. Just to handle input properly you have to handle the keys, swipes and taps yourself, because there’s no “onNextMenuItem” and “onPrevMenuItem”, which wouldn’t help for VA anyway, unless you rendered the menu horizontally in that case. Either way you need hardcoded behaviour.

    I will also say I can understand why users don’t like apps which have a non native look and feel. I used a stopwatch that had a very fancy non native menu with nice checkbox controls. But I hated it because it looked different.

    So I wonder if 230 users hate dynamic menu because it’s black on white instead of white on black.
  • Another open issue with Dynamic Menu is that all 3 items are the same height. In the real menus, the middle item is about 40% of the display height.
  • Since I started publishing apps with Menu back in 2015, I can't recall a single case where it didn't perform correctly on a real device. Yes, it's generic in the sim so doesn't look the same, but I haven't had an issue with that.

    If Dynamic Menu is named that because you can build menus on the fly, you can do that with Menu too. In one simple case, I change the text of a menu item between "Hike" and "Walk" for example, exclude or add items as the current conditions warrants, etc (you can only switch between hike and walk before recording starts). And all without having to debug the menu handler itself.

    As far as input, the va3 is a bit different than others (the one button thing..), but as long as you stick with the common things that work on all devices (avoid trying to detect long press of buttons with onKeyPressed/Released for example), it's really not hard to handle all kinds of devices without having one to test on. Having onMenuNext/onMenuPrevious would only really make sense if you were doing your own menu - Doesn't onNextPage/onPreviousPage work in the delegate for your case?
  • jim_m_58 Thanks for the feedback. I genuinely appreciate the effort. I will have to respectfully disagree with you on most points. Hopefully I haven't missed something anywhere.

    Dynamic Menu is different because you can add/delete/edit items on the fly AFTER the menu has been created. And you can also override the draw handler to draw whatever you want. And you can set sublabels, just like the native menu.

    Sure with Menu you can build menus "on the fly" at init time, but you can't add, delete or change items once the menu has been created. As long as you're in that view or a child view, that menu is not changing (except if you use a hack as described below.) You can't even change the focused item. And you can't override the draw handler afaik so you can't add a sub label, draw checkboxes or draw icons. You also can't change the text of an existing item. Please correct me if I'm wrong. That's not really "on the fly", unless you can change the Menu after it's been created. Sure, there's a workaround I used in one app to pop the menu view, automatically push it back and recreate the Menu with new contents, but that's a hack. In fact I used that workaround for Menu2 because addItem()/deleteItem() in Menu2 is reported to be broken.

    Basically you can't use Menu to make a settings menu (like native), with sublabels that show values, and submenus to change values.

    EDIT: It's also not clear to me how you could make ANY kind of settings menu with Menu, since you can't:
    - Have dynamic labels (or sublabels)
    - Set the focus/selection to a different item when initially displaying menu

    The only way I can see it working is with a hack like mentioned above, to recreate the entire menu once a settings in a sub menu is changed. But then you would lose the currently selected item, so it would look weird. Plus that hack looks weird in any case, unless you disable animations.

    onNextPage() and onPreviousPage() don't work for all devices, if you build your own menu. The Dynamic Menu author thought so but it doesn't.

    Here's why:
    - All old touchscreen devices (pre-VA3) trigger onNextPage() and onPreviousPage() on LEFT/RIGHT swipes, because that's how you scroll data field pages. This is problematic because the menu is vertical. Swiping left and right to scroll a vertical menu does not make sense.
    - All old touchscreen devices except VA support tapping above or below the center item to scroll the native menu. e.g. FR630. You can even see this in the simulator with Menu. If you are designing a vertical menu with VA, this is your only real option for scrolling, since UP/DOWN swipes are not supported
    - On devices with physical buttons, when you scroll past the top or bottom, the native menu wraps. On touchscreens, the native menu does not wrap (as this doesn't make sense for touch gestures).

    So I have modified Dynamic Menu so:
    - OnNextPage() and OnPreviousPage() are not handled
    - SWIPE and TAP trigger my own "OnNextItem_touch()" and "OnPreviousItem_touch()" which scrolls without wrapping
    - KEY_UP and KEY_DOWN trigger my own "OnNextItem_key()" and "OnPreviousItem_key()" which scrolls with wrapping

    Everyone keeps telling me you can write generic code, but I'm sorry, you just can't. Not if you want a better experience that more closely matches native behaviour.
  • As far as input, the va3 is a bit different than others (the one button thing..), but as long as you stick with the common things that work on all devices (avoid trying to detect long press of buttons with onKeyPressed/Released for example), it's really not hard to handle all kinds of devices without having one to test on.


    Agreed, except for the one thing where KEY is not supported in widgets for VA3.

    However, you do need to write special code if you want app behaviour that closely matches native apps.

    For example, in native activities, almost every watch takes laps when you press the LAP key or BACK key. Only the VA3 takes laps when you double-tap the screen, which does not correspond to the BACK key or BACK behaviour. Besides, you still need special handling to handle either LAP or BACK. If a watch has both LAP and BACK buttons (e.g. 630), then you don't want BACK to do the same thing as LAP!

    So to match native behaviour, you may not need the real device, but you need to know the real behaviour.

    Sorry, but I don't think Garmin makes this easy. That's why there's a stopwatch app in the store which asks you to press DOWN to take a lap....
  • BTW, I would appreciate it if you could send me the full stack trace (if available) from my app crash, so I can fix the problem, as I cannot reproduce it in the sim or on my 935. Thanks..


    Sorry for the late response. i rechecked on my device. The CIQ log file does not contain any additional info.
  • akamming no worries. If you happen to use the app and ever see it crash, please let me know.