Learning the iOS 4 SDK for JavaScript Programmers

Frameworks

One way Apple keeps the thousands of APIs straight is to organize them into groups known as frameworks. You may recognize the term from your exposure to JavaScript libraries such as Dojo, jQuery, and YUI. Although there are differences between libraries and frameworks (a subject beyond the scope of this book, and usually generating programming-religious discussions), they both provide APIs that facilitate programming-specific tasks. Frameworks targeting iOS web app development include iUI and a jQuery plug-in called jQTouch. The iUI framework consists of CSS and JavaScript files you link into a web page. The JavaScript objects and functions in the .js file are immediately available within the scope of the current document window. For example, the iUI framework performs much of the heavy lifting in turning an HTML unordered list into a page that resembles the typical iPhone vertically scrollable table view; a tap on an item (via a touch event) causes what looks like a detail view to slide in from the right side.

You can see the three basic frameworks that are common to virtually every iOS app created with the SDK. Open the Workbench project in Xcode and expand the Frameworks folder in the Files and Groups panel on the left. There you will see entries for the Foundation, UIKit, and CoreGraphics frameworks (Figure 4-1).

Figure 4-1. Three basic iOS SDK frameworks

You don’t truly have to know what’s inside each of these three frameworks, but having an overview of them from 35,000 feet will help you understand how the iOS SDK organizes its various powers. You are welcome to expand any of the framework items, but the long lists of header files might make your head explode until you progress further into this chapter. With that, let’s do a quick framework survey.

Foundation Framework

The Foundation framework reveals how much iOS has in common with Mac OS X. Both environments use the same Foundation framework, although the iOS version trims off many items that don’t apply or aren’t yet supported. Definitions in this framework include the basics: strings, various types of data collections, dates, timers, fetching data from the network through URLs, and even XML parsing (although not in a DOM-friendly manner). The Foundation framework is all about manipulating data, and not displaying it. In that sense, you might equate this framework with the core JavaScript language, which is designed for use in all kinds of environments, including those outside of web browsers.

UIKit Framework

As its name implies, the UIKit framework is all about user interface elements—specifically, iOS kinds of user interface elements. This is where the SDK lets you create and manipulate buttons, images, scrolling thingies, text boxes, various bars, alert dialog windows, and those neat looking slot-machine-style picker controls. Most of the time you will use Interface Builder to lay out user interface elements for a screen, but under the hood, the SDK ultimately relies on the UIKit framework definitions for those elements to figure out how to draw them when the app runs. If the Foundation framework is like the core JavaScript language API, the UIKit framework is like the DOM API, including the JavaScript style property to control very specifically how things on the screen appear (colors, sizes, etc.).

CoreGraphics Framework

Unlike the Objective-C-based Foundation and UIKit frameworks, the CoreGraphics framework uses the C language in all of its definitions. This is one reason you need to be familiar with basic C syntax when doing iOS SDK programming. The CoreGraphics framework focuses on 2-D drawing activities, such as when you need to fill a space with a gradient or rotate a user interface control (e.g., creating a vertical slider control).

Adding Frameworks

The above descriptions are brief, to be sure, but you’ll recognize that I make no mention of some of the specialized capabilities of iOS apps, such as location services, maps, or playing audio. That’s because APIs for those capabilities are contained in other frameworks that are not part of the default set that Xcode automatically puts into a view-based application. If you want to get an idea of the other frameworks available to you, Control-click the Frameworks group and follow the submenus to Add→Existing Frameworks, as shown in Figure 4-2.

Figure 4-2. Control-click the Frameworks group

In the resulting dialog box, choose Frameworks from the top menu to limit the list to available frameworks, as shown in Figure 4-3. You can see the range of subject matter covered by Apple’s documented frameworks. Don’t add anything to the Workbench project now. In Appendix A, you’ll learn how to use the SDK documentation to determine which framework to add to your project for a particular feature you want to add to your app.

Figure 4-3. List of existing frameworks

Frameworks Set in Stone

You may be accustomed to inspecting and even modifying the source code in JavaScript libraries that come in various web browser scripting frameworks. That’s one significant difference between a JavaScript library and an iOS SDK framework. The source code that does the work of the iOS APIs is hidden away. At best, you can see lists of the API calls available within a framework, but not how those frameworks actually do their work. That also means that you cannot alter the frameworks directly. That’s a good thing: given the complexity of iOS, such willy-nilly modifications could spell trouble for your app, because you never know when your code or another API relies on a mint-condition API call. Instead, Objective-C provides you with multiple ways to add to the existing functionality of an API that your program can use at will. (See Chapter 8).

Now that you’ve explored the Frameworks group in Xcode, it’s time to head back up to the Class Files group in the Workbench project. This is where you will spend most of your coding time.