UIPopoverController and iOS4
June 30th, 2010Ran into this today, I wanted to put an image picker onscreen. Sounds easy, lots of examples out there, but the problem is that they do not seem to work on Universal apps.
According the Apple docs for the iPhone/iPod, one creates an UIImagePickerController. The code sample for that work great on the iPhone/iPod. When I tried to run it under the simulator for the iPad, it crashes with this message: “On iPad, UIImagePickerController must be presented via UIPopoverController”. Kind of odd, I would think that the API designer would have made it so that it would just work on the new devices, but they failed to make it so. Digging around in the Apple docs, which is the largest part of my development day, since the APIs for the iPhone are… well, too complicated to get stuff do with.
Anyway, I found the iPad dev docs, which showed how to do this on the iPad: one queries to see if the class exists like this,
Class popoverClass = NSClassFromString(@”UIPopoverController”);
if popoverClass is not nil, then go for it. That seems to work on the iPad. But now iOS4 is out, so I decide to give the code a try - it crashed with this error: “-[UIPopoverController initWithContentViewController:] called when not running under UIUserInterfaceIdiomPad.”
So, to create a Universal iPad, iPhone, iPod, iOS4 app, query the interface is no longer good enough, since the new methods exist under iOS4, they just crash. Searching online for others with the same API problems, which is how I spend the rest of my day usually, I found that one also has to check if it is running on an iPad as well.
Summary: with the latest APIs, you have to know if the class exists, whether the method under the class exists, and which device you are running on, before you call any API. Since they can change any existing API to suddenly crash on a new device, how can one write code that is future-proof? I haven’t figured it out within Apple’s API design philosophy. Stuff that could easily be hidden or made to work as default, but allow for overriding if the programmer wants more control, seems to be a foreign concept at Apple. Code that would work fine and be 100% correct for the iPhone/iPod will just fail on the iPod - not sure I understand their thinking on this.
Edward
PS By the way, the problem with adding the “is iPad” check to the exist code is that it now leaves open the door for Apple to release a device that isn’t an iPad, but requires the UIPopoverController in order to access the UIImagePickerController. I have found no way in the docs or in searching online to write a simple program to display the picker that will work on current and future devices. Ideas?