Apple’s iOS SDK provides you with a vast library of objects arranged into several frameworks. As a result, you’ll spend a lot more time sending messages to objects that are ready-made for your use than creating new ones. Let’s begin our look at iOS by exploring several of these objects and how they’re arranged. We’ll take a tour of the anatomy of iOS, at how the object hierarchy is arranged, and how iOS handles windows and views.
The anatomy of iOS
iOS’s frameworks are divided into four major layers, as shown in figure 1.4.
Figure 1.4 Apple provides you with four layers of frameworks to use when writing iOS programs.
Each of these layers contains a variety of frameworks that you can access when writing iOS SDK programs. Generally, you should prefer the higher-level layers when you’re coding (those shown toward the top in the diagram).
Cocoa Touch is the framework that you’ll become most familiar with. It contains the UIKit framework—which is what we spend most of our time on in this topic—and the Address Book UI framework. UIKit includes window support, event support, and user-interface management, and it lets you display both text and web pages. It further acts as your interface to the accelerometers, the camera, the photo library, and device-specific information.
Media is where you can get access to the major audio and video protocols built into the iPhone and iPad. Its four graphical technologies are OpenGL ES, EAGL (which connects OpenGL to your native window objects), Quartz (which is Apple’s vector-based drawing engine), and Core Animation (which is also built on Quartz). Other frameworks of note include Core Audio, Open Audio Library, and Media Player.
Core Services offers the frameworks used in all applications. Many of them are data related, such as the internal Address Book framework. Core Services also contains the critical Foundation framework, which includes the core definitions of Apple’s object-oriented data types, such as its arrays and sets.
Core OS includes kernel-level software. You can access threading, files, networking, other low-level I/O, and memory functions.
Most of your programming work will be done using the UIKit (UI) or Foundation (NS) framework. These libraries are collectively called Cocoa Touch; they’re built on Apple’s modern Cocoa framework, which is almost entirely object oriented and, in our opinion, much easier to use than older libraries. The vast majority of code in this topic will be built solely using Cocoa Touch.
But you’ll sometimes have to fall back on libraries that are instead based on simple C functionality. Examples include Apple’s Quartz 2D and Address Book frameworks, as well as third-party libraries like SQLite. Expect object creation, memory management, and even variable creation to work differently for these non-Cocoa libraries.
When you fall back on non-Cocoa libraries, you’ll sometimes have to use Apple’s Core Foundation framework, which lies below Cocoa. Your first encounter with Core Foundation will be when we discuss the Address Book framework in topic 9; we’ll provide more details about how to use Core Foundation at that point.
Although Core Foundation and Cocoa are distinct classes of frameworks, many of their common variable types are toll-free bridged, which means they can be used interchangeably as long as you cast them. For example, CFStringRef and NSString * are toll-free bridged, as you’ll see when we talk about the Address Book. The Apple class references usually point out this toll-free bridging for you.
The object hierarchy of iOS
Within these frameworks, you can access an immense wealth of classes arranged in a huge hierarchy. You’ll see many of these used throughout this topic.Figure 1.5 shows many of the classes that you’ll use over the next several topics, arranged in a hierarchy. They’re a fraction of what’s available.
THE NS CLASSES
The NS classes come from Core Services’ Foundation framework (the Cocoa equivalent of the Core Foundation framework), which contains a huge number of fundamental data types and other objects.
You should use the fundamental Cocoa classes like NSString and NSArray whenever you can, rather than C fundamentals like char* or a plain array. This is because they tend to play nicely with each other and with the UIKit frameworks, and therefore you’re less likely to encounter bizarre errors. They also follow the memory-management rules of Objective-C (reference counting). Although it isn’t shown, NSNumber is another class you should be aware of. Although it shouldn’t be used in place of an ordinary number, it serves as a great wrapper when you need a number expressed as an object. This is useful for sending numbers via message passing. NSNumber is capable of holding many sorts of numerical values, from floats to integers and more.
Figure 1.5 This hierarchy graph shows a small selection of the classes available in iOS.
The objects that can hold collections of values like NSArray (a numerical array) and NSDictionary (an associative array) are picky about your sticking to their NS brethren. You’ll need to wrap C variables inside Cocoa classes whenever you hand off objects to these arrays. Finally, though NSString can take many sorts of objects when you’re formatting a string, you should be aware that Cocoa objects may require a different formatting string than their C equivalents.
In two situations, you’ll find that these NS classes can be a deficit. First, if you’re using the Core Foundation framework, you’ll often have to take advantage of toll-free bridging by casting variables, as you’ll see starting in topic 9, when we look at the Address Book. Second, if you’re using external APIs, you may need to convert some classes into their C equivalents. Topic 9′s look at the SQLite API explores this possibility, with NSString objects often being converted to their UTF-8 equivalent.
The most important of Cocoa’s Foundation objects is NSObject, which contains a lot of default behavior, including methods for object creation and memory management; you’ll learn about these later in this topic.
THE UI CLASSES
The second broad category contains the UI classes. These come from Cocoa Touch’s UIKit framework, which includes all the graphical objects you’ll be using as well as all the functionality for the iOS’s event model, much of which appears in UIResponder. That’s another topic we’ll return to soon.
Windows and views
As the UI classes demonstrate, iOS is deeply rooted in the idea of a graphical user interface. Therefore, let’s finish our introduction to iOS by looking at some of the main graphical abstractions embedded in the UIKit. There are three major abstractions: windows, views, and view controllers.
A window is something that spans the device’s entire screen. An application usually has only one, and it’s the overall container for everything your application does.
A view is the content holder in your application. You may have several of them, each covering different parts of the window or doing different things at different times. They’re all derived from the UIView class. But don’t think of a view as a blank container. Almost any object you use from UIKit will be a subclass of UIView that features a lot of behavior of its own. Among the major subclasses of UIView are UIControl, which gives you buttons, sliders, and other items with which users may manipulate your program, and UIScrollableView, which gives users access to more text than can appear at once.
A view controller does what its name suggests. It acts as the controller element of the Model-View-Controller triad and in the process manages a view, sometimes called an application view. As such, it takes care of events and updating for your view.
In this topic, we’ve divided view controllers into two types. Basic view controllers manage a screenful of information (such as the table view controller), whereas advanced view controllers let a user move around among several subviews (such as the navigation bar controller and the tab bar controller).
Windows, views, and view controllers are ultimately part of a view hierarchy. This is a tree of objects that begins with the window at its root. A simple program may have a window with a view under it. Most programs start with a window and have a view controller under that, perhaps supported by additional view controllers, each of which controls views that may have their own subviews. We’ll illustrate this concept more clearly in topic 5 when we start looking at the basic view controllers that make this sort of hierarchy possible.
