Skip to main content
Projectitis
Inspiring
November 22, 2015
Answered

Android rotation events

  • November 22, 2015
  • 1 reply
  • 483 views

Hi all,

I'm currently in the middle of the Android rotation saga.  My app allows rotation and listens for the rotation events.  After a rotation, my app rearranges the UI based on the new orientation.  Here are my observations:

  • Note: These results are on a Samsung Google Nexus with Android 4.3.  I have used other devices in the past which have given different behaviours.
  • Minor: Even though the docs say StageOrientationEvent.ORIENTATION_CHANGING are not dispatched on Android, in my testing they ARE.  Doesn't matter, I ignore them anyway
  • Major: On receiving the StageOrientationEvent.ORIENTATION_CHANGED event, the screen width/height are always the wrong way around.  If I rotate from portrait to landscape they are reported still in portrait mode, and if I rotate back to portrait they are in landscape when the event fires.  I could just swap them, but I have a feeling that this may be OS version of device specific so I really do not want to in case it breaks on other devices.
  • Major: I can't use stage.deviceOrientation to determine the actual orientation, because DEFAULT is landscape on some devices (usually tablets) and portrait on others (usually phones).
  • Major: I have tried waiting until the next frame to read width/height. Doesn't work (on my test device).  Have tried waiting a set time period (.e.g 250ms) before reading and handling width/height. Sometimes works, but not reliable.  Could set it to some higher value (like 1000 or 2000ms) but then there is an (even uglier) pause during rotation.

So what I can conclude from this:

  • StageOrientationEvent.ORIENTATION_CHANGED is not actually 'changed' (after) it is still before or during rotation
  • It is unreliable to wait a set amount of time after ORIENTATION_CHANGED as a strategy for handling rotation

My question:

How do you guys reliably detect and manage orientation changes?

Do you know if this problem is OS version dependent, device dependent, or AIR version dependent?

Cheers,

Peter

This topic has been closed for replies.
Correct answer Colin Holgate

Quite a few versions ago the rotation behavior was changed in AIR. You used to have to handle preventing the orientations you didn't want. After the change, if you have set Landscape as your orientation, Portrait will never be allowed. And vice versa. It made life very easy if your app only needed to be one or the other.

If you need the app to be either portrait or landscape, it's possible that the Auto setting would allow that, I'm not sure. The alternative is to disable autorotation and do all the accelerometer readings yourself. Amongst the many complication there is the fact that an iPad sat flat on the table, like say you were in landscape and rested it down, will read as being portrait, and the orientation would rotate away from the user.

When I did have to do an app that had some parts portrait and some landscape, I gave up on trying to cope with that, and just made my landscape parts be on the stage at 90 degrees.

But, there's another approach, if you happen to be using stage.scaleMode="noScale", you could remove any code you have that listens to the orientation, and instead just use a resize event function. That ought to work.

1 reply

Colin Holgate
Colin HolgateCorrect answer
Inspiring
November 22, 2015

Quite a few versions ago the rotation behavior was changed in AIR. You used to have to handle preventing the orientations you didn't want. After the change, if you have set Landscape as your orientation, Portrait will never be allowed. And vice versa. It made life very easy if your app only needed to be one or the other.

If you need the app to be either portrait or landscape, it's possible that the Auto setting would allow that, I'm not sure. The alternative is to disable autorotation and do all the accelerometer readings yourself. Amongst the many complication there is the fact that an iPad sat flat on the table, like say you were in landscape and rested it down, will read as being portrait, and the orientation would rotate away from the user.

When I did have to do an app that had some parts portrait and some landscape, I gave up on trying to cope with that, and just made my landscape parts be on the stage at 90 degrees.

But, there's another approach, if you happen to be using stage.scaleMode="noScale", you could remove any code you have that listens to the orientation, and instead just use a resize event function. That ought to work.

Projectitis
Inspiring
November 24, 2015

Thanks Colin - yep, I'm using scaleMode='noScale', so resize events worked great. The stupid thing is that the Facebook and standalone version of the game were already conditionally coded to work that way, and iOS/Android versions coded to listen for rotation.  So I already had the correct code in place to manage the resize event!