Avoiding the 'Menu' when holding Menu button.

I gave it another shot. Version 2.3b. Would you please test again?

Sorry to ask, and thanks a lot for your patience.

Ok! with 2.3b I can reset. Now tell us what you changed :)

Interesting change but is probably for the better despite the initial headaches. I pretty much exclusively use my own app for recording activities and my day to day watch face, so having direct access to the menu without leaving my app is a nice thing. I now have access to things like sensor pairing. Probably not many people though that use a single watch app 24/7. But there are numerous activity Apps that will benefit from this.

As for adapting my app to work on the 935:

onKeyRelease() doesn't get called any more for up/menu key holds. I was creating my own long key press events from this. I was comparing against key==KEY_UP.
onMenu() get's called when the app's menu is selected from the system menu that comes up.

Flow is definitely interrupted a bit with this menu coming up but it just means I need to rethink my interface. Much simpler than when I went from the 630 and touch screen.

:):):):)

Great!

Thanks so much for testing. I'm not 100% sure, but this is my explanation.

The status of the timer [saved in the object store] is read in onShow, which was expected to happen only once during my program flow, since there was no menu or other view to be displayed. It seems that onShow is called again when the default menu is dismissed, and it probably happens after the logic implemented in onMenu or onKey. So the variable which represents the time was reset in onMenu [but not saved in the object store], and then the previous value was read again in onShow.

Yes, I think you got bit with what you do in onShow. I'd read the ObjectStore in initialize, because you can run into cases where onShow is called more than once - with notifications, etc..

I gave it another shot. Version 2.3b. Would you please test again?

Sorry to ask, and thanks a lot for your patience.

FWIW, I came here looking for a solution to the stopwatch reset issue on my 5S. I just did an update and it's resetting on mine as well.

Yes, I think you got bit with what you do in onShow. I'd read the ObjectStore in initialize, because you can run into cases where onShow is called more than once - with notifications, etc..

You're right, I'd better move that code to initialize. And maybe I should also set the ObjectStore in onMenu/onKey.

The stopwatch was actually my first app ever :-] and I just followed the standard guideline which comes on top of onShow when you generate a project in Eclipse: that the resources should be read there.

​​​​​In my specific case, there was no problem in running onShow multiple times "accidentally" [e.g. because of a notification], as long as internal variables weren't changed.

I have a couple of widgets which uses KEY_MENU which work fine with 5.30 firmware, albeit now having to press select after the menu key before the widget gets the KEY_MENU event.

I can understand why this is done, but it really messes with my widget flow. I use the up and down buttons to move through my data one item at a time. I use a long press of these i.e. KEY_MENU and KEY_CLOCK to move through my data one page at a time. This no longer really works given the KEY_MENU is not generated unless you long press the menu button and then press the select button.

If the watch had always worked like this I probably would not have designed the widget like this. I'll probably re-code so I can detect a double press and use this to page through the data instead of using a long press.

I also expect I'll get feedback from another widget that the menu key no longer works and I'll have to explain to users they now need to press select afterwards for the menu function to work.

Sorry to be late to the party, but I just discovered this functionality on my F5. I too understand the "consistency" argument but as gasteropod said, this messes with my long press use (onKeyPressed && onKeyReleased). On one screen where I allow the user to scroll up/down through letters for custom text input, I employ long press SDK functionality to allow the user to scroll through the letters without needing to constantly press the button.

1. This seems like a big implementation change, one that would have been nice to have a heads up and one that probably should have been attached to bigger release (ie. 2.4.0) not a point release.

2. Other than removing the use of long press on the menu button on CIQ 2.3.x devices, is there any other workaround?

Cheers,
Douglas

1. This seems like a big implementation change, one that would have been nice to have a heads up and one that probably should have been attached to bigger release (ie. 2.4.0) not a point release.

It was actually a firmware change and not a CIQ VM change. And only with the f5 family and 935. It hasn't made it into other 2.3.x like the vahr,735, etc. But that said, it would have been nice if there was some kind of a heads up (maybe just in the change log for the FW)

It was actually a firmware change and not a CIQ VM change. And only with the f5 family and 935. It hasn't made it into other 2.3.x like the vahr,735, etc. But that said, it would have been nice if there was some kind of a heads up (maybe just in the change log for the FW)

I would strong contend that a firmware change that modifies the implementation or behaviour of a VM is VM change. The change may not have been driven by CIQ change per se but at the end of the day the VM no longer functions the way it used to and that's a VM change. ;)

Regardless of the semantics of what to call this, it's disruptive to developers and users alike for any CIQ apps which employ the use of long keypresses. And, as we both agree, it would have been nice to have been notified beforehand. And it would have been even better to have been consulted.

Cheers,
Douglas