Swipe left working in simulator but not on device

Hi,

In my BehaviorDelegate, I "map" the swipe left input to the onSelect behavior:

class MyDelegateDelegate extends BehaviorDelegate {
    public function onSwipe( swipeEvent ) {
        if( swipeEvent.getDirection() == SWIPE_LEFT ) {
            return onSelect();
        }
        return false;
    }

    public function onSelect() as Boolean {
        // Action
    }
}

This works in the simulator for my Epix Pro Gen2, but not on the real device.

Other swipe gestures that are automatically tied to behaviors work on the device, like swipe up/down to trigger onNextPage()/onPreviousPage() or swipe right for onBack().

When I swipe left with the clicked mouse in the simulator, the onSelect() is triggered correctly. On the device instead onNextPage() or onPreviousPage() is triggered.

What could I be doing wrong?

Top Replies

All Replies

  • Are you returning true from onSelect()?

    On the device instead onNextPage() or onPreviousPage() is triggered.

    This part kinda sounds like a bug. Obviously in the native UI, you wouldn't expect swipe left to scroll up or down, or to do anything at all (since Garmin doesn't support swipe left to go "forward").

    If you don't override onSwipe() at all, are onNextPage() or onPreviousPage() still triggered by a left swipe?

    Is it possible that your touchscreen is misinterpreting your left swipes? (What *does* happen in the native UI if you swipe left?)

  • Are you returning true from onSelect()?

    Yes. Also the standard onSelect() triggers (tap on touch screen or enter button) work fine.

    If you don't override onSwipe() at all, are onNextPage() or onPreviousPage() still triggered by a left swipe?

    Yes, just tried it without, it is still the same.

    Is it possible that your touchscreen is misinterpreting your left swipes? (What *does* happen in the native UI if you swipe left?)

    On the Epix 2, native apps also use swipe left, often for the same action as when pressing the 2 o'clock enter/start key.

    So I can confirm that I am able to do a proper swipe left, and that the watch is able to detect it in general. Only in my CIQ app it does not behave as expected.

    To me it looks like the same problem I had last week. Read these 2 threads, there's also a gist with some code that might help you do similar in your use case:

    Puh, these are very long threads. What exactly there describes a problem like mine?

  • Just did another test, and it is onNextPage() that is triggered by swipe left on the device.

    If on the device swipe left would be associated with the onNextPage() behavior, and I have onSwipe() as well, which of the two takes precedence?

    Edit: that was a stupid question because easy to test. At least in the simulator the behaviors take precedence, i.e. are called first.

    So, it may be a discrepancy between simulator and real device. If the swipe left is associated with onNextPage() on the device, my onSwipe() will never be called.

  • The simulators are pretty consistent, I checked simulator.json for Fenix 7, Fenix 8 and Venu3 models as well, in none of them swipe left is associated with a behavior.

  • So, it may be a discrepancy between simulator and real device. If the swipe left is associated with onNextPage() on the device, my onSwipe() will never be called.

    I have confirmed that when I disable my onNextPage(), then on the real device my onSwipe() is called and works as expected.

    So there is a discrepancy between simulator and real device. On the simulator, swipe left is not associated with any behavior, on the device it is with onNextPage().

  • Yeah so it seems like this is all down to a quirk of epix gen 2 where swipe left is used differently in the native UI compared to many other watches.

    Edit: that was a stupid question because easy to test. At least in the simulator the behaviors take precedence, i.e. are called first.

    Yeah so this is it. 

    I think others have found the same in different contexts.

    It really sucks that the behaviours take precedence since it means that you can't easily disambiguate between the onNextPage() that you do want (like via the DOWN button and swipe up), vs the onNextPage() you *don't* want (swipe left). It would be better if onSwipe() were called first, then on*Page(), instead of the other way around. 

    It seems that you could do a hack which others have suggested:

    - return false in the various behavior callbacks, but remember the behavior

    - in onSwipe/onKey/onTap, determine the true cause of the behaviour and act accordingly.

    Ofc this kind of strategy would assume that the behaviors are always called first. If this changed in a new device or was different on an old device, it would cause problems.

    I guess you could always try to implement guard code to handle this eventuality. e.g.

    - define variable "lastBehaviourOrInput" which is initially null

    - in behavior callbacks, if lastBehaviourOrInput is null, set lastBehaviourOrInput to current behavior and return false.

    If lastBehaviourOrInput is non-nuil, then lastBehaviourOrInput has the last input (key/tap/swipe), and act accordingly. Set lastBehaviourOrInput to null

    - in key/tap/swipe callbacks, if lastBehaviourOrInput is null, set lastBehaviourOrInput to current input and return false.

    If lastBehaviourOrInput it's non-nuil, then lastBehaviourOrInput has the last behavior, and act accordingly. Set lastBehaviourOrInput to null

  • It really sucks that the behaviours take precedence

    I suppose it's entirely by design, as Garmin wants onNextPage (for example) to be handled the same regardless of how the user triggered it. (That would be the simplest and most consistent behaviour from the part of the end user, who would generally expect CIQ apps to behave similarly to native apps from a UX pov.)

    Calling the behaviour callbacks *after* the keys and swipes would provide the greatest flexibility for the app dev tho. I guess that can already be achieved by just ignoring the behaviors, but then you don't get to easily implement a "best of both worlds" / hybrid solution where you adopt most, but not all, of the native behaviours.

  • (That would be the simplest and most consistent behaviour from the part of the end user, who would generally expect CIQ apps to behave similarly to native apps from a UX pov.)

    Actually on my Epix the behavior of native apps and CIQ is not the same. In the native apps that I have tested, swipe left acts the same as the select button, bringing in a detailed view from the right side. Only swipe up and swipe down switch between pages on the same level.

    And that is actually what I wanted for my own app. But in CIQ it seems swipe left is associated with the onNextPage() behavior on the device and only on the device, not in the simulator.

    So at least for the discrepancy between device and simulator, I'll open a bug report.

  • Yeah good point, my bad.

    I updated a previous comment with a hack that could be used to ignore a behavior (like onNextPage), but remember what the behavior was so you can act on it when you receive the corresponding key/tap/swipe. 

    https://forums.garmin.com/developer/connect-iq/f/discussion/407523/swipe-left-working-in-simulator-but-not-on-device/1916210#1916210