What You'll Learn in This Hour:
- Exploring the world of Objective-C
- Getting inside Objective-C objects
- Managing inheritance
- Using delegates and protocols
- Using model/view/controller
Working with the Code
Mac OS and iOS apps are written using the Objective-C language. Right there, some people might panic and throw up their hands, but do not worry. As pointed out previously, you write very little code from scratch. Much of the code that you run is already written for you using Objective-C; that code is in the Cocoa and Cocoa Touch frameworks that support everything from animation to native platform appearance and the Core Data and various table view classes that are the topic of this book. (Cocoa Touch is the version that runs on iOS; unless otherwise noted, references to Cocoa include Cocoa Touch in this book, just as references to iPhone include iPod touch.)
When you're working inside the Cocoa framework and the other components of iOS and Mac OS, most of your work consists of calling existing methods and occasionally overriding them for your own purposes. Xcode 4 provides a new development environment that is heavily graphical in nature. You will find yourself drawing relationships in your data model and, in the interface, drawing connections between objects on the interface and the code that supports them.
Blank pages are rarely part of your development environment.
- This is particularly relevant to declared properties, which are discussed later in this hour in the "Using Declared Properties" section, p. 68.
What You Do Not Have to Worry About
You do not have to worry about designing an entire program in most cases. You are writing code that will be a part built on a template, the behavior of which is known by users, so what you have to do is to fit in. You need to write the code that is specific to your app, but you do not have to worry about implementing an event loop.
In fact, if you decide to develop the app's infrastructure yourself, you might find that users are disappointed at its unfamiliarity and—more important to many people—your app might not find a place in the App Store.
Instead of writing code from scratch, much of what you will do is to investigate the code that you have in the Xcode templates or in Apple's sample code. You need to explore what is written and how it has been designed so that you can understand how and where your functionality will fit in. It is a very different process than writing it from scratch.
Objective-C is built on C; in fact, if you write ordinary C code, you can compile it with an Objective-C compiler (that includes Xcode). The main extension to C that Objective-C provides is its implementation of objects and object-oriented programming.
Today, object-oriented programming rates a big yawn from many people; that is the kind of programming that most people are used to. When Simula 67, the first precursor of Objective-C and all modern object-oriented languages, was developed, this was a new notion, and many people were not certain it was worth the extra effort (not to mention the time it took to learn what then was a new and not fully formed technology). It is against this background that the extensions to C needed to implement Objective-C were created. One of the goals was to prove that very little was needed to be added to C to implement object-oriented programming.
Basically, what was added to C was a messaging and object structure based on Smalltalk. Over the years, additional features such as protocols and delegates as well as categories and blocks were added to the language. Some other features were added. Some of them are not as important to developers writing for iOS or Mac OS X, while others of them simply never caught on with developers at large. Thus, this section provides an overview of the major components that are in use today in the context of iOS and Mac OS X.
At the same time as additional features were being added, the use of the language was refined particularly in the environments of NeXT, Apple, Mac OS X, and iOS. These refinements include conventions such as naming conventions and even code formatting conventions. They are not part of the language itself, but they represent best practices that are followed by the vast majority of Objective-C developers.