iPhone应用编程指南：专业开发者参考手册

需积分: 1 29 浏览量更新于2024-07-31 收藏 8.29MB PDF 举报

"AppProgrammingGuide 是一份针对iPhone应用开发的专业参考手册，由Apple Inc.于2010年3月24日发布。该指南详细介绍了iPhone应用开发的相关知识，适用于具备一定专业背景的读者。内容涵盖应用开发的各个方面，旨在帮助开发者创建高质量的iOS应用程序。" 在这份指南中，开发者可以找到关于iPhone应用开发的关键信息，包括但不限于以下知识点： 1. **iOS编程基础**：了解iOS平台的开发环境，如Xcode集成开发环境（IDE），Objective-C或Swift编程语言的基础知识，以及Cocoa Touch框架，这些都是构建iPhone应用的基础。 2. **用户界面设计**：学习Apple的人机交互指南（Human Interface Guidelines，HIG），以确保应用遵循Apple的设计标准，提供一致且直观的用户体验。 3. **事件处理**：理解如何处理触摸事件、手势识别，以及与用户交互的其他方式，以创建响应灵敏的应用。 4. **多线程编程**：学习如何在iOS平台上进行多任务处理，确保应用在后台运行时仍能保持性能和稳定性。 5. **内存管理**：了解iOS中的内存管理策略，包括自动引用计数（ARC）和垃圾回收，以避免内存泄漏并优化应用性能。 6. **数据持久化**：探讨如何利用SQLite数据库、Core Data框架或其他存储技术保存和检索用户数据。 7. **网络编程**：学习如何进行HTTP请求，实现网络通信，以及如何使用URLSession等API处理网络数据。 8. **推送通知**：理解如何集成Apple的推送通知服务，以便在应用不在前台运行时与用户保持互动。 9. **本地化与国际化**：了解如何使应用适应不同地区的语言和文化习惯，以便全球范围内使用。 10. **测试与调试**：掌握使用Xcode的测试工具，如单元测试、UI测试，以及调试技巧，确保应用在发布前的稳定性和可靠性。 11. **App Store审核指南**：熟悉Apple的App Store审核流程和指南，以确保应用符合提交和上架的所有要求。 12. **App生命周期与后台模式**：学习应用的启动、运行、暂停和恢复等生命周期状态，以及如何在后台模式下执行任务。请注意，这份文档明确指出，除非获得Apple的明确许可，否则不得复制、存储或传播其中的内容。同时，使用Apple的商标，如键盘苹果标志，需获得其书面同意，否则可能构成商标侵权和不公平竞争。文档中提到的技术并未授予任何明示或暗示的许可，Apple保留所有相关知识产权。这份文档旨在辅助应用开发者开发符合Apple标准的iOS应用。

■ Table View Programming Guide for iPhone OS provides information about working with table views, which

are used frequently in iPhone applications.

■ The Objective-C Programming Language introduces Objective-C and the Objective-C runtime system,

which is the basis of much of the dynamic behavior and extensibility of iPhone OS.

See Also

INTRODUCTION

Introduction

Every iPhone application is built using the UIKit framework and therefore has essentially the same core

architecture. UIKit provides the key objects needed to run the application and to coordinate the handling of

user input and the display of content on the screen. Where applications deviate from one another is in how

they configure these default objects and also where they incorporate custom objects to augment their

application’s user interface and behavior.

Although customizations to your application’s user interface and basic behavior occur down within your

application’s custom code, there are many customizations that you must make at the highest levels of the

application. Because these application-level customizations affect the way your application interacts with

the system and other applications installed on a device, it is important to understand when you need to act

and when the default behavior is sufficient. This chapter provides an overview of the core application

architecture and the high-level customization points to help you make determinations about when to

customize and when to use the default behavior.

Important: The UIKit classes are generally not thread safe. All work related to your application’s user interface

should be performed on your application’s main thread.

Core Application Architecture

From the time your application is launched by the user, to the time it exits, the UIKit framework manages

the majority of the application’s key infrastructure. An iPhone application receives events continuously from

the system and must respond to those events. Receiving the events is the job of the UIApplication object

but responding to the events is the responsibility of your custom code. In order to understand where you

need to respond to events, though, it helps to understand a little about the overall life cycle and event cycles

of an iPhone application. The following sections describe these cycles and also provide a summary of some

of the key design patterns used throughout the development of iPhone applications.

The Application Life Cycle

The application life cycle constitutes the sequence of events that occurs between the launch and termination

of your application. In iPhone OS, the user launches your application by tapping its icon on the Home screen.

Shortly after the tap occurs, the system displays some transitional graphics and proceeds to launch your

application by calling its main function. From this point on, the bulk of the initialization work is handed over

to UIKit, which loads the application’s user interface and readies its event loop. During the event loop, UIKit

coordinates the delivery of events to your custom objects and responds to commands issued by your

application. When the user performs an action that would cause your application to quit, UIKit notifies your

application and begins the termination process.

Figure 1-1 depicts the simplified life cycle of an iPhone application. This diagram shows the sequence of

events that occur from the time the application starts up to the time it quits. At initialization and termination,

UIKit sends specific messages to the application delegate object to let it know what is happening. During

Core Application Architecture 17

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 42).

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 22). 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 30).

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 19

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 29). For

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

List” (page 26).

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

剩余207页未读，继续阅读

bjheyun

粉丝: 2
资源: 5

iPhone应用编程指南：专业开发者参考手册

玄武岩纤维行业研究报告 新材料技术 玄武岩纤维 性能应用 市场分析

基于 Vue 3、Vite、Ant Design Vue 4.0、TypeScript、Vben Vue Admin，最先进的技术栈，让初学者能够更快的入门并投入到团队开发中去

请参阅 readme 了解更新的 repo 详细信息！一个示例商店，展示了如何使用 Vue、Stripe 和无服务器函数管理付款.zip

【java毕业设计】学生宿舍管理系统的设计与开发源码（springboot+vue+mysql+说明文档+LW）.zip

Python期末大作业基于LSTM的天气数据时间序列预测项目源码+论文+数据集（高分项目）

C++期末大作业基于C++和QT的天气预报系统源码（高分项目）

AppsFlyer广告平台综合表现报告 移动广告媒体源效果评估AppsFlyer指数分析

【java毕业设计】甘肃非物质文化网站的设计与开发源码（springboot+vue+mysql+说明文档+LW）.zip

【java毕业设计】基于B2B平台的医疗病历交互系统源码（springboot+vue+mysql+说明文档+LW）.zip

最新2024-12-1，zblog站群日收模板

最新资源

玄武岩纤维行业研究报告新材料技术玄武岩纤维性能应用市场分析

AppsFlyer广告平台综合表现报告移动广告媒体源效果评估AppsFlyer指数分析