Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

Corona vs Native Orientation Startup
Started by tedsdogs Aug 13 2013 11:43 AM

4 replies to this topic
orientation startup
[TOPIC CONTROLS]
This topic has been archived. This means that you cannot reply to this topic.
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#1

tedsdogs

[GLOBAL: userInfoPane.html]
tedsdogs
  • Observer

  • 8 posts
  • Corona SDK

Hi,

 

On startup I am getting a different orientation value between Corona and native build: First, in Corona I lock the orientation to port and handle port, left and right (upside down just 180's port) myself.

 

Before you start the app:

  Hold the ipad upside down.

  Now lay it faceup on a surface but still upside down relative to you looking at it. The 'desktop' is correctly oriented for the USD orientation.

 

Now start the app.

 

The application displays UPSIDEDOWN.

 

Here is why:

 

Corona:

    First we get an orientation of PORTRAIT followed immediately by faceup.

 

Native xcode (objective-c) build:

    First we get an orientation of PORTRAIT-UPSIDEDOWN followed immediately by faceup.

 
So the native build knew the system was still in UPSIDEDOWN yet Corona does not report this.
 
The bottom line is Corona is not reporting startup orientation events like native xcode does.

 

I have tried a bunch of things to get around this but nothing yet.

 

Any of you Corona guru's out there know any way around this?

 

BTW this is not a corner case. We are seeing this occur at a high enough rate under normal usage that it could leave bad impressions as a first impression - and first impressions are very important these days. Same thing happens with left and right except that starting shows the app sideways.

 

After a tilt and we get oriented correctly everything is great after that. It is just that first message is wrong.

 

Thanks All,

The Dogs

 


[TOPIC: post.html]
#2

bjsorrentino

[GLOBAL: userInfoPane.html]
bjsorrentino
  • Veteran

  • 8,506 posts
  • Corona SDK

Hi @tedsdogs,

Can you post some of the code that you're experimenting with?

 

Thanks,

Brent Sorrentino



[TOPIC: post.html]
#3

tedsdogs

[GLOBAL: userInfoPane.html]
tedsdogs
  • Observer

  • 8 posts
  • Corona SDK

<

local last
 
timer.performWithDelay(100,function()
  if not last or last~=system.orientation then
    print('==============  '..system.orientation)
    last = system.orientation
  end
end, 0)
 
local function onOri(event)
  print('===========|||  '..event.type)
  return true
end
Runtime:addEventListener("orientation", onOri )
>

 

Build settings supported is portrait only, default portrait.

 

The timer reports the initial orientation as portrait. The event handler then gets the face up and the timer see's it. That's it until you tilt the pad to force an orientation change

 

 

xcode:

<

- (void)deviceOrientationDidChangeNotification:(NSNotification*)note

{

    UIDeviceOrientation orientation = [[UIDevice currentDevice] orientation];

    NSLog(@"ORI  %d", orientation);

}

 

     [[NSNotificationCenter defaultCenter]

     addObserver:self

     selector:@selector(deviceOrientationDidChangeNotification:)

     name:UIDeviceOrientationDidChangeNotification

     object:nil];

>

 

Here we get notifications as I said for both states (as opposed to reading some system variable)

 

 

I will say that I think Apple screwed up by having 2 sets of non-mutually-excluded states under 1 enum. Corona does seem to send the 'current' state of the orientation (in the case of my issue a face-up) but the pad can be face-up in any of the 4 orientations - so if it is first face-up or face-down the current state is completely meaningless. Apple breaks that enum up into 2 enums or a bit-mapped field and this issue never happens.

 

Thanks

 

 

PS: My first post may have misspoke by saying Corona 'sends' the 1st portrait - whereas I was reading system.orientation. Sorry for any confusion. Bottom line is applications are unaware of the initial orientation if the pad is face-up/down.



[TOPIC: post.html]
#4

bjsorrentino

[GLOBAL: userInfoPane.html]
bjsorrentino
  • Veteran

  • 8,506 posts
  • Corona SDK

Hi @tedsdogs,
As you hinted, this is something of a "hardware design problem", because there are 2 kinds of "orientations":
1) the "device" orientation such as upright, sideways left, sideways right, upside down, face up, and face down.
2) the "app/content" orientation such as portrait, landscapeRight, landscapeLeft, and portraitUpsideDown.
 
They're fairly separate, when you consider it. The face up scenario is a good example of this. Face up is the orientation of the device, but typically, the orientation of the app won't change (it will remain portrait or landscape). There is also the scenario where you rotate the device to landscape, but the app only supports and displays portrait. That's a more common issue.
 
Note that we have a better way to identify if your app orientation has changed from portrait to landscape and vice-versa, using Corona's "resize" event. This works on all platforms and has been available since the last release version.  I recommend that you re-layout your app via this event instead of the "orientation" event.
 
 
Best regards,
Brent


[TOPIC: post.html]
#5

tedsdogs

[GLOBAL: userInfoPane.html]
tedsdogs
  • Observer

  • 8 posts
  • Corona SDK

Hi Brent,

 

That won't work for me since I lock the orientation in the build settings.

 

I do have a partial solution: If the first orientation message I get from Corona is face up/down - I look at the x and y gravity and determine the orientation to start with. Partial because if you start the app with the ipad face up then the x and y gravity are essentially small random values. But that starts to be a corner case.

 

It would be nice if you guys looked into sending 2 orientation events, like native, if the current is face up/down. I assume (possibly incorrectly) that your startup code gets the messages from the OS or could.

 

Anyway thanks for the responses Brent.

 

The Dogs




[topic_controls]
[/topic_controls]