Cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Receiving onclick when display is activated

ANSWERED

It seems to me that watch apps receive a physical button onkeypress event when a button press is used to turn the display on. I'm not sure that this is always desirable because it's difficult for the app to determine that the button was used to turn the display on (since display.on is always true), so the app will still process the event to make whatever state change it would make had the display been on previously. This probably isn't what the user intended; they just wanted to turn the display on rather than changing the app's state.

 

I'm wondering whether onkeypress events should be swallowed by the OS (ie, not passed through to the app) if they're used to turn the display on from an auto-off state.

 

Alternatively, could a parameter be set in the onkeypress KeyboardEvent argument to indicate that the event has been used to turn the display on? (This latter could be problematic because it would probably deviate from JS standards.) Perhaps a property already indicates this; if so, which one?

 

I tried to work around this problem by disabling onkeypress handling when the display is off, but unfortunately display.onchange occurs before onkeypress so the handler gets re-enabled before I'd rather. This leads to a third option: have the OS send the onkeypress BEFORE display.onchange. This would allow the onkeypress handler to work out whether the keypress is being used to turn on the display and give it the option of foregoing its normal in-app behaviour. As a bonus, the handler could optionally prevent further propagation of the event, thus preventing the display from turning on (although this might offend Fitbit's standards).

 

So far, the only workaround I've found is to record the time of the most recent display.onchange and, when a subsequent onkeypress occurs, calculate the difference. If it's with 50 ms, I assume that the keypress has been used to turn the display on. This seems to work, but is embarrassingly ugly.

 

I'd be interested in others' thoughts. A feature request may be in order.

Peter McLennan
Gondwana Software
Best Answer
0 Votes
1 BEST ANSWER

Accepted Solutions

We don't recommend using buttons within clock faces at all, but your "ugly" solution is probably the only way right now.

View best answer in original post

Best Answer
0 Votes
2 REPLIES 2

We don't recommend using buttons within clock faces at all, but your "ugly" solution is probably the only way right now.

Best Answer
0 Votes

Thanks Jon. I should clarify that the program is actually an app and not a clockface, so the issue applies in all cases.

Peter McLennan
Gondwana Software
Best Answer
0 Votes