iOS 12深度解析：Views、View Controllers与Frameworks详解

需积分: 32 122 浏览量更新于2024-07-17 收藏 8.96MB PDF 举报

《编程iOS 12：深入探索视图、控制器与框架》（Programming iOS 12: Dive Deep into Views, View Controllers, and Frameworks）是由业内知名作者Matt Neuburg撰写的一本详细指南。这本书是该系列的第九版，于2018年10月首次发布，版权归Matt Neuburg所有，享有保留权。本书专为iOS开发者设计，旨在帮助读者深入了解iOS 12平台的核心组件，包括视图(Views)、控制器(View Controllers)以及iOS的各种框架。在第九版中，Neuburg更新了内容，反映了iOS 12的新特性和改进，确保了读者能够跟上苹果系统的技术发展步伐。视图(Views)是构建用户界面的基础，本书会深入讲解如何设计和管理各种视图，如UIView及其子类，以及如何利用它们创建丰富的动态用户界面。读者将学习如何控制视图的位置、大小、颜色、动画等特性，以实现流畅且直观的用户体验。控制器(View Controllers)则是应用程序逻辑的核心，它负责协调视图之间的工作。书中会讲解如何创建、组织和管理控制器，以及如何使用故事板Storyboard来设计界面和控制器之间的交互。理解并熟练运用控制器是实现iOS应用功能的关键。框架是iOS开发中的基石，包括UIKit、Core Data、Core Graphics、Foundation等，这些框架提供了丰富的功能和工具。第九版会深入剖析这些框架的最新用法，帮助开发者高效地实现数据存储、图形渲染、网络请求和基础操作等功能。此外，本书还涵盖了iOS 12的新特性，如Swift语言的最新进展、安全性和性能优化、以及与macOS和tvOS的集成。对于希望进一步提升iOS开发技能的开发者来说，这是一本不可或缺的参考书。通过阅读《Programming iOS 12》，开发者不仅能掌握基础知识，还能获得实践经验，从而在实际项目中灵活应用所学内容，提升自己的iOS应用开发能力。无论是初学者还是经验丰富的开发者，都能从中受益匪浅。

How an App Launches

Your app’s root view controller is the link between your app’s UIWindow and the interface that it

contains. The initial view controller is instantiated, and that instance is assigned to the window’s roo

tViewController property. It is now the app’s root view controller, and its view henceforth

occupies the entirety of the window. The root view controller itself will be the top of the view

controller hierarchy, of which I’ll have much more to say in Chapter 6.

But how does your app, at launch time, come to have a main window in the first place, and how does

that window come to be populated and displayed? If your app uses a main storyboard, it all happens

automatically. Your app consists, ultimately, of a single call to the UIApplicationMain function.

(Unlike an Objective-C project, a typical Swift project doesn’t make this call explicitly, in code; it is

called for you, behind the scenes.) Here are some of the first things this call does:

1. UIApplicationMain instantiates UIApplication and retains this instance, to serve as the shared

application instance, which your code can later refer to as UIApplication.shared. It then

instantiates the app delegate class. (It knows which class is the app delegate because it is

marked @UIApplicationMain.) It retains the app delegate instance, thus ensuring that it will

persist for the lifetime of the app, and assigns it as the application instance’s delegate.

2. UIApplicationMain looks to see whether your app uses a main storyboard. It knows whether

you are using a main storyboard, and what its name is, by looking at the Info.plist key “Main

storyboard file base name” (UIMainStoryboardFile). You can easily edit this key, if

necessary, by editing the target and, in the General pane, changing the Main Interface value in

the Deployment Info section. By default, a new iOS project has a main storyboard called

Main.storyboard, and the Main Interface value is Main.

3. If your app uses a main storyboard, UIApplicationMain instantiates UIWindow and assigns

the window instance to the app delegate’s window property, which retains it, thus ensuring that

the window will persist for the lifetime of the app. It also sizes the window so that it will

initially fill the device’s screen. This is ensured by setting the window’s frame to the screen’s

bounds. (I’ll explain later in this chapter what “frame” and “bounds” are.)

4. If your app uses a main storyboard, UIApplicationMain instantiates that storyboard’s initial

view controller. (I’ll talk more about that in Chapter 6.) It then assigns this view controller

instance to the window’s rootViewController property, which retains it. When a view

controller becomes the main window’s rootViewController, its main view (its view) is 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 the main window a

reasonable backgroundColor. In general you’ll have no reason to change anything else about

the window itself.

5. UIApplicationMain calls the app delegate’s application(_:didFinishLaunchingWithOpt

ions:).

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

window. Therefore, if your app uses a main storyboard, UIApplicationMain calls the

window’s instance method makeKeyAndVisible.

It is also possible to write an app that lacks a main storyboard, or that has a main storyboard but,

under certain circumstances, effectively ignores it at launch time by overriding some or all of the

automatic UIApplicationMain behavior. Such an app simply does in code — typically, in applicat

ion(_:didFinishLaunchingWithOptions:) — everything that UIApplicationMain does

automatically if the app has a main storyboard (see Appendix B for a full implementation):

1. Instantiate UIWindow and assign it as the app delegate’s window property. With a little clever

coding, we can avoid doing this if UIApplicationMain did it already:

self.window = self.window ?? UIWindow()

2. Instantiate a view controller, configure it as needed, and assign it as the window’s rootViewCo

ntroller property. If UIApplicationMain has already assigned a root view controller, this

view controller replaces it.

3. Call makeKeyAndVisible on the window, to show it. This does no harm even if there is a main

storyboard, as UIApplicationMain will not subsequently repeat this call.

An app with no main storyboard is not common nowadays, but a hybrid app that sometimes overrides

some of the automatic UIApplicationMain behavior is. A frequent scenario is that our app has

something like a login or registration screen that appears at launch if the user has not logged in, but

doesn’t appear on subsequent launches once the user has logged in.

To enforce this, we implement step 2 only, leaving UIApplicationMain to perform the other steps. In

step 2, we look in UserDefaults (or some similar storage) to see if the user has logged in:

If so, we skip past the storyboard’s initial view controller to the next view controller in the

storyboard.

If not, we do nothing, leaving UIApplicationMain to instantiate the storyboard’s initial view

controller and make it the window’s rootViewController.

Here’s the general idea (this code will make much more sense to you after reading Chapter 6):

func application(_ application: UIApplication,

didFinishLaunchingWithOptions launchOptions:

[UIApplication.LaunchOptionsKey: Any]?) -> Bool {

if let rvc = self.window?.rootViewController {

let ud = UserDefaults.standard

if ud.string(forKey: "username") != nil { // user has logged in

let vc = rvc.storyboard!.instantiateViewController(

withIdentifier: "userHasLoggedIn")

self.window!.rootViewController = vc

}

return true

}

Subclassing UIWindow

A possible variation is to subclass UIWindow. That is uncommon nowadays, though it can be a way

of intervening in hit-testing (Chapter 5) or the target–action mechanism (Chapter 12). To use an

instance of your UIWindow subclass as your app’s main window, you would need to prevent UIAppl

icationMain from assigning a plain vanilla UIWindow instance as your app delegate’s window. The

rule is that, 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

app delegate’s window property.

If that value is not nil, UIApplicationMain leaves it alone.

Therefore, to make your app’s main window be an instance of your UIWindow subclass, all you have

to do is assign that instance as the default value for the app delegate’s window property:

@UIApplicationMain

class AppDelegate : UIResponder, UIApplicationDelegate {

var window : UIWindow? = MyWindow()

// ...

}

Referring to the Window

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

If a UIView is in the interface, it automatically has a reference to the window through its own wind

ow property. Your code will probably be running in a view controller with a main view, so self.

view.window is usually the best way to refer to the window.

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

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:

let w = UIApplication.shared.delegate!.window!!

If you prefer something less generic (and requiring less extreme unwrapping of Optionals), cast the

delegate explicitly to your app delegate class:

let w = (UIApplication.shared.delegate as! AppDelegate).window!

The shared application maintains a reference to the window through its keyWindow property:

let w = UIApplication.shared.keyWindow!

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

and interpose them as the application’s key window.

Experimenting with Views

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

your own. If you start your project with the Single View App template, it gives you the simplest

possible app — a main storyboard containing one scene consisting of one view controller instance

along with its main view. As I described in the preceding section, 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. Thus, if you can get your views to become subviews of that view

controller’s main view, they will be present in the app’s interface when it launches.

In the nib editor, you can drag a view from the Library into the main view as a subview, and it will be

instantiated in the interface when the app runs. However, my initial examples will all create views

and add them to the interface in code. So where should that code go? The simplest place is the view

controller’s viewDidLoad method, which is provided as a stub by the project template code; it runs

once, before the view appears in the interface for the first time.

The viewDidLoad method can refer to the view controller’s main view by saying self.view. In my

code examples, whenever I say self.view, you can assume we’re in a view controller and that self

.view is this view controller’s main view. For example:

override func viewDidLoad() {

super.viewDidLoad() // this is template code

let v = UIView(frame:CGRect(x:100, y:100, width:50, height:50))

v.backgroundColor = .red // small red square

self.view.addSubview(v) // add it to main view

}

Try it! Make a new project from the Single View App template, and make the ViewController class’s

viewDidLoad look like that. Run the app. You will actually see the small red square in the running

app’s interface.

剩余1143页未读，继续阅读

zzqiufeng

粉丝: 0
资源: 6

iOS 12深度解析：Views、View Controllers与Frameworks详解

Programming iOS 12 Dive Deep into Views View Controllers and Frameworks

Programming iOS 12.epub

Programming iOS 12

Programming iOS 8 Dive Deep into Views, View Controllers And Frameworks 2014

Programming iOS 11 Dive Deep into Views, View Controllers, Frameworks

Programming iOS 8 Dive Deep into Views, View Controllers, and Frameworks

Programming iOS 11 Dive Deep into Views, View Controllers, and 无水印原版pdf

Programming iOS 12: Dive Deep into Views, View Controllers, and Frameworks

Programming iOS 10: Dive Deep into Views, View Controllers, and Frameworks

IOS8 Dive Deep into Views, View Controllers, and Frameworks

最新资源