Holding the Down Button to Show the Native Clock

In a watch app, there appears to be intended functionality that Holding the Down button for a couple of seconds will bring up the native clock screen.

In running my app on a Fenix3, I noticed that this works when I'm in a menu, but not when I'm not in a menu (2 different delegates)

The regular input delegate has an OnKey function that always returns true. If I change it so that it returns false when KEY_CLOCK is detected in OnKey function, it will bring up the clock from this delegate as well. This seems reasonable.

In the menudelegate, I'm also always returning true from the OnMenuItem function. I don't see any way to prevent holding the down button from bringing up the native clock screen.

If I bring up the native clock screen while the Activity is not recording, it seems to work fine. UP and Down scroll through the various native screens. Start and Back return to the App.

If I bring up the native clock screen while the Activity is recording, I get unexpected behavior. The back button seems to try to create a lap in a native activity and when I exit that, I find that my app has been exited as well. To reproduce this, start the app, start the activity, go into a menu, hold the down button, press back.

So this brings up a few questions.

1) Is bringing up the native clock screen intended behavior in any case or is this a bug like bringing up the native lap screen was?
2) If not a bug, is there a way to explicitly bring up the native clock screen besides returning false from KEY_CLOCK?
3) Is there a way to prevent the native clock screen from being brought up when inside a menu delegate?
4) Do all of the watches act the same way?

travis.vitek over 9 years ago

2) If not a bug, is there a way to explicitly bring up the native clock screen besides returning false from KEY_CLOCK?

It seems false should be returned if the delegate does not do something in response to the key event.

MoxyRoger over 9 years ago

It seems false should be returned if the delegate does not do something in response to the key event.

My thinking is the opposite on this. There are 23 possible key constants listed in the WatchUi for 1.1.4. My app input delegate only does something with 6 of them. I'd prefer that my app does nothing with the other 17 because I don't know what they will all do and I'd prefer to not have to try to test them on all of the various watch types. I don't even know what combinations of button holds is required on each device to actually cause many of the key responses or which devices are capable of which key responses.

Always returning true unless I specifically desire some native action (such as bringing up the native clock screen) seems like the safer approach. Am I missing something in my thinking on this?

Former Member over 9 years ago

Thanks for the report Roger. The app is allowed to block the clock key in order to allow supporting held key behavior on the down key, so the behavior you are seeing in a regular view is correct. The behavior in the menu may or may not be correct. I think it is reasonable to allow the app to prevent the clock key functionality, but since held key behavior is not available from the native menu, I don't know what our expectation is there.

The native lap behavior occurring from the clock screen is definitely a bug. I will create a ticket to investigate.

It seems false should be returned if the delegate does not do something in response to the key event.

Generally yes, but in this case, you may want to block the native behavior of the clock key even if you aren't explicitly using it. If you want to scroll through items quickly by holding the down key, you must catch and block the clock key to prevent the native clock screen from appearing.

Former Member over 9 years ago

The Fenix 3 team has been able to identify the cause of this issue, and it should be resolved in a future device update.