I just want to confirm this, because it is not stipulated in the docs; if an iOS device has its Orientation locked, then the Runtime orientation listener will not be able to determine device orientation, is this correct? It is definitely what I am seeing.
Hi @temp29,
I assume you mean that the orientation of the OS itself is locked, as in the user has pulled up the little “slide up” menu and selected to lock the orientation?
How (in your code) are you trying to detect or determine the orientation? It will help if we can see a basic code example.
Take care,
Brent
Yes, the little lock symbol in the “slide up” menu.
I am registering orientation this way:
Runtime:addEventListener( “orientation”, monitorOrientation )
But the function monitorOrientation never fires if the “slide up” orientation has been locked.
EDIT:
This code also only return the orientation that the device has been locked into:
function printO()
print( "ORIENTATION: "…system.orientation )
end
timer.performWithDelay(100, printO, 500)
Hi again,
Have you tried simply checking the system orientation property?
https://docs.coronalabs.com/api/library/system/orientation.html
Checking for orientation events (using a Runtime listener) won’t trigger in the case you describe because that only detects when the orientation changes from its current state.
Brent
Looks like our posts crossed in the night 
Yes, I tried with:
unction printO()
print( "ORIENTATION: "…system.orientation )
end
timer.performWithDelay(100, printO, 500)
but all it ever prints is the locked orientation…
Hi again,
The “locked” orientation is what I would expect to be printed. If I turn my “locked” phone to another orientation, the display remains in the locked orientation, so I wouldn’t expect it to change. Perhaps I’m not clear on your purpose/design?
Brent
It’s not clear in the docs that this is the expected behavior is all. I wish it worked differently I wish I could still read the orientation of the physical device even though the user had locked the display orientation of the device. Maybe add this in the “gotchas” for future me, after I forget what I learned in this thread…
When you lock the orientation, the OS guarantees your app will be in the locked orientation. Why do you need to know if it’s rotated when the user explicitly wants a single orientation?
Rob
I’m using device orientations to trigger events. Even if the user does not have orientation locked, I only allow a portrait orientation for the app display, but still need to track the orientation of the device.
That said, I just rolled my own using the accelerometer. faceDown was kind of a challenge but done now, so all good. Maybe a quick reminder to folks in the gotchas that you cannot collect orientation data from a device where the orientation has been locked. Or not - likely I’m the only one who did not understand that particular detail…
Hi @temp29,
I assume you mean that the orientation of the OS itself is locked, as in the user has pulled up the little “slide up” menu and selected to lock the orientation?
How (in your code) are you trying to detect or determine the orientation? It will help if we can see a basic code example.
Take care,
Brent
Yes, the little lock symbol in the “slide up” menu.
I am registering orientation this way:
Runtime:addEventListener( “orientation”, monitorOrientation )
But the function monitorOrientation never fires if the “slide up” orientation has been locked.
EDIT:
This code also only return the orientation that the device has been locked into:
function printO()
print( "ORIENTATION: "…system.orientation )
end
timer.performWithDelay(100, printO, 500)
Hi again,
Have you tried simply checking the system orientation property?
https://docs.coronalabs.com/api/library/system/orientation.html
Checking for orientation events (using a Runtime listener) won’t trigger in the case you describe because that only detects when the orientation changes from its current state.
Brent
Looks like our posts crossed in the night Yes, I tried with:
unction printO()
print( "ORIENTATION: "…system.orientation )
end
timer.performWithDelay(100, printO, 500)
but all it ever prints is the locked orientation…
Hi again,
The “locked” orientation is what I would expect to be printed. If I turn my “locked” phone to another orientation, the display remains in the locked orientation, so I wouldn’t expect it to change. Perhaps I’m not clear on your purpose/design?
Brent
It’s not clear in the docs that this is the expected behavior is all. I wish it worked differently I wish I could still read the orientation of the physical device even though the user had locked the display orientation of the device. Maybe add this in the “gotchas” for future me, after I forget what I learned in this thread…
When you lock the orientation, the OS guarantees your app will be in the locked orientation. Why do you need to know if it’s rotated when the user explicitly wants a single orientation?
Rob
I’m using device orientations to trigger events. Even if the user does not have orientation locked, I only allow a portrait orientation for the app display, but still need to track the orientation of the device.
That said, I just rolled my own using the accelerometer. faceDown was kind of a challenge but done now, so all good. Maybe a quick reminder to folks in the gotchas that you cannot collect orientation data from a device where the orientation has been locked. Or not - likely I’m the only one who did not understand that particular detail…