03-12-2011 05:15 PM - edited 03-12-2011 05:20 PM
Hey guys and gals,
there has been a huge wonder in the community about how the swipes on the bezel will work if the playboook is rotated to portrait mode. a recent video at SXSW shows these gestures and more in protrait mode. here is a link to the video:
how we will have to handle this on our end is unknown to me but at least we know that the roation does change the way the bezel works!
EDIT: For those in a rush, you can skip to 5:45 of the video and that's where the fun begins!
03-12-2011 05:20 PM
03-12-2011 06:18 PM - edited 03-12-2011 06:19 PM
I would hope and think that the events the application receives is not different based on the orientation of the device. The events would be relative to the orientation and not absolute to the device.
PlayBook looks super amazing! I expect 1.0GM SDK will be out on March 31st as well.
03-12-2011 09:03 PM
I agree with John. The bezel gestures are for the system only. The only except to this is the down swipe from the top bezel. This just shows that the system will dispatch the QNXApplicationEvent.SWIPE_START event correctly depending on the orientation of the device. I don't think we'll ever have access to the other gestures. Which is the way it should be.
03-12-2011 09:57 PM
I watched that video with interest and agree that it does clear up one of the questions we've had, though we really never expected this to work any other way. Certainly for apps which reorient themselves properly, most of us always believed the bezel gestures would naturally track the current orientation in the expected manner.
Unfortunately it still leaves open one interesting question, as we discussed earlier in this thread. Specifically, for an app with a fixed orientation, if you have the device oriented the other way (turned 90 degrees to the app), how are the bezel gestures reoriented.
Think it through carefully before jumping on that and saying it acts identically to how it works with the reorienting apps.
If you have an app fixed in portrait mode, but the device is held in landscape mode (so the app is turned sideways), then the "top" of the screen for the app is (say) on the left.
Now you do a "top-swipe" relative to the tablet itself. Most would agree it would be unusual if this was interpreted as a right-swipe gesture to switch between apps. Agreed. So it must be a "top-swipe" to the app, right? Well, does the app pull down its app menu from the left, across the narrow part of the screen? Really? So, while your finger is tracking down the screen from the camera towards the BlackBerry logo, the app sees it as though you are moving your finger "down" into the screen (but really from the left)... this would require the X and Y coordinates to be swapped, and the user would see the menu appearing one the left instead of where they dragged their finger. For SWIPE_DOWN this might be just weird, but for SWIPE_START it would be downright bizarre, since you can make the menu appear but then disappear again if you move your finger back into the bezel region.
And what about the system menu? If you top-left or top-right swipe, does the system menu appear in landscape mode, relative to the tablet orientation? That would make it appear sideways along the edge of the app, with the text rotated 90 degrees relative to the text in the app.
Somehow I still get the impression we've never been shown this because it just makes little sense no matter which way you do it... And that video doesn't close the book on this question at all.
03-12-2011 10:32 PM
Hey Peter, you make a good point. It would be nice if the system recognizes something like stage.align = StageAlign.TOP_LEFT and the bezel gestures don't change orientation like the app.
03-13-2011 04:41 AM
most likely the gesture changes will be heavily reliant on the <autoOrient> tags in the -app.xml configuration file. and it'll respond accordingly. seems the most logical way to go
04-01-2011 11:49 AM
I just posted a lengthy description of how this works in the build we played with at the Dev Day in Toronto yesterday. Apologies for the length of that, but it's much harder to describe than it is to demonstrate.
In short, they've picked what is probably the best way for this to work, even if it's going to be slightly confusing under certain conditions (swiping between apps with fixed orientations different from the one the device is held in).