Acknowledged
5 months ago

Feature request: Suppress user shortcuts

I'd like to let my user cycle through input/menus quickly in my app by holding the up or down keys. I built an implementation using onKeyPressed() and onKeyReleased() that can detect the state of the key and works well on a simulator.

Unfortunately on my Fenix 6, holding the down key causes the music player to open on top of my app. Worse still, when it launches it prevents the onKeyReleased() callback from reaching my app/view, so when I return to my app it thinks the key is still being held and is caught cycling endlessly until my code receives more user input and detects the issue.

This known limitation has been raised before: https://forums.garmin.com/developer/connect-iq/f/discussion/351737/disable-shortcut#pifragment-1298=1

Long presses are a highly useful feature in general. By enabling two different behaviors for each key, it effectively doubles the size of the user input space and enables much richer functionality. So I'd really like to see support for long presses.

Here is my feature request:

1) I would like to see the API changed so that the developer can decide to suppress a user shortcut, which may not be appropriate/intended behavior in the context of some apps. Maybe this can happen whenever true is returned from onKeyPressed()?

Additionally, the behavior I described where my app loses track of user input is not ideal.  I would like to see either or both of the following features added to enable workarounds:

2) Provide a mechanism where I can access the current state of the buttons, so my view/delegate can check in onShow() whether a key is still held and prevent an erroneous long press behavior.

3) Provide a mechanism to check whether there is a shortcut registered on a button. This way if there is, an app can smartly disable long press behavior in the context, but in other contexts/for other users it can still provide the richer functionality.

bostonwalker
Parents
  • 5 months ago

    > However as a user I could live with the following: if a long keypress shortcut is not defined in the system, then that would work in the app. However as an app developer probably this would not be very useful...

    It already works this way tho.

    As I mentioned in the linked discussion, I have an app that optionally supports long-press of certain keys, with the understanding that it won’t work if those shortcuts are already assigned at the system level.

    It's not as useful as it could be, but it gives the user an alternative that's available as long as they don't have that shortcut assigned to something else.

    Consider the opposite behavior: hypothetically, Garmin allows 3rd party apps to override system shortcuts such as hold DOWN (defaults to music player on some devices) or hold BACK (defaults to return to watchface or open app switcher?) on some devices. I can imagine users complaining if their beloved shortcuts suddenly stop working when they're using a 3rd party app. As a matter of fact, I've seen plenty of discussions in Fenix boards where Fenix users who are used to holding BACK to return to the watchface get upset (or confused) bc a newer Fenix assigns the hot key to a different function (or no function). The point is that even in the case where a user can get back the previous behavior by changing a setting, it's still upsetting that the behavior changed in the first place (usually bc they may be unaware that they can change the behavior back). I think it would be even more upsetting if they were told that their favorite functionality just won't work while they're using a 3rd party app.

    I think all of this goes back to the fact that Garmin watches are not 3rd-party app-centric. Everything revolves around the built-in functionality and user experience, which Garmin controls very tightly. Third-party apps are hamstrung compared to native software in terms what can be accomplished in terms of the UI and in accessing native functionality. This can especially be seen in CIQ data fields, but also to a certain extent, also in CIQ device apps.

Comment
  • 5 months ago

    > However as a user I could live with the following: if a long keypress shortcut is not defined in the system, then that would work in the app. However as an app developer probably this would not be very useful...

    It already works this way tho.

    As I mentioned in the linked discussion, I have an app that optionally supports long-press of certain keys, with the understanding that it won’t work if those shortcuts are already assigned at the system level.

    It's not as useful as it could be, but it gives the user an alternative that's available as long as they don't have that shortcut assigned to something else.

    Consider the opposite behavior: hypothetically, Garmin allows 3rd party apps to override system shortcuts such as hold DOWN (defaults to music player on some devices) or hold BACK (defaults to return to watchface or open app switcher?) on some devices. I can imagine users complaining if their beloved shortcuts suddenly stop working when they're using a 3rd party app. As a matter of fact, I've seen plenty of discussions in Fenix boards where Fenix users who are used to holding BACK to return to the watchface get upset (or confused) bc a newer Fenix assigns the hot key to a different function (or no function). The point is that even in the case where a user can get back the previous behavior by changing a setting, it's still upsetting that the behavior changed in the first place (usually bc they may be unaware that they can change the behavior back). I think it would be even more upsetting if they were told that their favorite functionality just won't work while they're using a 3rd party app.

    I think all of this goes back to the fact that Garmin watches are not 3rd-party app-centric. Everything revolves around the built-in functionality and user experience, which Garmin controls very tightly. Third-party apps are hamstrung compared to native software in terms what can be accomplished in terms of the UI and in accessing native functionality. This can especially be seen in CIQ data fields, but also to a certain extent, also in CIQ device apps.

Children