With more than 20 years of software development under his belt, Ray Floyd was ready to tackle the next great platform, Apple's iPhone. He'd developed for the Macintosh, although not recently. He was familiar with Objective-C, and he had developed software for other mobile platforms. With a software development kit in hand and up to 75 million potential customers, Floyd couldn't wait to roll out his first iPhone app.

Two months later, he was still waiting, and his enthusiasm had largely changed to exasperation. Why? Because writing native applications for the iPhone platform can be an intimidating process.

For one thing, as Floyd quickly discovered, there is a huge amount of information to digest before you can start coding. The iPhone/iPod Touch/ iPad is a new platform in its own right. These are sophisticated general-purpose, handheld computers. And as a platform, it has its own operating systems, and a host of APIs (some new, some recycled) for programming. Not surprisingly, the documentation on operating systems and APIs spans hundreds of pages.

Even knowing the Mac isn't a free pass. The iPhone operating system is a variant of Mac OS X, but slimmed down to function on a mobile device. As such, a lot of familiar OS X APIs, such as those that manage a keyboard and mouse, are absent. This means that even experienced Mac developers, which Floyd didn't consider himself to be, may not have the features and facilities they're used to having.

The APIs are based on Cocoa, an object-oriented application framework used to write Mac OS X apps. Like the operating system, the Cocoa frameworks have been stripped to the bare essentials for the iPhone OS, and lightweight touch interface APIs added. This minimalist version of Cocoa, termed Cocoa Touch, provides another hurdle.

To use the APIs, you need to learn Objective-C. Objective-C is an object-oriented superset of C, and while it has many valuable features, its idiosyncratic syntax means it'll take a lot more than a cursory study to make sense of code. The language's syntax is quite different from C++, and until you have a grasp of the syntax, example code will appear almost unreadable.

My Journey To iPhone Coding

Like Floyd, I was initially lulled into thinking iPhone development was probably simple for experienced developers. How else could you explain the many thousands of iPhone apps available in Apple's App Store? In fact, many of these apps--and games written in C and C++, in particular--have been ported to the iPhone, where a wrapper based on Objective-C interfaces to the Cocoa Touch frameworks, while the game engine remains written in C and C++. In other words, since the Apple Objective-C compiler accepts C and C++ code, you don't have to start entirely from scratch.

But as I began researching iPhone apps, I grimly realized even my background in writing INITs and FKEYs for the classic Mac OS and J2ME programming for various mobile phones was of little use. The iPhone platform, its OS and APIs, and the peculiarities of Objective-C were radically different. I decided to break the task up to reduce the steepness of the learning curve, hoping to find a magic bullet along the way that would streamline development.

First, what should my first app do? I wanted a specific project so I could focus on a subset of APIs and not become overwhelmed by the big picture. I settled on porting the SpaceActivity app I had written for the Android platform some time ago (see "The Android Mobile Phone Platform," at drdobbs.com/ 1261/ddj/android). The app displayed a spaceship you steered with handset buttons.

That iPhone APIs would be utterly different from Android's was a given. I'd have to learn how to draw the ship on the iPhone's screen, then figure out how to implement controls for it. I hoped that SpaceActivity's "core code"--that is, the physics routine that calculated the ship's velocity in response to rocket thrusts, plotted its position, and kept the image on screen--could be reused. This code was debugged and tested, and it had the virtue of using a minimum of API calls. It also had ready-to-use images of the spaceship with a transparent background, so I didn't have to design any new graphics. Finally, it would also be an interesting test of porting Android code.

View To The Rescue

Floyd might have preserved a lot of his enthusiasm if he'd stumbled upon a particular Cocoa Touch class at the start of his iPhone app-building enterprise. Luckily, I did. While it wasn't quite a magic bullet, I eventually figured out that the key to drawing to the iPhone's screen is Cocoa Touch's View class.

Views are how the iPhone OS displays information and handles user actions--the cornerstone of an iPhone app's design and the logical class to start with. Until you master this class, there's not much sense in learning other APIs. The rookie iPhone programmer should focus on understanding View.

Views are rectangular regions that draw their contents to the display. The content can be vector graphics, pixel images, HTML, and OpenGL ES graphics. Points on the view are specified using floating-point numbers for device-independent resolution. Views can be layered atop one another, and this order can be rearranged with the appropriate methods. Views can also be nested in other views to assemble sophisticated user interface elements. In fact, an iPhone app's entire interface consists of views nested within one master view, termed the "window view." The View class has a number of child classes that define visual controls such as buttons and sliders, while others manage the display of content, or implement navigation elements that guide a user among the various screens that make up the app.

A view has properties than can be used to specify its alpha channel (transparency) and determine if it's visible or not. Another property applies a transformation matrix to the view so that it can be rotated or other special effects applied. Another specifies the center point of the view, which is valuable for games where views become objects that are moved about the screen.

Views receive touch events from the main window object. You can use these to determine if the user touched a particular view or moved his finger across the screen, possibly making a gesture. Brief touches are considered taps and can be counted. For example, the sample code provided with the online version of this article (informationweek.com/ 1261/ddj/iphone) resets the app if the screen is tapped twice. The sample app also shows how a view can display a virtual joystick or control pad, and translate touches on it into commands that affect the app's operation. The core code that calculates the ship's position, velocity, and bearing is the Java code that I lifted from the Android program.

4 iPhone Tools

Special roles in app's UI
for these views

1. Status Bar
Shows important information, including cell signal strength and battery charge 2. Navigation Bar
Includes titles, buttons, and segmented controls 3. Tab Bar
Contains segments that activate different application modes 4. Tool Bar
Includes controls that perform specific actions in the current context of the application

Views can be created programmatically or by loading instances of the view, and other class objects, from a NextStep Interface Builder (nib) file. Nib files store condensed information about a view such as its size, location on the screen, color, its properties, and references to any images it might display. You use an Interface Builder application to lay the view's elements out graphically and define their properties before storing it in a nib file.

When the app loads the nib file, the views within it are reconstituted into instances of the objects. Nib files are useful for storing views that display static data, such as a help screen or backdrop image. Views that change their position, shape, alpha channel, visibility, and other characteristics are often better implemented using program code.

Once past the iPhone operating system's steep learning curve, you'll discover how much punch the iPhone platform packs. Cocoa Touch has the flexibility and features to write a responsive and attractive app with a small amount of code. If all else fails, you can use certain BSD calls--since, at heart, the iPhone OS uses Unix--to support some capabilities, such as storing data. Best of all, you can reuse proven C and C++ code taken from another platform--as long as it doesn't use numerous platform-specific calls or rely on characteristics of the original platform.

iPhone development can start off feeling overwhelming, especially for developers who are unfamiliar with Objective-C and Cocoa Touch. Fortunately, powerful features such as the View class help make the leap from coding to deployment. But unfortunately, the information on Views is buried deep in the documentation.

Tom Thompson is an experienced developer for multiple mobile platforms.

Write to us at [email protected].