Odd orientation issue

PaulH · April 1

I have an app that usually supports only landscape orientation. If I let autorotation deal with it, it correctly flips between landscape left and landscape right. It has one buggy looking behavior when turned to a portrait orientation, though. It appears to start to rotate, and then snaps back to landscape. I see that in any Gideros app I build with autorotation enabled.

In my case my app mostly requires landscape, but it has one mode in which the code itself supports both landscape and portrait orientations. While it's not really necessary to support those orientations within this app, I've been trying to do that.

For that I have code to detect changes in the device orientation, and switch the application orientation to match if portrait is currently supported, and if not, only switch when the device orientation is landscapeLeft or landscapeRight. Here's a demo that uses similar code:

tf = TextField.new(nil, "Some text")
stage:addChild(tf)
tf:setPosition(100, 300)
tf:setScale(6)
 
stage:addEventListener(Event.ENTER_FRAME,
	function()
		local orientation = application:getDeviceOrientation()
		if last_orientation ~= orientation then
			print("\nDevice orientation changed!")
			last_orientation = orientation
 
 
			local support_portrait = true
			if orientation == "portrait" and support_portrait then
				application:setOrientation(Application.PORTRAIT)
			elseif orientation == "portraitUpsideDown" and support_portrait then
				application:setOrientation(Application.PORTRAIT_UPSIDE_DOWN)
			elseif orientation == "landscapeLeft" then
				application:setOrientation(Application.LANDSCAPE_LEFT)
			elseif orientation == "landscapeRight" then
				application:setOrientation(Application.LANDSCAPE_RIGHT)
			end
 
			print("App orientation:", application:getOrientation())
			print("Device orientation:", orientation)
 
		end
 
	end
)

If I set support_portrait set to true, it works as I would expect in a Gideros Player on Android, almost. If I rotate slowly enough to let it catch each 90 degree change, it will display in the correct orientation. But if I run it starting in landscapeLeft and quickly flip the device to landscapeRight, the output will say that both the app and device are in landscapeRight, but the screen will actually be in landscapeLeft and appear upside-down. If I allow it to be in portrait orientation for at least one frame between the two landscape orientations, it works fine.

If I set support_portrait to false, then start in landscapeLeft and rotate to portrait, the screen will flash as autorotation tries to change it, then it stay in landscapeLeft, as usual for autorotation apps. If I then rotate further into landscapeRight, the screen displays in landscapeLeft and is upside-down, though the output says both the device and application are in landscapeRight. If I keep rotating, now to portrait-upside-down, the display changes to landscapeRight and stays there through any device orientation other than portrait-right-side-up, at which point it will switch back to landscapeLeft.

It's almost as though application:setOrientation() doesn't work for switching between landscape left and landscape right unless it's set to a portrait orientation in between.

I thought it might be an issue with autorotation and this directly implemented rotation interfering with one another. But if I turn off auto-rotation during the build, application:getDeviceOrientation() always returns the initial orientation no matter how the device is held.

Am I misunderstanding something, or is this a bug?

Paul

hgy29 · April 2

It looks like a bug to me, but orientation stuff has always been acting strangely to me, as though Gideros is trying to handle it while Android or iOS also try to handle it by themselves. If you add the two android specific options in 'Require' plugin (Screen doesn't rotate and Game can be both portrait and landscape) into the equation, things become even more incomprehensible.

Add to that that sometimes your app will display as you expect, until your try to draw some native UI (keyboard for example) on top of it and see that it is drawn sideways...

I reckon an in-depth analysis of what Gideros do and what the OS do is needed here.

hgy29 · April 2

I have been reading Gideros code and Android code and things get clearer, and obviously a few things are rather hacky. I wonder why it was done that way in Gideros Android code, maybe that was no other way ? I'll try to do it properly.

PaulH · April 2

Thanks for looking into it!

hgy29 · April 4

I think I'll need your understanding here. Gideros internally deals with three orientations:
- hardware orientation (that is the canvas orientation)
- device orientation (I am not sure about this one)
- app orientation (the way you want your application to be displayed)

Only device orientation and app orientation are available to lua. I thought device orientation was supposed to reflect the way you hold your device, irrespective of canvas orientation, but I discovered that accelerometer demo uses device orientation to compensate raw accelerometer values, which are more tied to hardware orientation.

So I feel I didn't get the meaning of device orientation, what in your opinion is supposed to be device orientation ?

PaulH · April 4

I assumed the same, that "device orientation" meant the orientation of the physical device based on the accelerometer. I would think that "hardware" and "device" would be interchangeable in this context, but perhaps they're not.

I've considered turning off all autorotation and implementing whatever set of orientations I want to support directly, based on the accelerometer. That seemed like it would be reinventing the wheel if everything necessary to support that was already in place though.

hgy29 · April 5

@PaulH, yes you are right to remind me about autorotation, since this is what cause the misunderstanding.
When autorotation is enabled, then real device orientation actually matches canvas orientation (or at least android rotates the canvas at some point to catch up).
When it isn't, real device orientation may not match canvas orientation, but possibly the developper don't care.

Although I managed to diffentiate both on android, it is probably better to have deviceOrientation mean orientation the OS reported, according to autorotation/orientation settings in the project properties. That way I won't break any existing code.

But I think autorotation setting should be redefined. I don't see the point of enabling it for iPhone and not for iPad, but I'd see a benefit of allowing developper to chosse between fixed orientation, full rotation (4 directions) and only portrait or landscape (still 2 directions). It also have more options such as locked / nosensor if I manage to figure out what they actually do in Android.

PaulH · April 5

I agree it would be ideal to be able to specify those orientations to support in the project properties.

The scenario I was dealing with, an app that usually must be in landscape but has one function in which it could potentially support either, is certainly an unusual case and not worth worrying about.

I'm assuming it's the Android layer that causes the screen to start to turn and snap back if the app is setup for landscape only and you turn the device to portrait. The idea of preventing that behavior that had me considering writing my own separate orientation handling using the accelerometer.

hgy29 · April 9

So this will probably be a breaking change for some apps, but I decided to clean up orientation settings and behavior. In the projection properties, we will now configure initial orientation and auto-rotation configuration for all supported platforms.
Autorotation will have four options: Normal (no autorotation), Dual (normal and upside down), All (four directions) and Fixed (no autorotation, device orientation choosen by the system (nosensor on android).
Additionnally, setOrientation will make the device orientation change, and autorotation will be changeable too from lua.
I think that will cover all use cases.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Odd orientation issue

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Odd orientation issue

Comments