Learning the iOS 4 SDK for JavaScript Programmers

Chapter 4. Structural Overview of an iOS App

Now that we have a working iOS app, we can look more closely at many of the details in the source code for that app and the project. Xcode will again be your gateway to the inner workings. Although the title of this chapter doesn’t mention object-oriented programming (OOP), this chapter is where you will learn the fundamentals—especially the terminology, which is often quite different from what you’ve seen in the JavaScript world. Despite the differences in naming, you will recognize some familiar concepts.

Where It All Begins: APIs

An application programming interface, or API, is essentially a list of entities you can program and what you can ask those entities to do in a program. Designers of computers and software systems can choose to expose the inner workings of those devices and programs to third-party programmers. APIs typically shield the third-party programmer from the complex inner workings of the systems and provide him with simpler, optimized, and well-tested ways to control those systems.

APIs You Already Know

As a client-side scripter, you have already worked with a number of APIs, even if the three-letter term wasn’t forced upon you. The API most obvious to you should be the DOM, which exposes every type of HTML element as an object you can script. The authors of the W3C DOM write specifications about how objects are named, what their properties and methods are, and how objects are to behave under script control. The initial audience for these standards is browser makers who implement the standards and provide the APIs that you access via JavaScript.

APIs for current programming environments rarely stand still. That has certainly been the case in the browser API world. The evolving HTML5 standard includes an API for new HTML elements that facilitate embedding audio and video into a web page, as well as other APIs for offline web applications and dynamically editable content. A browser maker can also elect to add APIs, which is what Apple has done with Mobile Safari to enable limited access to iOS location services through a web page’s scripts.

The JavaScript language provides its own APIs for the core language. The way your scripts work with strings, numbers, dates, regular expressions, and operations through the Math object are all part of that API. All of those properties and methods you see in reference guides are there to provide you with easy access to what would otherwise be very complex, low-level programming.

The Cocoa Touch APIs

To allow developers to write apps for the iPhone and similar devices, Apple’s engineers created a set of APIs. The historical basis for the iOS APIs was the set of Mac OS X development APIs. On the Mac, the most recent set of APIs is known as Cocoa (whose technological heritage, in turn, originated with the NeXTSTEP development environment). Although the name Cocoa was originally associated with a children’s multimedia creation environment (by Apple), the name eventually shifted to the Mac OS X development world, where it has remained.

Because so many fundamentals of iOS are based on Mac OS X but implemented for purely touch-based devices, it was logical enough to call the iOS APIs Cocoa Touch. That’s not to say Cocoa Touch is merely Cocoa with the addition of some touchscreen events. Cocoa Touch omits many Cocoa technologies that aren’t necessary for a slimmed-down device (compared to a desktop or laptop computer) and adds gobs of technologies that Mac OS X computers may never acquire—you’re not likely to rotate your MacBook display to portrait mode or demand turn-by-turn directions from an iMac.

Cocoa Touch APIs consist of specifications for objects and built-in functions that programmers can use while developing apps for iOS devices. Just as the JavaScript API in browsers supplies scriptable access to strings, numbers, and dates, the Cocoa Touch API provides Objective-C access to those same kinds of data. And, just as the DOM API in browsers specifies how JavaScript can access and control document objects, such as forms, arbitrary divs, or images, the Cocoa Touch API lets programmers access and control buttons, images, and scrollable regions within a view.

But of course, the Cocoa Touch APIs grant lots of OS-specific access to features such as the device’s geographical location, the music library in the built-in iPod app, and those ubiquitous scrolling lists of items. With each new generation of iOS, Apple adds more APIs. For example, at the announcement of the iOS 4.0, Apple claimed to have added over 1,500 methods to the SDK, including access to a user’s calendar data and files in the photo library and the ability to build SMS messaging into apps. For iOS 4.2, Apple added scores of APIs, including a MIDI controller and wireless printing facilities.

The job of an iOS SDK programmer, therefore, is to use the Objective-C language to manipulate data (text, graphics, sounds, etc.) with the help of the APIs built into the operating system. You’ll still need good ideas about the data and how best to integrate that data into the device, but learning the broad spectrum of APIs available to you is a very important part of the learning process.

Public Versus Private APIs

If you read the fine print of your iOS SDK license agreement, you find the provision that your apps may use only “Documented APIs,” which Apple defines as the APIs it reveals via its developer documentation in the SDK. Those are not the only APIs in iOS, but they’re the only ones that you, as a registered developer, can use if you plan to distribute your app through the App Store.

Apple’s explanation for this distinction between public and private APIs is that undocumented, private APIs are generally not yet finalized—not ready for prime time, as it were. The burden of documenting an API is that developers will use it, and it becomes nearly impossible to change that API in the future because it would break all existing apps that use the API. Additionally, there are APIs in the OS that Apple will likely never document because developers could abuse the privileges, much to the dismay of users (e.g., automatically making phone calls) or cell phone service providers (e.g., downloading movie-length HD video over a 3G connection).

Being limited to documented APIs might be frustrating at times, especially if you see Apple’s own apps performing tasks that your apps cannot. In the meantime, there are enough APIs ahead of you on your learning curve to keep you plenty busy.