Anatomy of an iPhone Application Content taken from book: “iPhone SDK Development” by Bill Dudney and Chris Adamson

Cocoa classes Cocoa’s Foundation framework includes essential data classes, includes basic utilities, and establishes some core programming conventions that cannot be expressed by the Objective-C language alone Nearly all Cocoa classes inherit from a root class, NSObject, defined in Foundation. NSString

Collection classes Three classes are used for collecting Cocoa objects: NSArray for ordered collections of objects, NSSet for unordered collections, NSDictionary for mapping key objects to value objects. – These three collections are immutable—once initialized, they can’t be changed.

Mutable subclasses NSMutableArray, NSMutableSet, and NSMutable-Dictionary. – The collections can store only NSObjects. If you have C primitives, you can pass them around Cocoa with the wrapper classes NSData and NSMutableData, which wrap a byte buffer, and NSNumber, an object container for any of C’s scalar (numeric) types, such as int, float, or bool.

Other specific data classes NSURL for URLs NSDate and NSTimeZone

Cocoa Touch The “Touch” part of Cocoa Touch is largely represented by the UIKit framework, also imported by default in every iPhone application. This framework offers the drawing model, event handling, application life cycle, and other essentials for a touch-based application. Some user interface component classes: UIButton, UITextView, UITableView, etc.

Parts of a Project Classes—Class files are the C and Objective-C source that you create to provide the functionality of your application. Other sources—These are source files that are generated automatically and that you are largely not responsible for or interested in. – precompiled headers file – main.m is the implementation of the main( ) function that the system calls to launch your application. – third-party library source here or procedural-C sources (.c files) that aren’t “classes”

Other parts of a Project Resources—Resources are noncode files that are nevertheless needed by your application at runtime. – Such files might include graphics or sound files, and localization dictionaries. Frameworks—These represent the frameworks that your application uses. – By default, the Xcode template links in the frameworks Core Graphics and UIKit so you’ll be able to call the various GUI classes, and Foundation for commonly used classes such as strings, collections, and URLs. Products—This folder represents the files that will be created by the build process, in this case the Hello.app iPhone application.

XCode Xcode is really the base for your application project. Although you’ll use other applications to set up the GUI elements in the nib (Interface Builder), create images (any graphics application such as Photoshop or Pixelmator), and measure performance (Instruments), the job of managing all the pieces of the application and building it falls to Xcode.

IBOutlets and IBActions A reference from code to an object in the nib is called an outlet and is designated with the keyword IBOutlet. A method that you want a nib’s objects to be able to call is an action and is designated with the keyword IBAction.

HelloUserViewController.h This code declares two outlets and one action. – (IBAction) is equivalent to (void) in that it returns no value, but using the IBAction keyword indicates our intent to connect the method to GUI events via Interface Builder

Laying Out Your Interface in IB In Xcode’s project window, double-click helloUserViewController.xib to open it with IB. From the library, drag over three objects: a label, a text field, and a button.

Customize three components as follows:

Identifying Outlets and Actions

Implementing the Action HelloUserViewController.m

Build Application

Previous in Class Assignment AddingViewController.h AddingViewController.m