苹果官方iPhone应用编程指南：权威文档

需积分: 3 142 浏览量更新于2024-08-02 收藏 7.39MB PDF 举报

"《iPhone应用程序编程指南》是苹果公司于2009年1月6日发布的官方开发者文档，由Apple Inc.原创并持有版权。这份指南为想要为iPhone平台开发应用的开发者提供了全面的指导，涵盖了从基础到高级的主题，旨在帮助开发者遵循苹果的开发规范和最佳实践。首先，该指南强调了版权保护，明确指出未经Apple事先书面许可，任何个人或组织不得复制、存储在检索系统中，或者通过任何形式（如机械、电子、影印、录音等）进行传播，除非是出于个人学习目的，且仅限于打印文档副本，同时必须保留Apple的版权声明。苹果的商标，如"Apple logo"和"键盘"图标（Option-Shift-K），在商业用途中使用需得到Apple的书面许可，否则可能构成商标侵权和不公平竞争，触犯联邦和州法律。这意味着开发者在设计和使用应用程序时必须尊重这些知识产权规定。其次，该指南明确指出，虽然提供了技术描述，但这并不意味着授予任何类型的许可，无论是明示还是默示。Apple保留所有与文档中所述技术相关的知识产权，其目的是为了支持和促进应用开发，而不是供商业用途的授权使用。开发者在阅读这份指南时，会了解到如何遵守Objective-C或Swift等编程语言的语法，了解iPhone应用的界面设计原则，以及如何集成各种功能如地图、通知、网络请求、多线程处理等。此外，指南还会涉及安全性和性能优化、适配不同屏幕尺寸和设备特性、以及提交至App Store的流程和要求。《iPhone应用程序编程指南》是开发iOS应用的基础资源，对于确保应用质量和遵循苹果生态系统的要求至关重要。通过深入学习和遵循此文档，开发者可以有效地创建出高质量的iPhone应用程序，并与Apple的生态体系保持同步。"

Figure 1-1 Application life cycle

Your code

User taps application icon

main()

UIApplicationMain()

applicationDidFinishLaunching:

System asks application to terminate

Application execution terminates

Event

Loop

UIKit

Handle event

applicationWillTerminate:

The Main Function

In an iPhone application, the main function is used only minimally. Most of the actual work needed to run

the application is handled by the UIApplicationMain function instead. As a result, when you start a new

application project in Xcode, every project template provides an implementation of the standard main

function like the one in “Handling Critical Application Tasks.” The main routine does only three things: it

creates an autorelease pool, it calls UIApplicationMain, and it releases the autorelease pool. With few

exceptions, you should never have to change the implementation of this function.

Listing 1-1 The main function of an iPhone application

#import <UIKit/UIKit.h>

int main(int argc, char *argv[])

{

NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

int retVal = UIApplicationMain(argc, argv, nil, nil);

[pool release];

return retVal;

}

Core Application Architecture

CHAPTER 1

The Core Application

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

CHAPTER 1

The Core Application

Nib files are disk-based resource files that store a snapshot of one or more objects. The main nib file of an

iPhone application typically contains a window object, the application delegate object, and perhaps one or

more other key objects for managing the window. Loading a nib file reconstitutes the objects in the nib file,

converting each object from its on-disk representation to an actual in-memory version that can be manipulated

by your application. Objects loaded from nib files are no different than the objects you create programmatically.

For user interfaces, however, it is often more convenient to create the objects associated with your user

interface graphically (using the Interface Builder application) and store them in nib files rather than create

them programmatically.

For more information about nib files and their use in iPhone applications, see “Nib Files” (page 28). For

additional information about how to specify your application’s main nib file, see “The Information Property

List” (page 25).

The Event-Handling Cycle

After the UIApplicationMain function initializes the application, it starts the infrastructure needed to

manage the application’s event and drawing cycle, which is depicted in Figure 1-2. As the user interacts with

a device, iPhone OS detects touch events and places them in the application’s event queue. The event-handling

infrastructure of the UIApplication object takes each event off the top of this queue and delivers it to the

object that best suited to handle it. For example, a touch event occurring in a button would be delivered to

the corresponding button object. Events can also be delivered to controller objects and other objects indirectly

responsible for handling touch events in the application.

Figure 1-2 The event and drawing cycle

Operating

system

Event queue

Application

object

Application

Core objects

In the iPhone OS Multi-Touch event model, touch data is encapsulated in a single event object (UIEvent).

To track individual touches, the event object contains touch objects (UITouch), one for each finger that is

touching the screen. As the user places fingers on the screen, moves them around, and finally removes them

from the screen, the system reports the changes for each finger in the corresponding touch object.

Core Application Architecture

CHAPTER 1

The Core Application

When it launches an application, the system creates both a process and a single thread for that application.

This initial thread becomes the application’s main thread and is where the UIApplication object sets up

the main run loop and configures the application’s event-handling code. Figure 1-3 shows the relationship

of the event-handling code to the main run loop. Touch events sent by the system are queued until they can

be processed by the application’s main run loop.

Figure 1-3 Processing events in the main run loop

Main run loop

Event source

event

System

Port

Note: A run loop monitors sources of input for a given thread of execution. When an input source has data

to process, the run loop wakes up the thread and dispatches control to the handler for that input source.

When the handler finishes, control passes back to the run loop, which processes the next event or puts the

thread to sleep if there is nothing more to do. You can install your own input sources, including ports and

timers, on a run loop using the NSRunLoop class of the Foundation framework. For more on NSRunLoop and

run loops in general, see Threading Programming Guide.

The UIApplication object configures the main run loop with an input source that processes touch events

by dispatching them to the appropriate responder objects. A responder object is an object that inherits from

the UIResponder class and that implements one or more methods for processing the different phases of a

touch event. Responder objects in an application include instances of UIApplication, UIWindow, UIView,

and all UIView subclasses. The application typically dispatches events to the UIWindow object representing

the application’s main window. The window object, in turn, forwards the event to its first responder, which

is typically the view object (UIView) on which the touch took place.

In addition to defining the methods you use to handle events, the UIResponder class also defines the

programmatic structure of the responder chain, which is the Cocoa mechanism for cooperative event

handling. The responder chain is a linked series of responder objects in an application, which usually starts

at the first responder. If the first responder object cannot handle the event, it passes it to the next responder

in the chain. The message continues traveling up the chain—toward higher-level responder objects such as

the window, the application, and the application’s delegate—until the event is handled. If the event isn't

handled, it is discarded.

The responder object that handles the event tends to set in motion a series of programmatic actions that

result in the application redrawing all or a portion of its user interface (as well as other possible outcomes,

such as the playing of a sound). For example, a control object (that is, a subclass of UIControl) handles an

event by sending an action message to another object, typically the controller that manages the current set

of active views. While processing the action message, the controller might change the user interface or adjust

the position of views in ways that require some of those views to redraw themselves. When this happens,

the view and graphics infrastructure takes over and processes the required redraw events in the most efficient

manner possible.

Core Application Architecture 19

CHAPTER 1

The Core Application

For more information about events, responders, and how you handle events in your own custom objects,

see “Event Handling” (page 75). For information about how windows and views fit into the event-handling

scheme, see “The View Interaction Model” (page 50). For additional information about the graphics

infrastructure and how views are updated, see “The View Drawing Cycle” (page 85).

Fundamental Design Patterns

The design of the UIKit framework incorporates many of the design patterns found in Cocoa applications in

Mac OS X. Understanding these design patterns is crucial to creating iPhone applications, so it is worth taking

a few moments to learn about them. The following sections provide a brief overview of these design patterns.

Table 1-1 Design patterns used by iPhone applications

DescriptionDesign pattern

The Model-View-Controller (MVC) design pattern is a way of dividing your code

into independent functional areas. The model portion defines your application’s

underlying data engine and is responsible for maintaining the integrity of that

data. The view portion defines the user interface for your application and has no

explicit knowledge of the origin of data displayed in that interface. The controller

portion acts as a bridge between the model and view and facilitates updates

between them.

Model-View-Controller

The delegation design pattern is a way of modifying complex objects without

subclassing them. Instead of subclassing, you use the complex object as is and

put any custom code for modifying the behavior of that object inside a separate

object, which is referred to as the delegate object. At pre-defined times, the

complex object then calls the methods of the delegate object to give it a chance

to run its custom code.

Delegation

Controls use the target-action design pattern to notify your application of user

interactions. When the user interacts with a control in a predefined way (such as

by tapping a button), the control sends a message (the action) to an object you

specify (the target). Upon receiving the action message, the target object can then

respond in an appropriate manner (such as by updating application state in

response to the button push).

Target-action

The Objective-C language uses a reference-counted scheme for determining when

to release objects from memory. When an object is first created, it is given a

reference count of 1. Other objects can then use the retain, release, or

autorelease methods of the object to increase and decrease that reference

count appropriately. When an object’s reference count reaches 0, the Objective-C

runtime calls the object’s cleanup routines and then deallocates it.

Managed memory

model

For a more thorough discussion of these design patterns, see Cocoa Fundamentals Guide.

Core Application Architecture

CHAPTER 1

The Core Application

剩余163页未读，继续阅读

luyuncan

粉丝: 2
资源: 8

苹果官方iPhone应用编程指南：权威文档

iPhoneAppProgrammingGuide.pdf

①-iphone应用程序开发-iPhoneAppProgrammingGuide

Pytorch版代码幻灯片.zip

Jupyter_Chat甄嬛是利用甄嬛传剧本中所有关于甄嬛的台词和语句基于ChatGLM2进行LoRA微调得到的模仿甄.zip

高效甘特图模板下载-精心整理.zip

伯克利大学机器学习-5Dimensionality reduction [Percy Liang]

gapid工具(OpenGL渲染调试器)

全国行政区划shp最新图.zip

全国研究生招生与在校数据+国家线-最新.zip

PyTorch入门教程在线阅读地址.zip

最新资源