PlayBook: SWIPE_START Simplified


Posted:   |  More posts about PlayBook AIR

Warning: in the 1.0 release, SWIPE_START may no longer work exactly as described here. If you use it in your app, you may need to switch to SWIPE_DOWN until the 1.0 software has been released and can be analyzed fully.

In my previous post I wrote at length about the two ways to handle top-swipe events with the Adobe AIR SDK in the BlackBerry PlayBook.

As always happens after I spend a long time polishing some code and writing documentation for it, shortly afterwards I realized it could be simplifier. In this case, there's a way to use swipeStart without dealing with mouseMove at all.

From the last post, here's the sequence of events that you'll get if you subscribe to QNXApplicationEvent.SWIPE_START and perform a top-swipe:

  1. QNXApplicationEvent.SWIPE_START
  2. MouseEvent.MOVE (once only)
  3. MouseEvent.DOWN (at same coords)
  4. MouseEvent.MOVE (many)
  5. MouseEvent.UP
  6. MouseEvent.CLICK

Now as I pointed out in the previous post, it's possible to contrive to generate the same sequence without really doing a swipe, but just tapping and releasing in the top bezel (i.e. don't move your mouse/finger), then down in the screen area doing a proper swipe.

The simplification to my ca.microcode.menu.TopSwipeMenu code would be to ignore MouseEvent.MOVE entirely, and just use the MouseEvent.DOWN which follows the swipeStart as the signal that the top-swipe gesture has really begun provided the mouse coordinates lie in the bezel area. That is, check for "stage.mouseY < 0" and cancel the swipe if that's not true.

There's a minor defect with this approach, since it's possible to tap just off the top of the screen (Y value just below 0) to generate the swipeStart, yet not have the mouseDown event be issued until the position is already at 0 or higher. You can choose how to deal with this, but the simple approach would be to ignore it. That would mean users have to start the top-swipe just the slightest bit above the top edge of the screen (depending on how fast they swipe), but it seems unlikely anyone would ever notice the limitation so this is a mere technicality.

I won't post sample code for this (yet) as I haven't tried it out myself, but anyone who can deal with the state machine code should have no trouble modifying it to work this way. I'd also like to just wait until I have real hardware on which to test, since:

  1. the behaviour may be different by release time, and
  2. the response to touches may differ slightly from mouse clicks in the simulator.
Comments powered by Disqus