Tag Archives: problem

iPhone app orientation (portrait vs landscape)

Introduction

The UIInterfaceOrientation property that can be put in an iPhone app’s Info.plist file, has lead me into a confusing environment of iPhone app orientation design.
At the top level, there are two ways the orientation can be considered: 1- the physical orientation of the device; 2- the orientation of the on-screen user interface.
And when developing an app, these two things can be inconsistent, and confusing.
The iPhone has 7 different physical DEVICE orientations, 3 of which I am not covering (face-up, face-down, unknown).  The 4 device orientations that are considered in this writing are: landscape-left (homebutton is on right), landscape-right (home button is on left), portrait (home button is down), portrait-upside-down (home button is up).
The iPhone has 4 different interface orientations. Two are portrait and portrait-upside-down that equal the physical device portrait orientations.  The other two are the landscape-right and landscape-left, but these are the opposite: interface-landscape-right = device-landscape-left,  and the other is flipped too.  If the device is rotated one way, the interface rotates the other way, to maintain a consistent “up” direction.

Setup

The specifics of my app:
I have a subclassed UIViewController, and its main view property is assigned a subclassed UIView object.
The main view is added to the UIApplication’s window.
Standard setup so far.
The UIView subclass has an overrided – (void) layoutSubviews method.
The UIViewController subclass has a method registered by the app delegate to receive notifications on orientation change, through the default notification centre.

Testing

There is something inconsistent between the notification centre for orientation change, and the value of [UIApplication sharedApplication].statusBarOrientation value.
Now to test:
For a start, the Info.plist file has the UIInterfaceOrientation key set to UIInterfaceOrientationLandscapeRight.
layoutSubviews will always fire first, and a check during the method for [UIApplication sharedApplication].statusBarOrientation shows landscape-right, as defined in the plist.
Then, sometimes-or-not, the orientation-change notification is sent to the registered object.
Starting the app while the device is physically in portrait, NO orientation change notification gets sent.
However, starting while the device is in any other physical orientation, then an orientation change notification is sent.
So it seems there is an expected default physical Portrait orientation, which cannot be manually defined, yet the default interface orientation can be pre-defined using [UIApplication sharedApplication].statusBarOrientation.
There are more haywire behaviours beyond this, if the device is then physically re-oriented after the app starts, more confusing behaviours.

Conclusions

Today was spent working on front-end app menu screens. My project originally started with the style and layout of screens drawn on paper in landscape orientation.  But, before today, I did not know it’s possible to use landscape-orientation images in Interface Builder nib files.  Now I know, and they can be displayed properly, if the right combination of settings are applied, such as the “Simulated User Interface Element-Orientation” setting in the inspector of IB, set to landscape, and interface orientation in the app.
Before today, I’ve done all my customized orientation positioning and rotation using the views’ center, frame, bounds and transform properties.
So, now, I can possibly adopt the built-in auto resize/rotation system.  Even if I don’t use that resize/rotation system, it could also make positioning easier.  It’s not difficult (now), to calculate the horizontal and vertical center of a shape, and position it within another shape whose width and height keeps changing.  Still, an easier way is always a good thing!
Working with all this is leading me to the following conclusions:
  • An app that has some parts that work only in landscape, and other parts that work only in portrait, should be upgraded so all parts work in all orientations.
  • An app that supports either (aka every) orientation, should not have the UIDeviceOrientation key set, because it leads to confusing situations (unless someone can suggest a good reason for it).
  • But, an app that supports any orientation … should, as a standard, start with the Default image designed to be portrait-oriented, not landscape, like so many iPhone games are that I’ve bought.
  • This final concluding point, personally speaking, is the the biggest problem to be solved: the conflicting desires or requirements: the desire to be universal and support either/every orientation (oh the bad memories of the browser wars come flying back), and the desire also prioritize one orientation with the other less-prioritized.

That’s all, folks!

Terrible conflict, but I am happy I could articulate this whole mess!
Posted in Technology, Thoughts | Tagged , , , , , , | Leave a comment

Problems with iPhone device provisioning

Before working on the iPhone, I have only a day or two’s experience with secure certificates.  The SSL certificate I bought for a web site took a day to buy and another day to setup.

Now, I am dealing with these secure certificates again, and it’s a bit challenging because of my lack of experience!

The task at hand: get Xcode to properly upload one of my apps for testing on the iPod touch.  I think the provisioning is giving me troubles, or something else is.   When I tried to build an app I downloaded as a tutorial, it had someone else’s name in the configuration for the device, so I changed it to my own and also included the certificate, and it still kept telling me the other person’s name was in the configuration.

So I stopped trying to use that tutorial project, and went back to my own, and discovered that Xcode is bugged up.  I try to build and run, setting the device as the Active SDK.

And it uploads the app, but if I am running the debugger, and I click build and debug, it uploads, but gives me an error saying “Failed to upload the ___ app”

Then I look at the iPod touch, and the app is sitting there.  I delete the app, repeat the process, and it’s exactly the same as described.

I’ve checked every single Build-Debug configuration setting and they’re all proper, so I know the issue is not there.

I’ve just finished restarting the iPod touch, and the results:

Failure.

I’m really puzzled.  Possibly some other file is causing me grief.    I created a new test project to verify Xcode can still upload and debug, and yes, it can still upload and debug.  So, there’s something buggy with the app.  Cleaning the targets doesn’t help either.

And this issue has started since testing this other tutorial app out.

EDIT: I have solved this issue after checking google a second time.  First time searching for the problem did not give any success, but second time I found this: Failed to upload XXX.app

More information: The location of the name of this other person was in the Code signing area of the TARGET, but not of the PROJECT.    That’s solved now.

Posted in Technology | Tagged , , , , , , , , | Leave a comment