iPhone developer's Cookbook -- Chapter 1 Introduction

Assembling iPhone Projects

The iPhone Application Skeleton

Here is the most common source code pattern: a main.m file, an application delegate, and a view controller.



XIB files(.xib) are created in Interface Builder. These XML-based user interface definition files are linked to your application and called by your app at runtime in their compiled .nib format.

1. main.m

The main.m file has two jobs:

1. creates a primary autorelease pool for your application.

2. invokes the application event loop

int main(int argc, char *argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, @"MyAppDelegate");
[pool release];
return retVal;
}

The argc and argv variables passed to main() refer to command-line arguments. Since the iPhone does not use a command-line to launch its programs, these elements are not used. They are included for consistency with standard ANSI C practice.

Autorelease Pools

Autorelease pools are objects that support the iPhone's memory management system. The system is normally based on keeping track of reference counts. The pool automatically sends a release message to all the objects it owns at the end of every event loop
cycle so you don't have to.

Autorelease objects are typically created with a pattern that looks like this:

[[[Someclass alloc] init] autorelease]

Once added to the autorelease pool, these objects pass their release responsibilities along to the pool. At the end of the event loop, the pool drains and sends the releases.

The UIApplicationMain Function

The UIApplicationMain function provides the primary entry point for creating a new application object. It creates the new application instance and its delegate.

The third and fourth arguments of the UIApplicationMain function specify the name of the principal application class and its delegate. If the third argument is omitted(set as nil), the iPhone defaults to using the standardUIApplicationclass.

UIApplicationMain also establishes the application's event loop. An event loop repeatedly looks for low-level user interactions such as touches on the screen or sensor triggers. Those events are captured by the iPhone's kernel and dispatch an event queue,
which is forwarded to the application for handling.

2. Application Delegate

An application delegate implements how your program should react at critical points in the application life cycle. Here are the most important delegate methods that your application will implement:

The applicationDidFinishLaunching: method: This method is the first thing triggered in your program after the application object has been instantiated. Upon launch, this is where you create a basic window,
set its contents, and tell it to become the key responder for your application.
The applicationWillTerminate: method: This method enables you to handle any status finalization before handing control back to SpringBoard. Use this to save defaults, update data, and close files.
The applicationDidReceiveMemoryWarning method: When called, your application must free up memory to whatever extent possible. This method works hand in hand with the UIViewController'sdidReceiveMemoryWarning:
method. If your application is unable to release enough memory, the iPhone terminates it, causing your user to crash back toSpringBoard.(Springboard is the main iPhone GUI that presents the application icon,
allowing users to launch programs)
After launching and loading the window, the application delegate takes a back seat. Nearly all application semantics move over to some child of aUIViewControllerclass.

3. View Controller

View controllers provide the heart of how an application runs. Here is where you normally implement how the application responds to selections, button presses, as well as sensor triggers. Here are some of the key methods:

loadView and
viewDidLoad: http://stackoverflow.com/questions/573958/iphone-sdk-what-is-the-difference-between-loadview-and-viewdidload shouldAutorotateToInterfaceOrientation: Unless you have pressing reasons to force your user to remain in prtrain orientation, add the should-autorotate method to allow the UIViewController method to automatically
match your screen to the iPhone's orientation. You must define how the screen elements should update.
viewWillAppear: and
viewDidAppear: These methods get called whenever a view is ready to appear onscreen or a view has fully appeared onscreen.

iPhone Application Components

Compiled iPhone applications live in application bundles. These application bundles are just folders named with a .app extension. 

The Info.plist File

Info.plist files are XML property lists that describe an application to the operating system.

In an Info.plist file, you specify where the application's executable (Executable file) can be found, the text that appears under the application icon(Bundle display name), and the application's unique identifier(Bundle identifier).

The app's display name should not be too long, or it will be truncated.

The application identifier must not duplicate any other identifier on App Store. The identifier is case sensitive and must be consistent with the provisions you generate at the developer portal.

Programming Paradigms

Object-Oriented Programming

Pseudo-multiple inheritance(via invocation forwarding and protocols) provides an important feature of Objective-C's approach to object-oriented programming.

Model-View-Controller

The MVC paradigm on the iPhone breaks down into the following categories:

Model: Model methods supply data through protocols such as data sourcing and meaning by implementing callback methods triggered by the controller.
View: View components are provided by children of the
UIView class and assisted by its associatedUIViewController class.
Controller: The controller behavior is implemented through three key technologies: delegation, target action, and notification.

1. View Classes

The iPhone builds its views based on two important classes:
UIView and UIViewController. These two classes and their descendants are responsible for defining and placing all onscreen elements.

Because of their onscreen nature, all views establish a frame of some sort. This frame is an onscreen rectangle that defines the space each view occupies. The rectangle is established by the view's origin and extent.

Views are arranged hierarchically and are built with trees of subviews. You can display a view by adding it to your main window or to another view by using theaddSubView method to assign a child to a parent.

The UIViewController class does not act as controllers in the MVC sense. They more often act as view handlers and models than as controllers:

UIViewController take responsibility for rotating the display, resize views to fit within the boundaries...
UINavigationController enables you to drill down between views. Navigation controllers remember which views came first and provide a full breadcrumb trail of "back" buttons to return to previous views.
UITabBarController let you easily switch between view controller instances using a tabbed display.

Every UIViewController subclass implements a method to load a view, whether through implementing a proceduralloadView method or by pulling in an already-built interface from a .xib file and callingviewDidLoad.

2. Controller

2.1 Delegation

Many UIKit classes use delegation to hand off responsibility for responding to user interactions. When you set and object's delegate, you tell it to pass along any interaction message and let that delegate take responsibility for them.

2.2 Target-Action

2.3 Notification

3. Model