onActionMenu being called when swiping left ANYWHERE on the screen

It works like this on a real device too.

I guess the action menu simply replaces the standard swipe left which becomes unavailable if you enable the action menu indicator.

That's not great news. I'll have to think if I can release the app on these devices without "physical" menu button.

Yes, in at least one app, I had to decide if I wanted to add the action menu for my menu, and lose swipe left which I use for a transition. Or work out another way to bring up the menu.

I was already using onHold as an additional way to bring up a menu on some apps, so they still work when there is no menu button. But users are less familiar with using hold for this so not the best experience.

This is interesting, because the native UI on current Forerunners allows you to swipe left to open an action menu (which is also opened via the START button), but it only works if you swipe from the right edge. I guess they are trying to make things "easier" (same reasoning behind getting rid of the menu button shortcut on the newer touch-first devices, I guess)

What does swipe left normally do in your app?

- if it's some kind of continuous action (e.g. pan/zoom), is it possible to use drag instead? Or maybe your action menu can put you in a mode where a menu is not available via left swipe but your swipe action is available otherwise? (Kind of pan/zoom mode on the map page for forerunners.)

- if it's some kind of single action, can you put that action in your action menu?

- can you have a dedicated app page which has exclusive access to the menu? (You would probably need to find something else to put on the page so it doesn't look awkward). The analogy with the real Vivoactive 6 is that apparently you open watch settings via a  menu item in the activities list now. (Based on DCR's review - I haven't seen it myself)

- can you have a ubiquitous on-screen menu button instead? (Like the 3-lines / hamburger menu on the map page)

Swiping left drills down a level of detail. There is a flow going deeper and deeper. So, I could put that as a menu option on the top screen where the menu is available, but it would ruin the flow. Swipe left to go deeper, right to go back up. 

I could use a hamburger too I guess. That is definitely an option, but I think people have got used to using touch & hold. I do like that idea though. 

Maybe the on screen menu button will work for my case.

The best way (and most complicated way) I found to have complete control of the gestures is to use 'onDrag' and build your own onSwipe within. Make sure the original onSwipe... gestures do nothing but return true. If you need to handle buttons too, since they'll somehow be called after a 'drag' event on a real device (but not in the simulator), I've put a 250 ms timer at the end of onDrag function that ignores the next onNext/PreviousPage event. You'll need to handle the onKey for specific keys too if you want to deal with some GPS devices! If you use a ViewLoop to move pages up/down but also want complete controls of the buttons and gestures for some things, it gets even more complicated, as I found out yesterday. 

This is the delegate code I came up with to handle all these scenarios. Not the cleanest code but it does what it needs to do, for now. Not sure if an updated CIQ will break it though. So far it hasn't in my Calculator app, which uses an older version of that code.

github.com/.../BatteryMonitorDelegate.mc

I'd worry more about new devices with different behaviour (different number of buttons, or gestures)

Yes, that's something else that can happen but so far, it hasn't

It kind of happened, 'cause with vivoactive6 they added onActionMenu and some apps that previously worked pretty well on many devices (including new devices added before va6) without changing the logic are now... not sure what's the right word to use. Broken? Less user friendly? Confusing? Probably it also depends on what exactly the logic was in the app.