Ticket Created
over 5 years ago

WERETECH-9013

Vivoactive 4S swipe identified as a key pressed

At least on the Vivoactive 4S, since I wasn't able to test this out on other devices, there seems to be an undocumented / unwanted behavior that is not directly visible when testing in the emulator.

While developing Monky (https://github.com/vladmunteanu/monky), I had to adjust one of the minigames so that it checks for a key pressed event instead of a swipe right, because when the app ran on the actual watch, it would trigger the onKey event, instead of onSwipe. (https://github.com/vladmunteanu/monky/blob/37fae93329cd7875d9d3c05c9a64c6cffd4cee07/source/SwipeGame/SwipeGameDelegate.mc#L17)

If intended, the documentation should at least be changed to reflect this when implementing an InputDelegate. 

vsm
Parents
  • over 5 years ago

    IMO this is an integration bug. A device should not generate a key press events for a swipe inputs.

    On the vivoactive3/4 devices discussed above, I'd expect a swipe right to generate

    1. If using a BehaviorDelegate, a call to BehaviorDelegate::onBack(). If that returns false..
    2. A call to InputDelegate::onSwipe(). If that returns false
    3. Whatever the default behavior for the device is for a back event (probably dismissing current page)

    I'm guessing this is something that has been around since the vivoactive and vivoactive_hr days. We already have an issue filed to work out some behavior issues with taps and swipes, so I'm including a reference to this post there.

Comment
  • over 5 years ago

    IMO this is an integration bug. A device should not generate a key press events for a swipe inputs.

    On the vivoactive3/4 devices discussed above, I'd expect a swipe right to generate

    1. If using a BehaviorDelegate, a call to BehaviorDelegate::onBack(). If that returns false..
    2. A call to InputDelegate::onSwipe(). If that returns false
    3. Whatever the default behavior for the device is for a back event (probably dismissing current page)

    I'm guessing this is something that has been around since the vivoactive and vivoactive_hr days. We already have an issue filed to work out some behavior issues with taps and swipes, so I'm including a reference to this post there.

Children
  • over 5 years ago in reply to Travis.ConnectIQ

    With the va and vahr, this wasn't really an issue, as swipes were just swipes.  With the two buttons, and between short and only presses, you got menu,back and start.

    The va3 is where it got odd with only the one button (start) and the only way to do a back was the right swipe, and for the top view for a widget, the only way to exit a widget.  I have a felling the key press might be there so the same delegates can be used on other devices. (it looks just like it would on a device with a physical back button).  I've not checked, but likely the same for menu (a long screen press).

    With the va4, the lower left button (short press) is "back", but so is a right swipe.  

    Input mapping on the va3/va4 (and variations) has always been odd, and I think some of that is touch, but some of it is also so that the delegate works the same on other devices, and similar for widgets and device apps.  I might be wrong...

  • over 5 years ago in reply to Travis.ConnectIQ

    I agree with Travis, and what he described would definitely be intuitive.