Apr 02

In light of yesterday’s “announcements” and rumors about the 3G iPhone, it’s good to remind yourself that there will eventually be new iPhones with different properties and capabilities than the current generation.

Developing for the iPhone is great because it’s a single platform. If you have ever tried to adapt a J2ME application for dozens of different phones, you know how painful that is. But don’t take the “single platform” idea too far and assume things like screen size.

Always ask the device about it’s capabilities and dimensions. For example, [[UIScreen mainScreen] bounds] will give you the size of the screen your application can work with. Don’t hardcode 320 x 480 pixels. A good way to test your UI is to allow it to rotate between portrait and landscape mode. If the UI can handle that without breaking or looking distorted, it will probably adapt to other screen sizes as well.

Going back to the 3G example, how would you know if an iPhone is 3G connected to a 3G network? There is nothing specific to 3G in the current API. There is a kSCNetworkReachabilityFlagsIsWWAN flag in SCNetworkReachability which is defined as “EDGE, GPRS, or other cell connection”. That could include 3G. But since there is a significant speed difference between EDGE and 3G it would be nice if Apple added another flag specifically for 3G reachability.

Another possibility is the UIDevice class, and specifically it’s model property. Currently this contains “iPhone” or “iPod Touch”. An “iPhone 3G” model string would make it pretty clear that a phone is 3G capable. But that’s a pretty crude way of describing capabilities. And it puts the onus on each application to map device names to specific capabilities. When you think about all the different iPod models you realize that this will get out of hand pretty quickly.

What we really need is a new capabilities API or framework where an application can query the device for specific information such as screen size, RAM size, network capabilities, etc.

written by Nick \\ tags: , , ,