2013年编程iOS 7第四版指南：Matt Neuburg 著

5星 · 超过95%的资源需积分: 10 107 浏览量更新于2024-07-24 1 收藏 11.7MB PDF 举报

《编程iOS 7, 第四版》是由Matt Neuburg撰写的一本权威指南，于2013年发布，由O'Reilly Media出版。本书是针对苹果iOS 7平台的最新教程，全面深入地介绍了iOS应用开发的关键技术和最佳实践。作为第四版，它在2013年9月18日进行了早期修订，提供了及时更新的内容，确保开发者能跟上iOS系统的发展步伐。该书覆盖了广泛的iOS 7主题，包括但不限于Swift编程语言（当时的最新语言），用户界面设计，Cocoa Touch框架，以及核心服务如地图、通知、多任务处理等。对于iOS开发新手来说，书中提供了详尽的基础知识和逐步指导，而对经验丰富的开发者，则能从中找到进阶技术和解决方案。在编写过程中，本书遵循了O'Reilly Media的一贯严谨风格，包括编辑Rachel Roumeliotis的专业把关，生产编辑、复制编辑和校对人员的精心校核，确保内容的准确性和一致性。同时，封面设计出自Karen Montgomery之手，内部设计和插图则由David Futato和Robert Romano负责，为读者提供了视觉上的愉悦体验。《编程iOS 7, 第四版》不仅适合专业的iOS开发者使用，也是iOS应用程序开发课程的教材，以及个人学习iOS开发的理想参考书籍。在线版本便于随时随地查阅，读者可以通过O'Reilly Safari在线平台获取更多相关资源和支持。此外，作者版权声明指出，未经许可，不得以任何形式进行商业或销售推广使用，且注明了O'Reilly Media的商标信息。对于任何发现的错误或遗漏，读者可访问O'Reilly的在线错误报告页面获取更多信息。《编程iOS 7, 第四版》是一本实用且全面的指南，对于想要掌握iOS 7开发技术的读者来说，是不可或缺的参考资料。通过阅读这本书，开发者可以提升技能，紧跟iOS技术的潮流，为iOS应用开发注入新的活力。

CHAPTER 1

Views

view (an object whose class is UIView or a subclass of UIView) knows how to draw

itself into a rectangular area of the interface. Your app has a visible interface thanks to

views. Creating and configuring a view can be extremely simple: “Set it and forget it.”

For example, you can drag an interface widget, such as a UIButton, into a view in the

nib editor; when the app runs, the button appears, and works properly. But you can also

manipulate views in powerful ways, in real time. Your code can do some or all of the

view’s drawing of itself (Chapter 2); it can make the view appear and disappear, move,

resize itself, and display many other physical changes, possibly with animation (Chap‐

ter 4).

A view is also a responder (UIView is a subclass of UIResponder). This means that a

view is subject to user interactions, such as taps and swipes. Thus, views are the basis

not only of the interface that the user sees, but also of the interface that the user touches

(Chapter 5). Organizing your views so that the correct view reacts to a given touch allows

you to allocate your code neatly and efficiently.

The view hierarchy is the chief mode of view organization. A view can have subviews;

a subview has exactly one immediate superview. Thus there is a tree of views. This

hierarchy allows views to come and go together. If a view is removed from the interface,

its subviews are removed; if a view is hidden (made invisible), its subviews are hidden;

if a view is moved, its subviews move with it; and other changes in a view are likewise

shared with its subviews. The view hierarchy is also the basis of, though it is not identical

to, the responder chain.

A view may come from a nib, or you can create it in code. On balance, neither approach

is to be preferred over the other; it depends on your needs and inclinations and on the

overall architecture of your app.

The Window

The top of the view hierarchy is the app’s window. It is an instance of UIWindow (or

your own subclass thereof), which is a UIView subclass. Your app should have exactly

one main window. It is created at launch time and is never destroyed or replaced. It

occupies the entire screen and forms the background to, and is the ultimate superview

of, all your other visible views. Other views are visible by virtue of being subviews, at

some depth, of your app’s window.

If your app can display views on an external screen, you’ll create an

additional UIWindow to contain those views; but in this chapter I’ll

behave as if there were just one screen, the device’s own screen, and

just one window. I repeat: if there is just one screen, your app should

create just one UIWindow. You may encounter online tutorials that

advise explicit creation of a second UIWindow as a way of making

content appear in front of the app’s main interface; such statements are

wrong and should be disregarded. To make content appear in front of

the interface, add a view, not another entire window.

The window must fill the device’s screen. Therefore, its size and position must be iden‐

tical to the size and position of the screen. This is done by setting the window’s frame

to the screen’s bounds as the window is instantiated (and I’ll explain later in this chapter

what “frame” and “bounds” are):

UIWindow* w = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

The window must persist for the lifetime of the app. To make this happen, the app

delegate class has been given a window property with a strong retain policy. As the app

launches, UIApplicationMain (called in the main function in main.m) instantiates the

app delegate class and retains the resulting instance. This is the app delegate instance;

it is never released, so it persists for the lifetime of the app. The window instance is

assigned to the app delegate instance’s window property; therefore it, too, persists for the

lifetime of the app.

You will typically not put any view content manually and directly inside your main

window. Instead, you’ll obtain a view controller and assign it to the main window’s root-

ViewController property. This causes the view controller’s main view (its view) to be

made the one and only immediate subview of your main window — the main window’s

root view. All other views in your main window will be subviews of the root view. Thus,

the root view is the highest object in the view hierarchy that the user will usually see.

There might be just a chance, under certain circumstances, that the user will catch a

glimpse of the window, behind the root view; for this reason, you may want to assign

4 | Chapter 1: Views

the main window a reasonable backgroundColor. But this seems unlikely, and in general

you’ll have no reason to change anything about the window itself.

Your app’s interface is not visible until the window, which contains it, is made the app’s

key window. This is done by calling the UIWindow instance method makeKeyAnd-

Visible.

All of the configuration that I’ve just described is trivial to perform, because the Xcode

app templates implement all of it for you:

App with a main storyboard

If your app has a main storyboard, as specified by its Info.plist key “Main storyboard

file base name” (UIMainStoryboardFile) — the default for most Xcode 5 app tem‐

plates, except the Empty Application template — then UIApplicationMain instan‐

tiates UIWindow with the correct frame and assigns that instance to the app dele‐

gate’s window property. It also instantiates the storyboard’s initial view controller

and assigns that instance to the window’s rootViewController property. All of that

happens before the app delegate’s application:didFinishLaunchingWith-

Options: is called.

Finally, UIApplicationMain calls makeKeyAndVisible to display your app’s inter‐

face. This in turn automatically causes the root view controller to obtain its main

view (typically by loading it from a nib), which the window adds as its own root

view. That happens after application:didFinishLaunchingWithOptions: is

called.

App without a main storyboard

If your app has no main storyboard, then creation and configuration of the window

must be done in some other way. Typically, it is done in code. You can see this in a

project generated from the Empty Application template, where all the configuration

I’ve just described is performed explicitly, in code, in application:didFinish-

LaunchingWithOptions:, like this:

self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

// Override point for customization after application launch.

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

It is extremely improbable that you would ever need to subclass UIWindow. If, however,

you wanted to create a UIWindow subclass and make an instance of that subclass your

app’s main window, then how you proceed depends on how the window is instantiated

in the first place:

App with a main storyboard

As the app launches, after UIApplicationMain has instantiated the app delegate, it

asks the app delegate instance for the value of its window property. If that value is

nil, UIApplicationMain instantiates UIWindow and assigns that instance to the

The Window | 5

app delegate’s window property. If that value is not nil, UIApplicationMain leaves

it alone and uses it as the app’s main window. Therefore, the way to instantiate a

UIWindow subclass and use that instance as your app’s main window is to imple‐

ment the getter for the app delegate’s window property in such a way as to generate

the UIWindow subclass instance exactly once (that is, instantiate the UIWindow

subclass only if you haven’t already done so), like this:

- (UIWindow*) window {

UIWindow* w = self->_window;

if (!w) {

w = [[MyWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

self->_window = w;

}

return w;

}

App without a main storyboard

You’re already instantiating UIWindow and assigning that instance to the app del‐

egate’s self.window, in code. So instantiate your UIWindow subclass instead.

Once the app is running, there are various ways to refer to the window:

• If a UIView is in the interface, it automatically has a reference to the window through

its own window property.

You can also use a UIView’s window property as a way of asking whether it is ulti‐

mately embedded in the window; if it isn’t, its window property is nil. A UIView

whose window property is nil cannot be visible to the user.

• The app delegate instance maintains a reference to the window through its window

property. You can get a reference to the app delegate from elsewhere through the

shared application’s delegate property, and through it you can refer to the window:

UIWindow* theWindow = [[[UIApplication sharedApplication] delegate] window];

• The shared application maintains a reference to the window through its key-

Window property:

UIWindow* theWindow = [[UIApplication sharedApplication] keyWindow];

That reference, however, is slightly volatile, because the system can create temporary

windows and interpose them as the application’s key window. For example, while a

UIAlertView is showing, it is the application’s keyWindow.

Subview and Superview

Once upon a time, and not so very long ago, a view owned precisely its rectangular area.

No part of any view that was not a subview of this view could appear inside it, because

6 | Chapter 1: Views

Experimenting With Views

In the course of this and subsequent chapters, you may want to experiment with views

in a project of your own. Since view controllers aren’t formally explained until Chap‐

ter 6, I’ll just outline two simple approaches.

One way is to start your project with the Single View Application template. It gives you

a main storyboard containing one scene with one view controller instance which itself

contains its own main view; when the app runs, that view controller will become the

app’s main window’s rootViewController, and its main view will become the window’s

root view. You can drag a view from the Object library into the main view as a subview,

and it will be instantiated in the interface when the app runs. Alternatively, you can

create views and add them to the interface in code; the simplest place to do this, for now,

is the view controller’s viewDidLoad method, which has a reference to the view con‐

troller’s main view as self.view. For example:

- (void)viewDidLoad {

[super viewDidLoad];

UIView* mainview = self.view;

UIView* v = [[UIView alloc] initWithFrame:CGRectMake(100,100,50,50)];

v.backgroundColor = [UIColor redColor]; // small red square

[mainview addSubview: v]; // add it to main view

}

Alternatively, you can start your project with the Empty Application template. It has

no .xib or .storyboard file, so your views will have to be created entirely in code. The

Empty Application template does not supply any view controllers, and does not assign

any view controller to the window’s rootViewController property. This situation causes

the runtime to complain when the application is launched: “Application windows are

expected to have a root view controller at the end of application launch.” A simple sol‐

ution is to put your code in the app delegate’s application:didFinishLaunchingWith-

Options:, creating a minimal root view controller and accessing its main view through

its view property. For example:

- (BOOL)application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

// (template code:)

self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

// Override point for customization after application launch.

// (your code:)

self.window.rootViewController = [UIViewController new];

UIView* mainview = self.window.rootViewController.view;

UIView* v = [[UIView alloc] initWithFrame:CGRectMake(100,100,50,50)];

v.backgroundColor = [UIColor redColor]; // small red square

[mainview addSubview: v]; // add it to the main view

// (template code:)

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

The Window | 7

剩余846页未读，继续阅读

li_xin_an

粉丝: 0
资源: 9

2013年编程iOS 7第四版指南：Matt Neuburg 著

ProgrammingiOS7Cookbook.pdf 英文原版

iOS7Programming

openpcs 安装包

Linux下载pcre-8.40.tar.gz代码示例

输出文本文件sy6-1.txt中的所有内容。sy6-1.txt中内容为: Welcome to Python. Python is a programming language that lets you work quickly and integrate systems more effectively

设计程序，输出文本文件sy6-1.txt中的所有内容。sy6-1.txt中内容如下: Welcome to Python. Python is a programming language that lets you work quickly and integrate syste more effectively的Python 程序怎么写

api-ms-win-core-synch-l1-2-0.dll

设计程序，输出文本文件sy6-1.txt中的所有内容。sy6-1.txt中内容如下: Welcome to Python. Python is a programming language that lets you work quickly and integrate syste more effectively.

-MD -MP -MF ..d -MT -c -o explain this command by examples

stm407-can-iap.rar

最新资源