Note: An autorelease pool is used in memory management. It is a Cocoa mechanism used to defer the
release of objects created during a functional block of code. For more information about autorelease pools,
see Memory Management Programming Guide for Cocoa. For specific memory-management guidelines related
to autorelease pools in iPhone applications, see “Allocating Memory Wisely” (page 41).
The UIApplicationMain function at the heart of the preceding listing takes four parameters and uses them
to initialize the application. Although you should never have to change the default values passed into this
function, it is worth explaining their purpose in terms of starting the application. In addition to the argc and
argv parameters passed into main, this function takes two string parameters that identify the principal class
(that is, the class of the application object) and the class of the application delegate. If the value of the
principal class string is nil, UIKit uses the UIApplication class by default. If the value of the application
delegate’s class is nil, UIKit assumes that the application delegate is one of the objects loaded from your
application’s main nib file (which is the case for applications built using the Xcode templates). Setting either
of these parameters to a non-nil value causes the UIApplicationMain function to create an instance of
the corresponding class during application startup and use it for the indicated purpose. Thus, if your application
uses a custom subclass of UIApplication (which is not recommended, but certainly possible), you would
specify your custom class name in the third parameter.
The Application Delegate
Monitoring the high-level behavior of your application is the responsibility of the application delegate object,
which is a custom object that you provide. Delegation is a mechanism used to avoid subclassing complex
UIKit objects, such as the default UIApplication object. Instead of subclassing and overriding methods,
you use the complex object unmodified and put your custom code inside the delegate object. As interesting
events occur, the complex object sends messages to your delegate object. You can use these “hooks” to
execute your custom code and implement the behavior you need.
Important: The delegate design pattern is intended to save you time and effort when creating applications
and is therefore a very important pattern to understand. For an overview of the key design patterns used by
iPhone applications, see “Fundamental Design Patterns” (page 20). For a more detailed description of
delegation and other UIKit design patterns, see Cocoa Fundamentals Guide.
The application delegate object is responsible for handling several critical system messages and must be
present in every iPhone application. The object can be an instance of any class you like, as long as it adopts
the UIApplicationDelegate protocol. The methods of this protocol define the hooks into the application
life cycle and are your way of implementing custom behavior. Although you are not required to implement
all of the methods, every application delegate should implement the methods described in “Handling Critical
Application Tasks” (page 29).
For additional information about the methods of the UIApplicationDelegate protocol, see
UIApplicationDelegate Protocol Reference.
The Main Nib File
Another task that occurs at initialization time is the loading of the application’s main nib file. If the application’s
information property list (Info.plist) file contains the NSMainNibFile key, the UIApplication object
loads the nib file specified by that key as part of its initialization process. The main nib file is the only nib file
that is loaded for you automatically; however, you can load additional nib files later as needed.
Core Application Architecture 17
2009-01-06 | © 2009 Apple Inc. All Rights Reserved.
CHAPTER 1
The Core Application
我的内容管理
展开
