Adobe AIR Development

[T55555]

Hi,

I am using latest simulator (on Windows), and found that the swipe down event is generated when click on the top bezel.

I mean, just "click" ==> move mouse to top bezel, not too close on left / right edge, and just "click", not swipe, not drag-n-drop.

I hope this only on simulator, but not on real device.

Otherwise, it may be very strange .... simply hold and release ( without "swipe" ) would generate start swipe event to application !?

( Currently, my app listen swipe and start show Navigator bar; if simply click will generate such event too, I may add mouse event to fine tune.  I know System Menu is smooth with 23 pixels "role-back".  Not sure I really want to do the same behavior ... )

[JRab]

hey,

i found the same behaviour. since then i've just listened to the SWIPE_DOWN event instead of the SWIPE_START event. it seems to be more reliable and works every time.

[peter9477]

You should count on SWIPE_START behaving that way even on the real device, because it appears to be what is intended... and why it's named that way.

If you want a quick but crude approach to opening an app menu, use SWIPE_DOWN.  This waits for you to bezel-swipe into the screen a certain distance, at which point it triggers once to indicate that you've effectively asked for the menu to appear.  (Personally, I think having the menu then appear instantly, or even slide down with an animation, doesn't look particularly smooth.)

If you want something more sophisticated, where the menu slides down as you swipe, you'll want to use SWIPE_START plus some additional logic to track the mouse.  I earlier posted some preliminary code demonstrating how you might do that.

You should also consider as part of this whether you want the menu to "push" your main window content down, or to slide down over top of it like a window blind.  There are arguments in favour of each approach, and it depends on the needs of your own app and personal preference.  (Maybe we'll see in a few months a trend to one or the other based on user feedback.)  One mental model I use for this is that if your app is "frozen" when the app menu opens, push it down.  If the app continues operating behind the scenes, leave it in place and slide the menu over top of it.

[peter9477]

Above, I referenced an earlier post with SWIPE_START code, but I've now discovered it is technically flawed. (I can't edit either post as they're too old.)

I've now analyzed the top-swipe behaviour fairly thoroughly (I think it was thorough anyway) and posted an article about it along with improved code for handling SWIPE_START.  The article also shows a snippet to use SWIPE_DOWN in a very simple way, if you prefer that.  I'm just working on a couple of state diagrams showing the sequence of events following SWIPE_START and will update the post shortly.

In any case, I wouldn't recommend anyone use my "preliminary code" referenced above, though it's quite functional (so don't go rewriting your app if it's already been submitted with something like that code).

[T55555]

@peter9477

Thank you Peter for the wonderful article and demo code about Swipe-Down menu.

After reading your article and analyze your code, I decided to go with my own simple version.

It is very close to your "Swipe_Start simplified" idea ( without state machine ).

Even I don't use your code, your article and demo code did help me a lot to come out with my own version.

So, thank you again Peter.  ( I may post a short movie about my app to show the menu action later ) 

[peter9477]

You're welcome!  Thanks for the feedback.

Note also the follow-up post, with a simplified approach outlined.  I haven't tried that one myself but there's no reason it shouldn't work pretty well.  I'm not going to bother with it myself until I have a real tablet to work on.

For my internal version of that code, which I used in my app, I adjusted things a bit, mainly to add an extra full-stage Sprite which lies under the menu whenever it is displayed.  It has a black, alpha 60% fill that partially obscures the underlying screen, to emphasize that the menu is active and to intercept the "outside" mouse-clicks so I can more easily ignore them.

I also added dispatching an Event.COMPLETE from the menu whenever it is closed, so I can listen for that and not update my preferences until the user actually dismisses the menu.

I also noticed something in some of the video demo apps we've seen, and in the Browser.  When you click below the menu and it closes, that first click is ignored by the app so it doesn't trigger any controls you might have clicked on.  I decided to follow the same convention in my app, unlike the posted code which watches for the outside click but doesn't try to block it.

[T55555]

---

>> I also noticed something in some of the video demo apps we've seen, and in the Browser.  When you click below the menu and it closes, that first click is ignored by the app so it doesn't trigger any controls you might have clicked on.  I decided to follow the same convention in my app, unlike the posted code which watches for the outside click but doesn't try to block it.

---

Yes, that's why you are using other Sprite ( transparent, or semi-transparent ) to block the click event.

I did the same at the beginning, but remove it, because for my app, it seems ok to accept the mouse event for both app-specific and close-menu actions. 

Again, this depend on the app, for most app, I would suggest follow Peter's suggestion. ( Don't mix change focus, or toggle button with close menu at the same time ).

---

>> I also added dispatching an Event.COMPLETE from the menu whenever it is closed, so I can listen for that and not update my preferences until the user actually dismisses the menu.

---

This is a good design, I already submit my app, too later to refactor it...

My solution is not very elegant, in fact, I need close-menu and after that open other page.

(scenario:  open menu => click a menu button => tweener to close menu => tweener to open selected page)

I don't know how to queue them directly on Tweener.

Maybe write your own queue and listen Event.COMPLETE ( means menu complete closed ) and start next open page tweener.

For what I did, I simply add "delay" time on next tweener to open the page,

and the delay time is the same amount time for menu tweener to close up.

[peter9477]

---

T55555 wrote:

For what I did, I simply add "delay" time on next tweener to open the page,

and the delay time is the same amount time for menu tweener to close up.

---

That appears to be the documented approach to "chaining" with the caurina.transitions.Tweener: "Also notice you can chain tweenings sequentially, creating complex animations, by using delays."

I find it a bit primitive, but it's another thing I'm just living with until getting a real PlayBook.  (At that point I'd start testing comparative performance of various tweening libraries and maybe switch to a different one.)

[T55555]

---

T55555 wrote:

So, thank you again Peter.  ( I may post a short movie about my app to show the menu action later ) 

---

Ok. I did a demo "movie" about my second app.

You can find it at:

http://www.doublegifts.com/product/peg-solitaire/peg-solitaire.html

The menu will bounce back if user "drag" less than 23 pixels.

Some menu buttons will not close the menu ( ex. Undo/Redo to allow sequence of multi Undo/Redo )

[shanerooni]

fyi...  your app description in the catalog says "action will sure to keep you entertained" and should say "action is sure to keep you entertained" or "action will be sure to keep you entertained".  looks like a nice app.