onMenu not working in app any more

See https://forums.garmin.com/forum/developers/connect-iq/1241457-avoiding-the-menu-when-holding-menu-button

I'm wondering if this may be by design with the new 5.10 FW on the f5 family and 935. I know with my apps, the app name is the first thing in the new menu, and selecting it triggers onMenu in the app. Menus in the sim have always been a generic representation, BTW, and often differ on devices than they are in the sim, so I really wouldn't expect this in the sim..

Thanks Jim, hopefully they will change it to the way it was :)

Bye

This is expected behavior, and I would not expect it to change back. This change was made to allow access to the general device menus while Connect IQ applications are running.

Hi Brian,

that means that all applications using "onMenu" have a changed workflow now and do not work the same way any more. Also it means that "onMenu" is not a convenient way any more to give additional functionality for apps/widgets. On the other hand the global settings are available from various other places, why was it necessary to add it in apps also? Was this a feature request from users?

I personally do not understand that change and think other users will also come to that conclusion when every app, that uses "onMenu", now shows the "undesired" menu.

Bye

Wanted to follow up on this one. The change in behavior came from the product UX team, who were specifically trying to make menu handling in the widget loop more consistent for the user as is their mission. There are a lot of actions like re-order widgets in the system menu that you couldn't access from in a CIQ widget, and they were trying to make consistent behavior with the menu button, which I agree with as a goal. The change was rolled out to widgets and apps, which has a lot of side effects that go beyond the intent and really messed with how apps process input.

In an upcoming F5/s/x/935 update we'll be removing this behavior from apps, but leaving it in for the base page of the widget. Widgets never had access to the up/down buttons, so there are less side effects to having the "intermediate" menu, and users can still send the menu action via the first item. If you push a page in the widget, the intermediate menu will be disabled, allowing for full input.

The other problem is that we didn't message or consult our developers about this change. This change has been vigorously discussed internally, but I should have made sure you, our developers, had notice and chance to comment. Usually with large changes we have blog posts, forum posts, and the beta period, but because this was seen as a change in product behavior versus API behavior we didn't take the usual messaging steps. That was a mistake.

We do value you all, and are always grateful for the content you create.I'm chalking this up as a learning experience of the dangers of making big changes in point releases.

Happy Labor Day developers in the US. Happy Monday to the rest of you.

-AM

Thanks for the info. Once this update comes out to partly revert to the old behaviour my main issue will be resolved. I use the menu action after pushing a page and the "intermediate" menu here was really messing up my widget flow. So, it is good to know this "intermediate" menu will be disabled after pushing a page.

at AlphaMonkeyC

I really appreciate your statement and am also very happy that this change will be removed in a future update. I think it is the right decision as this new button behavior really destroys application flows in a lot of apps, the user will also be very thankful I think.

Bye

It is being removed in apps, but not widgets. In widgets it will stay for the initial page, but not other pages once pushed. The change is not being completely removed though.

I think this is a good compromise as using the menu button in the main widget carousel shouldn't be such a common use case.

Thanks, AlphaMonkeyC. This discussion give us the good feeling that we are heard as devs :-]

But now I'd like to be heard as a user.

1. It's a lot easier for a user to relate the menu that will appear with the screen that's currently being shown. If the current screen is an app or a widget, I'll see the menu of that app or widget. If it's the watch face, then I'll see the system menu.

2. If my objective is to open the system settings, why would I start the widget carousel?
If I start the widget carrousel, I want to interact with the widgets. If my favorite widget makes use of the menu key on its first page, I have to go through an intermediate menu now. Or, if the dev implements the suggested solution - i.e. push a view - then I probably have to click a button first and only then use the widget menu. So​ I always need an extra action to skip a stupid [sorry] menu, which, if I wanted, I would have opened before I started the widget carousel.

Let me illustrate it with three examples of simple widgets I authored [two of them among the most popular ConnectIQ apps...]
- stopwatch: action button = start/stop, menu button = reset
- calendar, action button = next month, menu button = options like previous month, change colors, first day of week, etc.
- notes widget: action button = next note, menu button = options like delete note, change colors, etc.

Do we really want an intermediate menu in these cases?