苹果官方iPhone应用编程指南

5星 · 超过95%的资源需积分: 3 73 浏览量更新于2025-01-03 收藏 7.39MB PDF 举报

"这是一本关于iPhone应用编程的指南，适合初学者，旨在提供简单易懂的iPhone开发知识。本书由Apple Inc.于2009年发布，内容涵盖iPhone应用开发的基础到进阶知识。" 该PDF文档是苹果公司官方出版的《iPhone Application Programming Guide》，适用于对iOS开发感兴趣的个人或开发者。它主要介绍了如何开发适用于iPhone的应用程序，内容可能包括但不限于以下关键知识点： 1. **Objective-C与Swift编程语言**：虽然现在Swift已成为主流的iOS开发语言，但在2009年时Objective-C更为常见。书中可能详细讲解了这两种语言的基础语法、面向对象编程概念，以及如何使用它们来构建iOS应用。 2. **Xcode集成开发环境**：作为苹果官方推荐的开发工具，Xcode在iOS开发中的使用方法，包括项目设置、界面设计、代码编写、调试等环节可能会在书中有所涉及。 3. **UIKit框架**：UIKit是iOS应用开发的核心，书中可能详细解释了如何使用UIKit组件，如视图（UIView）、控制器（UIViewController）、按钮（UIButton）、标签（UILabel）等，来构建用户界面。 4. **事件处理与手势识别**：iOS应用如何响应用户触摸事件，以及如何实现手势识别（如滑动、捏合等），这些可能都是书中讨论的主题。 5. **数据持久化**：如何在iOS设备上存储数据，包括使用SQLite数据库、Core Data框架以及文件系统等方法。 6. **网络编程**：介绍如何进行网络请求，使用URLSession进行HTTP通信，以及处理JSON或XML数据等。 7. **多线程与性能优化**：书中可能涵盖了多线程编程（如GCD、NSOperationQueue）以及如何优化应用性能，以确保良好的用户体验。 8. **推送通知与后台模式**：如何集成Apple Push Notification服务，以及理解不同类型的后台模式，如声音、位置、后台刷新等。 9. **App Store提交指南**：介绍如何遵循Apple的指导方针和规定，将应用程序提交至App Store进行审核和分发。 10. **测试与调试**：Xcode的测试工具使用，包括单元测试、UI测试以及性能测试的实践指导。这本书不仅提供了理论知识，还可能包含实例代码和练习，帮助读者通过实践来学习和掌握iOS开发技能。尽管出版时间较早，但基本概念和技术原理仍然适用，对于初学者来说，仍是一份有价值的参考资料。

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页未读，继续阅读

liubingshuang

粉丝: 0
资源: 2

苹果官方iPhone应用编程指南

iphone app programming guide

iPhoneAppProgrammingGuide

①-iphone应用程序开发-iPhoneAppProgrammingGuide

C2000，28335Matlab Simulink代码生成技术，处理器在环，里面有电力电子常用的GPIO，PWM，ADC，DMA，定时器中断等各种电力电子工程师常用的模块儿，只需要有想法剩下的全部自

OpenArk64-1.3.8beta版-20250104

面向对象（下）代码.doc

基于springboot的校园台球厅人员与设备管理系统--论文.zip

【创新无忧】基于matlab蜣螂算法DBO优化极限学习机KELM故障诊断【含Matlab源码 10720期】.zip

基于springboot的数码论坛系统设计与实现--论文.zip

基于springboot的生鲜超市管理的设计与实现.zip

最新资源