Acknowledged
4 months ago
CIQQA-3113

bug: swipe right on the left side of the screen triggers onKey(KEY_ESC)

I noticed this with my app in simulator (fr955, SDK 8.1.1), and then I checked it with the Input sample and it also reproduces it, so it's clearly a bug both in the simulator and even on real devices (tested on real fr965). A similar bug was already reported 4 years ago: https://forums.garmin.com/developer/connect-iq/i/bug-reports/vivoactive-4s-swipe-identified-as-a-key-pressed

To reproduce:

- run the Input sample from the SDK on fr955 in the simulator.

- swipe right in a way that you touch in the middle or the right side of the screen => correctly, only swipe event is triggered

- swipe right touching in the left side of the screen => onKey(KEY_ESC) is triggered (It's not clear when this happens, in the Input sample it looks like sometimes this only happens every 2nd time you swipe on the left side of the screen)

flocsy🤠
  • 2 months ago

    Is there any way to get an update on this? This function is triggered by water (where my app operates) and negatively affects operation. 

  • 3 months ago

    Having the same issue on Fenix and Epix. Cannot replicate 'onback' behaviour in sim however, just in real. 

  • 3 months ago

    Not to state the obvious, but this kind of thing also makes it harder to write an app which purposely ignores all touches (whether or not touch is enabled in device settings).

  • 4 months ago

    As for why this bug exists, I can only guess that:

    - the "right swipe from left triggers KEY_ESC" aspect of the bug is meant to handle buggy / old apps (for non-touchscreen devices) which only used KEY_ESC to go back and overrode the behaviour of onBack() so it doesn't go back, which breaks touch interaction

    - the "all right swipes trigger onBack()" aspect of the bug is make it even easier for users to go back by swiping right in a CIQ app? But the same change wasn't made to Menu2 or the native UI

    All i can say is that if Garmin wants us to write apps which handle input like the native UI, they're not making it easy for us.

    See also:

    - trying to handle back/lap input in CIQ device apps

    -- most devices have a single back/lap key

    -- some devices (fr630) have separate back/lap keys

    -- some touchscreen devices use swipe right to go back, but never to take a lap

    -- vivoactive3 uses double tap to take laps

    Given all of the above, it would've been great to have a distinct lap input event [*] in CIQ, because:

    - triggering a lap on KEY_ESC excludes vivoactive3 and fr630

    - triggering a lap on onBack() still excludes vivoactive3 and fr630, but also has the side effect of inappropriately taking a lap on a right swipe, for most touchscreen device

    - there's no built in double tap event, so devs will have to roll their own to handle vivoactive3

    [*] I understand why there isn't a lap event in BehaviorDelegate - it's probably because the design doesn't really allow for 2 events (like Lap and Back) to be triggered by a single input, as the app wouldn't be able to distinguish that from two separate inputs. One solution for this could've been to allow for hybrid events (so that two behaviours could be tied to a single input).

    This brings up another negative consequence to this bug. Suppose a dev writes a device app which records an activity and only supports modern devices (not vivoactive3 and not fr630), in which case they can supposedly be ok with triggering a lap only on KEY_ESC. This bug actually means that their app will incorrectly trigger a lap on right swipe, and there isn't an easy way to avoid this.

  • 4 months ago

    This kind of thing is part of why I'm very reluctant to get back into real CIQ development (as opposed to rebuilding a simple data field to support new devices).