Objective-C, Foundation Framework, Cocoa Touch, and UIKit
Apple describes the iPhone’s technology as layers. The base layer is the Core OS layer. On top of that layer is the Core Services. On top of the Core Services is the Media layer. The topmost layer is Cocoa Touch.
You can simplify the iPhone operating system (OS) even more; think of it as two layers—a C layer and a Cocoa layer. The C layer comprises the operating system’s layer. You use BSD UNIX–style C functions to manipulate this layer. This layer consists of things like low-level file I/O, network sockets, POSIX threads, and SQLite. The Media layer is also rather low-level and contains C application programming interfaces (APIs) like OpenGL ES, Quartz, and Core Audio. The Cocoa layer overlays the C layer, and it simplifies iPhone programming. For instance, rather than manipulating C strings, you use the Foundation framework string, NSString.
Cocoa Touch
On the iPhone, Cocoa is called Cocoa Touch, because the iPhone OS contains touch events. If you have ever tapped, flicked, swiped, or pinched your iPhone’s display, you know what touch events are. Touch events allow you to program responses to a user’s touching the screen with his or her fingers.
Cocoa Touch also provides the primary class libraries needed for iPhone development. The two Cocoa Touch frameworks you will use in every iPhone application you write are the Foundation framework and the UIKit framework. A framework is a collection of code devoted to a similar task. The Foundation framework is dedicated to standard programming topics, such as collections, strings, file I/O, and other basic tasks. The UIKit is dedicated to the iPhone’s interface and contains classes such as the UIView. In this book, you spend most your time learning the UIKit.
Foundation Framework
The Foundation framework contains Objective-C classes that wrap lower-level core functionality. For instance, rather than working with low-level C file I/O, you can work with the NSFileManager foundation class. The Foundation framework provides many useful classes that you really should learn if you wish to program robust iPhone applications. The Foundation framework makes programming using collections, dates and time, binary data, URLs, threads, sockets, and most other lower-level C functionality easier by wrapping the C functions with higher-level Objective-C classes.
Tip: See Apple’s Foundation Framework Reference for a complete listing of the classes and protocols provided by the Foundation framework.
Note: If you are a Java programmer, think of the iPhone’s programming environment like this: Objective-C is equivalent to Java’s core syntax. The Foundation framework is equivalent to Java’s core classes, such as ArrayList, Exception, HashMap, String, Thread, and other Java Standard Edition classes, and the UIKit is the equivalent of SWING. I realize it’s a simplification, but it works for me.
The iPhone Frameworks
This book dedicates itself to the UIKit rather than trying to cover a little bit of every framework.
It is this book’s premise that once you understand how to create an iPhone application using the UIKit classes, you should learn the other frameworks.
iPhone limitations
If you have never programmed for a small device like an iPhone, there are some limitations you should be aware of before you begin programming. Memory and processor speed are constrained, and the screen is small. Security is also tight on an iPhone,and applications are limited in what they can do.
Limited memory and processor speed
Chances are you have a Mac or a PC with a dual-core processor and 2GB of memory. Note that if you own a PC, if you wish to develop iPhone apps, you must buy a Mac. Although Apple hasn’t divulged this information, hacker Craig Hockenberry (furborg.org) has estimated that an iPhone has about a 600 MHz processing speed with 128MB of available physical memory. The memory of the device is limited compared to your desktop.
Caution: If your application uses too much memory, the iPhone OS X may abruptly terminate your application to prevent a system crash.
Small screen
The iPhone’s 3.5-inch screen has a 480x320 pixel resolution—not much room to work with. Of course, controls such as buttons are smaller on an iPhone, but the layout space is still significantly constrained. If you are accustomed to programming user interfaces on a 1280 × 800 pixel display, you must adjust your thinking.
The small screen size also results in only one window being visible at a time. In fact, every application you develop in this book consists of one window. There will rarely be any reason to create another window when programming an iPhone application. Instead, what you do is swap views into and out of an application’s window. But only one view is visible at a time—no exceptions.
“Sandbox” security
You can only read or write to directories that are part of your application’s bundle. Areas accessible to your application are said to be in your application’s “sandbox.” You cannot read files created by other applications. You also cannot write to anywhere outside your application’s sandbox. Applications written by SDK users cannot share resources; period!
No memory-resident apps
Memory-resident applications have the ability to run in the background while a user runs other applications. Unfortunately, these cannot be memory-resident. An iPhone can only have one program running at a time. This means that your application is in constant danger of being terminated by the OS when another app is launched. For example, a phone call might arrive while your application is running. In this situation, the OS asks a user if he or she wishes answering the call. If the user chooses to answer the call, the iPhone OS terminates your application.
Because of this constant probability of sudden termination, you should program defensively and anticipate abrupt terminations. You will see that the UIKit makes this easy by providing event handlers you can implement whenever your application is about to terminate.
NOTE: Before you rail against this limitation, consider the alternative. Suppose you develop a long-running and power-hungry application that is memory-resident. Users of your application will notice a shorter battery life for their iPhone and complain about it. And who will they blame? Apple, of course.
Manual memory management
One of the big improvements in Objective-C 2.0 is “garbage collection.” This feature frees developers from having to worry about memory management, as the system does so automatically. Unfortunately, the iPhone, with its limited resources, does not include Objective-C 2.0 garbage collection. Developers must manage memory themselves. You can use something called “autorelease,” which makes memory management a little easier, but even this is not recommended. Instead, you should manage memory manually. Although not a huge limitation, it can be a pain because forgetting to release an object is a mistake that is all too easy to make. (Chapter 5 of SDK Programming: A Beginner’s Guide provides tools to help you track down and fix this and other errors.)
Relevant documentation
Apple has a considerable amount of online documentation. You have access to that documentation through both your Developer Connection membership and through Xcode’s help. Most of the documentation is also available in PDF format. The first two documents you should download and print out are the “iPhone Application Programming Guide” and the “iPhone Development Guide.” You might then consider downloading and printing out the “Cocoa Fundamentals Guide.” You will also find documents on Objective-C and various Cocoa classes. The book this article was excerpted from tries not to duplicate these online and desktop sources, but rather complement them by providing step-by-step examples illustrating how to do things. Once you understand how, the online documentation shows you more options to expand upon this book’s tutorial.
Getting a quick start on iPhone development
As mentioned, this article was excerpted from Chapter 1 of SDK Programming: A Beginner’s Guide. The next four chapters cover prerequisite tools and skills that you should have prior to learning the iPhone’s UIKit and Cocoa Touch. But by this point in the book, you will probably be ready to start programming using the frameworks already discussed. Chapter 1 ends with a quick-start example of a simple iPhone app to whet your appetite. This quick-start will also familiarize you with the IBOutlet and IBAction keywords and their use, as well as Xcode and Interface Builder.
Getting started building your own Apps using the SDK is easier than you might realize. To help you get started, Chapter 1 of this book is available as a PDF download at the author’s website. Chapter 1 has a step-by-step tutorial that helps you get a “quick start” to developing iPhone Apps. The chapter’s tutorial also has a comprehensive accompanying video tutorial at the author’s Vimeo site. Even if you do not buy the book, there are lots of helpful beginner tutorials to get you started.
