Swift编程基础：掌握iOS 12开发 - CSDN文库

5星 · 超过95%的资源需积分: 9 185 浏览量更新于2024-07-18 2 收藏 4.81MB PDF 举报

"iOS 12 Programming Fundamentals with Swift" 是一本关于使用 Swift 语言和 Xcode 开发 iOS 应用的基础教程。这本书由 Matt Neuburg 撰写，覆盖了 Swift、Xcode 和 Cocoa 基础知识，适合初学者入门。在iOS开发领域，Swift 是Apple推出的一种现代化编程语言，具有简洁、安全和高性能的特点。本书针对iOS 12版本，深入讲解如何使用Swift来构建iOS应用。Swift 的特性包括类型推断、选项类型、泛型、协议和扩展等，这些都使得编写iOS应用变得更加高效和易于理解。 Xcode 是Apple官方的集成开发环境（IDE），用于编写iOS和macOS应用。书中将介绍如何使用Xcode的界面构建器（Interface Builder）设计用户界面，以及如何使用源代码编辑器编写Swift代码。此外，还会涉及Xcode的调试工具、测试框架以及持续集成等方面的内容，帮助开发者实现高效开发和测试。 Cocoa 是Apple开发框架的总称，包含了Foundation和UIKit等库，用于构建iOS和macOS应用。在iOS开发中，Cocoa Touch 是关键部分，提供了许多UI控件和系统服务。书中的“Cocoa Basics”部分会详细阐述如何使用这些框架来实现常见的应用功能，如导航控制器、表视图、页面控制器等，并且讲解如何处理触摸事件和动画效果。书中可能会涵盖以下主题： 1. Swift基础：变量、常量、数据类型、控制流、函数和闭包。 2. 类与结构体：继承、封装、多态以及协议。 3. Xcode项目设置：创建新项目、配置目标、设置模拟器和真机调试。 4. Interface Builder：使用故事板布局界面、绑定UI元素和代码。 5. Model-View-Controller（MVC）架构：理解和实践MVC模式。 6. View Controller生命周期和导航：理解生命周期方法，使用UINavigationController实现页面导航。 7. UIKit组件：UILabel、UIButton、UITableView、UICollectionView等基本组件的使用。 8. 自定义视图和手势识别：创建自定义视图，添加手势识别事件。 9. 数据持久化：使用Core Data或SQLite存储数据。 10. 异步编程：网络请求、GCD（Grand Central Dispatch）和OperationQueue。 11. 错误处理：使用Swift的try-catch语句进行错误处理。 12. 性能优化：内存管理、性能分析和调试技巧。 13. App Store发布流程：签名、打包、测试和提交应用。通过学习这本书，读者将能够掌握iOS开发的基本技能，具备独立开发iOS应用的能力。同时，随着对Swift和Cocoa的理解加深，开发者可以进一步探索更高级的主题，如SwiftUI、Combine框架以及ARKit等新技术。

Ground of Being

A complete Swift command is a statement. A Swift text file consists of multiple lines of text. Line breaks are meaningful. The typical

layout of a program is one statement, one line:

print("hello")

print("world")

(The print command provides instant feedback in the Xcode console.)

You can combine more than one statement on a line, but then you need to put a semicolon between them:

print("hello"); print("world")

You are free to put a semicolon at the end of a statement that is last or alone on its line, but no one ever does (except out of habit,

because C and Objective-C require the semicolon):

print("hello");

print("world");

Conversely, a single statement can be broken into multiple lines, in order to prevent long statements from becoming long lines. But you

should try to do this at sensible places so as not to confuse Swift. For example, after an opening parenthesis is a good place:

print(

"world")

Comments are everything after two slashes in a line (so-called C++-style comments):

print("world") // this is a comment, so Swift ignores it

You can also enclose comments in /*...*/, as in C. Unlike C, C-style comments can be nested.

Many constructs in Swift use curly braces as delimiters:

class Dog {

func bark() {

print("woof")

}

}

By convention, the contents of curly braces are preceded and followed by line breaks and are indented for clarity, as shown in the

preceding code. Xcode will help impose this convention, but the truth is that Swift doesn’t care, and layouts like this are legal (and are

sometimes more convenient):

class Dog { func bark() { print("woof") }}

Swift is a compiled language. This means that your code must build — passing through the compiler and being turned from text into

some lower-level form that a computer can understand — before it can run and actually do the things it says to do. The Swift compiler

is very strict; in the course of writing a program, you will often try to build and run, only to discover that you can’t even build in the

first place, because the compiler will flag some error, which you will have to fix if you want the code to run. Less often, the compiler

will let you off with a warning; the code can run, but in general you should take warnings seriously and fix whatever they are telling

you about. The strictness of the compiler is one of Swift’s greatest strengths, and provides your code with a large measure of audited

correctness even before it ever runs.

The Swift compiler’s error and warning messages, however, range from the insightful to the obtuse to the downright misleading. You

will often know that something is wrong with a line of code, but the Swift compiler will not be telling you clearly exactly what is wrong

or even where in the line to focus your attention. My advice in these situations is to pull the line apart into several lines of simpler code

until you reach a point where you can guess what the issue is. Try to love the compiler despite the occasional unhelpful nature of its

messages. Remember, it knows more than you do, even if it is sometimes rather inarticulate about its knowledge.

Everything Is an Object?

In Swift, “everything is an object.” That’s a boast common to various modern object-oriented languages, but what does it mean? Well,

that depends on what you mean by “object” — and what you mean by “everything.”

Let’s start by stipulating that an object, roughly speaking, is something you can send a message to. A message, roughly speaking, is an

imperative instruction. For example, you can give commands to a dog: “Bark!” “Sit!” In this analogy, those phrases are messages, and

the dog is the object to which you are sending those messages.

In Swift, the syntax of message-sending is dot-notation. We start with the object; then there’s a dot (a period); then there’s the message.

(Some messages are also followed by parentheses, but ignore them for now; the full syntax of message-sending is one of those details

we’ll be filling in later.) This is valid Swift syntax:

fido.bark()

rover.sit()

The idea of everything being an object is a way of suggesting that even “primitive” linguistic entities can be sent messages. Take, for

example, 1. It appears to be a literal digit and no more. It will not surprise you, if you’ve ever used any programming language, that you

can say things like this in Swift:

let sum = 1 + 2

But it is surprising to find that 1 can be followed by a dot and a message. This is legal and meaningful in Swift (don’t worry about what

it actually means):

let s = 1.description

But we can go further. Return to that innocent-looking 1 + 2 from our earlier code. It turns out that this is actually a kind of syntactic

trickery, a convenient way of expressing and hiding what’s really going on. Just as 1 is actually an object, + is actually a message; but

it’s a message with special syntax (operator syntax). In Swift, every noun is an object, and every verb is a message.

Perhaps the ultimate acid test for whether something is an object in Swift is whether you can modify it. An object type can be extended

in Swift, meaning that you can define your own messages on that type. For example, you can’t normally send the sayHello message to

a number. But you can change a number type so that you can:

extension Int {

func sayHello() {

print("Hello, I'm \(self)")

}

}

1.sayHello() // outputs: "Hello, I'm 1"

In Swift, then, 1 is an object. In some languages, such as Objective-C, it clearly is not; it is a “primitive” or scalar built-in data type. So

the distinction being drawn here is between object types on the one hand and scalars on the other. In Swift, there are no scalars; all

types are ultimately object types. That’s what “everything is an object” really means.

Variables

A variable is a name for an object. Technically, it refers to an object; it is an object reference. Nontechnically, you can think of it as a

shoebox into which an object is placed. The object may undergo changes, or it may be replaced inside the shoebox by another object,

but the name has an integrity all its own. The object to which the variable refers is the variable’s value.

In Swift, no variable comes implicitly into existence; all variables must be declared. If you need a name for something, you must say

“I’m creating a name.” You do this with one of two keywords: let or var. In Swift, declaration is usually accompanied by initialization

— you use an equal sign to give the variable a value immediately, as part of the declaration. These are both variable declarations (and

initializations):

let one = 1

var two = 2

Once the name exists, you are free to use it. For example, we can change the value of two to be the same as the value of one:

let one = 1

var two = 2

two = one

The last line of that code uses both the name one and the name two declared in the first two lines: the name one, on the right side of the

equal sign, is used merely to refer to the value inside the shoebox one (namely 1); but the name two, on the left side of the equal sign, is

used to replace the value inside the shoebox two. A statement like that, with a variable name on the left side of an equal sign, is called

an assignment, and the equal sign is the assignment operator. The equal sign is not an assertion of equality, as it might be in an

algebraic formula; it is a command. It means: “Get the value of what’s on the right side of me, and use it to replace the value of what’s

on the left side of me.”

The two kinds of variable declaration differ in that a name declared with let cannot have its value replaced. A variable declared with

let is a constant; its value is assigned once and stays. This won’t even compile:

let one = 1

var two = 2

one = two // compile error

It is always possible to declare a name with var to give yourself the most flexibility, but if you know you’re never going to replace the

initial value of a variable, it’s better to use let, as this permits Swift to behave more efficiently — so much more efficiently, in fact, that

the Swift compiler will actually call your attention to any case of your using var where you could have used let, offering to change it

for you.

Variables also have a type. This type is established when the variable is declared and can never change. For example, this won’t

compile:

var two = 2

two = "hello" // compile error

Once two is declared and initialized as 2, it is a number (properly speaking, an Int) and it must always be so. You can replace its value

with 1 because that’s also an Int, but you can’t replace its value with "hello" because that’s a string (properly speaking, a String) —

and a String is not an Int.

Variables literally have a life of their own — more accurately, a lifetime of their own. As long as a variable exists, it keeps its value

alive. Thus, a variable can be not only a way of conveniently naming something, but also a way of preserving it. I’ll have more to say

about that later.

WARNING

By convention, type names such as String or Int (or Dog or Cat) start with a capital letter; variable names start with a small letter. Do not violate this convention. If you

do, your code might still compile and run just fine, but I will personally send agents to your house to remove your kneecaps in the dead of night.

Functions

Executable code, like fido.bark() or one = two, cannot go just anywhere in your program. (Failure to appreciate this fact is a common

beginner mistake, and can result in a mysterious compile error message such as “Expected declaration.”) In general, executable code

must live inside the body of a function. A function is a batch of code that can be told, as a batch, to run. Typically, a function has a

name, and it gets that name through a function declaration. Function declaration syntax is another of those details that will be filled in

later, but here’s an example:

func go() {

let one = 1

var two = 2

two = one

}

That describes a sequence of things to do — declare one, declare two, change the value of two to match the value of one — and it gives

that sequence a name, go; but it doesn’t perform the sequence. The sequence is performed when someone calls the function. Thus, we

might say, elsewhere:

go()

That is a command to the go function that it should actually run. But again, that command is itself executable code, so it cannot live on

its own either. It might live in the body of a different function:

func doGo() {

go()

}

But wait! This is getting a little nutty. That, too, is just a function declaration; to run it, someone must call doGo by saying doGo() —

and that’s executable code too. This seems like some kind of infinite regression; it looks like none of our code will ever run. If all

executable code has to live in a function, who will tell any function to run? The initial impetus must come from somewhere.

In real life, fortunately, this regression problem doesn’t arise. Remember that your goal is ultimately to write an iOS app. Thus, your

app will be run on an iOS device (or the Simulator) by a runtime that already wants to call certain functions. So you start by writing

special functions that you know the runtime itself will call. That gives your app a way to get started and gives you places to put

functions that will be called by the runtime at key moments — such as when the app launches, or when the user taps a button in your

app’s interface.

TIP

Swift also has a special rule that a file called main.swift, exceptionally, can have executable code at its top level, outside any function body, and this is the code that

actually runs when the program runs. You can construct your app with a main.swift file, but in general you won’t need to.

剩余586页未读，继续阅读

trismile

粉丝: 4

最新资源