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
  • 4 months ago

    Not to beat a dead horse or state the obvious, but in the absence of any changes from Garmin, I think the only solution an app dev would have is to make support for any long-press shortcuts optional, and disabled by default. (That's why I do for my app that supports certain long-press shortcuts.)

    If long-press support is always there or optional but enabled by default, then there will always be the possibility that a conflict with a system-wide shortcut will cause problems with your app. e.g.

    "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."

    Otoh, if the user had to opt-in to enabling the hold Down shortcut (for example) in the app, the app could at least warn them of the possibility of a conflict (and/or such a conflict could be called out on the store page.)

    Even if Garmin eventually makes the changes that are being asked for:

    - older devices probably wouldn't get the changes (not sure what the oldest devices supported by the app are, tho)

    - there's no guarantee all users would update their firmware (ofc this could be taken care of by the fact that the SDK device definitions are constantly being updated in such a way that forces users to update their firmware/CIQ before installing newly built versions of apps)

    - existing users need to be taken care of the meantime

    Yeah, I know none of this is ideal.

Comment
  • 4 months ago

    Not to beat a dead horse or state the obvious, but in the absence of any changes from Garmin, I think the only solution an app dev would have is to make support for any long-press shortcuts optional, and disabled by default. (That's why I do for my app that supports certain long-press shortcuts.)

    If long-press support is always there or optional but enabled by default, then there will always be the possibility that a conflict with a system-wide shortcut will cause problems with your app. e.g.

    "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."

    Otoh, if the user had to opt-in to enabling the hold Down shortcut (for example) in the app, the app could at least warn them of the possibility of a conflict (and/or such a conflict could be called out on the store page.)

    Even if Garmin eventually makes the changes that are being asked for:

    - older devices probably wouldn't get the changes (not sure what the oldest devices supported by the app are, tho)

    - there's no guarantee all users would update their firmware (ofc this could be taken care of by the fact that the SDK device definitions are constantly being updated in such a way that forces users to update their firmware/CIQ before installing newly built versions of apps)

    - existing users need to be taken care of the meantime

    Yeah, I know none of this is ideal.

Children
No Data