You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Devices: Motorola Photon, Galaxy SIII, Le Pan Tablet, Galaxy Player
Problem: KEYCODE_HOME and KEYCODE_POWER key events don't emit, while _MENU, _BACK, _SEARCH, VOLUME, and others work perfectly.
Guess: the app probably pauses before the key event emits.
Alternative: Because HOME and POWER are generally the only way to pause the app on a default installation (because the app runs in stay awake mode by default), from a development perspective, the only need is to distinguish between 'how' the device was slept.
In other words, if it's not practical to trap a key event that triggers a shutdown, this alternative would probably satisfy most devs (which also has the benefit of allowing for other possible non-keypress pause sources):
def on_pause(self, reason_for_pause):
if reason_for_pause == Android.KEYCODE_HOME_REASON:
self.perform_cleanup_A()
if reason_for_pause == Android.KEYCODE_POWER_REASON:
self.perform_cleanup_B()
if reason_for_pause == Android.ANDROID_WANTS_TO_SLEEP_REASON:
self.perform_cleanup_B()
return True
So this is a very old request for a feature. But why does it matter? I honestly can not think of any reason that I would do on_pause differently for any given "KEYCODE" or because of a specific pause source. Can you explain why different sources matter to your app?
Closing as this issue relates to the old toolchain which is no longer supported. Please open a new issue if you experience this issue with the current master branch.
Devices: Motorola Photon, Galaxy SIII, Le Pan Tablet, Galaxy Player
Problem: KEYCODE_HOME and KEYCODE_POWER key events don't emit, while _MENU, _BACK, _SEARCH, VOLUME, and others work perfectly.
Guess: the app probably pauses before the key event emits.
Alternative: Because HOME and POWER are generally the only way to pause the app on a default installation (because the app runs in stay awake mode by default), from a development perspective, the only need is to distinguish between 'how' the device was slept.
In other words, if it's not practical to trap a key event that triggers a shutdown, this alternative would probably satisfy most devs (which also has the benefit of allowing for other possible non-keypress pause sources):
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: