Orientation support problem on android 4.0 (samsung galaxy tab 2, 10.1")

Solar2D Android
#1

Hello everyone,

I did a little coding for my bachelor thesis and I now have a problem with my content when changing the orientation of the device, I’m testing on.

I have 18 pngs that get arranged on the screen depending on resolution and orientation. The initial orientation always works fine no matter if it’s portrait or landscape but whenever I turn the device to another orientation the whole content gets a little out of place (about 50 pixel up and 50 pixel to the left). Seems to be about the height of the android status bar (which I learned can not be turned off on android 3.0 or higher?).
I tested the code on a galaxy smartphone and an iPad and it seemed to be ok.

In my config.lua i did not specify a resolution and also no scale and my build.settings support all orientations while “portrait” is default.

Any ideas? Is this an android 4 problem?

Thanks in advance

Roman [import]uid: 127006 topic_id: 27410 reply_id: 327410[/import]

#2

Roman,

This is a known bug that only occurs on Android 3.x and 4.x tablet devices. It is a bug with how Corona handles changes in orientation. Corona merely swaps the width and height when an orientation occurs, which on most platforms and devices this works fine. But on Android 3.x and 4.x tablets, Android’s virtual navigation bar moves when the app changes orientation, causing the width and height to totally change. That is, the aspect ratio of the app actually changes. So, swapping the width and height on these devices doesn’t work and it causes the app’s content to be misplaced like you are seeing.

Currently, the only work-around for this issue is to set a fixed orientation for your app and handle the orientation changes yourself. Not a great solution for sure, but that’s the best we can offer at the moment. Fixing this issue won’t be trivial on our end, but it is definitely on our to-do list. Especially since a change of width and height of the app is necessary when we eventually support Mac app builds. [import]uid: 32256 topic_id: 27410 reply_id: 111400[/import]

#3

Thank you, Joshua, for the information!

[import]uid: 127006 topic_id: 27410 reply_id: 111492[/import]

#4

Has there been any progress with the orientation support? [import]uid: 127006 topic_id: 27410 reply_id: 120565[/import]

#5

Unfortunately, no. We haven’t had time to look into this yet. No ETA yet. The only work-around at the moment is to use a fixed orientation. [import]uid: 32256 topic_id: 27410 reply_id: 120719[/import]

#6

Has there been any progress with the orientation support? [import]uid: 127006 topic_id: 27410 reply_id: 120565[/import]

#7

Unfortunately, no. We haven’t had time to look into this yet. No ETA yet. The only work-around at the moment is to use a fixed orientation. [import]uid: 32256 topic_id: 27410 reply_id: 120719[/import]

#8

Having difficulty with this issue as well on Nook HD+, hoping for a resolution soon! Thanks. [import]uid: 40337 topic_id: 27410 reply_id: 135748[/import]

#9

Having difficulty with this issue as well on Nook HD+, hoping for a resolution soon! Thanks. [import]uid: 40337 topic_id: 27410 reply_id: 135748[/import]

#10

Any new updates on this issue? It’s causing trouble for me on the Nexus 7. [import]uid: 69807 topic_id: 27410 reply_id: 138385[/import]

#11

Any new updates on this issue? It’s causing trouble for me on the Nexus 7. [import]uid: 69807 topic_id: 27410 reply_id: 138385[/import]

#12

Bump! Is there an update on status of this issue? The problem has been around for more than a year already and it is affecting more and more devices as android tablets keep popping up. It’s a pretty deal-breaking problem when it comes to cross compatibility of the apps, as orientation doesn’t work on any Android tablet running any of the recent Android versions.
 

As stated elsewhere on this forum, it will probably require adding onResize event that should resize OpenGL window behind the scenes and update the variables such as display.contentWidth etc…  and more importantly return correct touch coordinates. Additionally onResize event MAY be exposed to Lua, but I think it’s of lower priority because we would already know that the resize has occurred because orientation event would be fired anyway.

Really after a year I think this issue, which is a pretty core problem, should deserve at least a bit of attention.

Thanks

N.

#13

This issue was fixed as of of the last release version, build #1137.

We’ve also added a new “resize” event which is documented here…

   http://docs.coronalabs.com/api/event/resize/index.html

The resize event is needed because the bottom navigation bar on Android tablets 3.x and higher rotate with your app, cause the aspect ratio of your app to change with it.  That is, the width and height of your app will not simply swap like it does on iOS.  Also, the height of the application window has been known to change (particularly on the Nook HD/HD+) when returning from an app that displays a status bar.  This means that a resize kind occur without an orientation event, making the above mentioned “resize” event necessary.

Things to note:

  • If your app uses “letterbox” scaling, then changing orientation will cause the content scales to change, and Corona will automatically fit its contents within the application window.

  • If your app uses “zoomEven” scaling, then the content scales may not change, but your viewableContentWidth/Height will.  This can be detected via a resize event.

Anyways, I hope this helps!

#14

Joshua, thanks, I overlooked that this feature already has been added :slight_smile: This should totally solve the issue! Thanks

#15

Happy to help.  And sorry about not informing everyone on this forum thread.  We try our best to spread the word, but our forums are active enough that it’s easy to miss some of them.

Just so you know, the other advantage of the “resize” event is that it’s the perfect event to use to relayout your app’s contents.  For example, using an “orientation” event to layout your screen is wasteful when transitioning between landscapeRight and landscapeLeft, because the content width/height and scaling should be the same.  In that circumstance, the “resize” event will not get resized… but a “resize” event will get raised when transitioning between landscape and portrait.

That said, the “orientation” event still has its uses.  Particularly for fixed orientation apps that rotate their controls when rotating the device.  A perfect example of this is a camera app which is typically locked to a portrait orientation, but rotates its buttons when rotating the device.

#16

Bump! Is there an update on status of this issue? The problem has been around for more than a year already and it is affecting more and more devices as android tablets keep popping up. It’s a pretty deal-breaking problem when it comes to cross compatibility of the apps, as orientation doesn’t work on any Android tablet running any of the recent Android versions.
 

As stated elsewhere on this forum, it will probably require adding onResize event that should resize OpenGL window behind the scenes and update the variables such as display.contentWidth etc…  and more importantly return correct touch coordinates. Additionally onResize event MAY be exposed to Lua, but I think it’s of lower priority because we would already know that the resize has occurred because orientation event would be fired anyway.

Really after a year I think this issue, which is a pretty core problem, should deserve at least a bit of attention.

Thanks

N.

#17

This issue was fixed as of of the last release version, build #1137.

We’ve also added a new “resize” event which is documented here…

   http://docs.coronalabs.com/api/event/resize/index.html

The resize event is needed because the bottom navigation bar on Android tablets 3.x and higher rotate with your app, cause the aspect ratio of your app to change with it.  That is, the width and height of your app will not simply swap like it does on iOS.  Also, the height of the application window has been known to change (particularly on the Nook HD/HD+) when returning from an app that displays a status bar.  This means that a resize kind occur without an orientation event, making the above mentioned “resize” event necessary.

Things to note:

  • If your app uses “letterbox” scaling, then changing orientation will cause the content scales to change, and Corona will automatically fit its contents within the application window.

  • If your app uses “zoomEven” scaling, then the content scales may not change, but your viewableContentWidth/Height will.  This can be detected via a resize event.

Anyways, I hope this helps!

#18

Joshua, thanks, I overlooked that this feature already has been added :slight_smile: This should totally solve the issue! Thanks

#19

Happy to help.  And sorry about not informing everyone on this forum thread.  We try our best to spread the word, but our forums are active enough that it’s easy to miss some of them.

Just so you know, the other advantage of the “resize” event is that it’s the perfect event to use to relayout your app’s contents.  For example, using an “orientation” event to layout your screen is wasteful when transitioning between landscapeRight and landscapeLeft, because the content width/height and scaling should be the same.  In that circumstance, the “resize” event will not get resized… but a “resize” event will get raised when transitioning between landscape and portrait.

That said, the “orientation” event still has its uses.  Particularly for fixed orientation apps that rotate their controls when rotating the device.  A perfect example of this is a camera app which is typically locked to a portrait orientation, but rotates its buttons when rotating the device.