Biblicious was originally an iPhone only app because the iPad did not exist. When the iPad was coming out, I used a similar algorithm to my Elastic Window product in order to naturally scale up the drawing so that the game looked just as good on the iPad as it did on the iPhone. The iPad was released, and then the iPad2 was released, and Biblicious still only worked in portrait mode. After a few requests and knowing that Apple prefers iPad apps to work in any orientation, I started the work of manually repositioning controls on the game screen. After a couple of days of work, mostly in the iOS Simulator, the game was ready. I could control when changing orientation was allowed or not. For example, not allowing the orientation to be changed while any Core Animation was going on. Everything looked great! I thought it was so neat that I would actually sit there and play with the orientation just so I could watch the controls move around. Life was good, and I was happy that I finally got this code done. I released that update & everything was good. But after a few days I saw a “nasty” review on the AppStore: “With the latest update the answers are all on top of each other and cannot be read unless you start trying to tilt the iPad in such a way they clear up. It doesn’t always help. Please try to correct.” Not very helpful, I know.
I repeatedly tried to make Biblicious do this, asked Pariahware followers on Facebook & Twitter, and received no responses. I asked a few friends and nobody said they had every seen this overlapping button issue. As every developer knows, we have no way of contacting our customers when they comment and we have no way to rebut. After a few days this person also sent me a support email from within Biblicious. I told them that I could not make it happen and asked them to send me detailed steps. — No response.
I figured that I should go ahead and try it again. Due to my scaling code, I thought I would try to make the overlapping button issue happen on the iPhone where no scaling happens. If it didn’t happen on the iPhone, then I knew I would need to concentrate on the scaling code. So, I hooked up my iPhone and ran the app from Xcode. I start a new game and began to play with the device’s orientation. Lo and behold I saw a button partially land on top of 2 other buttons as the buttons were being animated onto the screen. I was perplexed and tried it again, this time on the iPad. How could this happen? I check the device orientation for UIDeviceOrientationPortrait and UIDeviceOrientationPortraitUpsideDown and perform portrait drawing code otherwise perform landscape drawing code.
Upon further searching, I noticed that sometimes I was checking for [[UIDevice currentDevice] orientation] and in other places, I was checking for [[UIApplication sharedApplication] statusBarOrientation]. The latter was actually “forced” upon me with the iOS 5 SDK install due to compiler warnings. The former, obtains the device’s orientation which can return a number of results corresponding to the 3D plane, including face down. The latter essentially returns landscape or horizontal. So, what was happening in my code was, I was asking the device for it’s orientation in 3D space which was most likely returning UIDeviceOrientationFaceUp. Since my code didn’t know how to react, it just kept drawing in it’s last known state and place the button in the incorrect spot. I was able to get this to happen by changing the device’s orientation and then holding it at an approximate angle of 45 degrees. By changing all of my orientation checking code to [[UIApplication sharedApplication] statusBarOrientation] the problem was solved.
My conclusion: [[UIDevice currentDevice] orientation] it NOT necessarily the same as [[UIApplication sharedApplication] statusBarOrientation]
I hope this helps other people out and saves them some time when coding for their iOS devices.