Skip to main content

[Swift3] ? 與 !

學習 Swift 語言覺得最有趣就是變數後面的問號與驚嘆號。看著程式碼帶著一堆 ??!! 相信初學的朋友應該都挺傻眼的。其實會出現 ? 與 ! 是因為 Swift runtime 的特性:不容許變數有 nil 的存在而產生的,這時候就需要先來學習什麼是變數為 Optional(可選性)。

以下是一般情況,預先宣告了一個沒有賦值的變數,然後不小心先使用它,這種情況下就會出現 runtime error:

var string: String
print(string)

---output---------
variable 'string' used before being initialized

加上?宣告成 Optional 就安全過關:

var string: String? //-> 設定為 Optional 所以 runtime safe
print(string)

---output---------
nil

重點一:變數會有 nil 情況發生就是加上 ?

class ClassA {
var b: ClassB? // 不確定b 會不會存在,加上? 就不需要在 init 初始化
}

class ClassB {
var count = 1
var string = "Hahaha"
var x = 12.0
var y = 20.5
}

因為使用了問號 b 還是 Optional,所以沒有 runtime error。

let a = ClassA()
print( "\(a.b?.count)" )

---output---------
nil


而與 ? 相對的就是 ! , 一個包裝,一個拆包。驚嘆號最大的作用就是將「虛轉成實」,所以當使用!打開 Optional 變數時,如果該變數還是 nil 的話,就會出現 runtime error。

let a = ClassA()
print( "\(a.b!.count)" )
//使用 ! 強制將 Optional 的 b 打開,結果因為 b 是 nil 所以有 runtime error

---output---------
fatal error: unexpectedly found nil while unwrapping an Optional value

重點二:想要使用 ! 強制拆包,就必須要很肯定該包裝的內容物是存在的。

Optional Chaining (可選鍵鏈)

Optional 變數可以直接串連取用,由左至右當某一層為 nil 時,就會停止串連。

class ClassC {
var d: ClassD?
}

class ClassD {
var string: String?
}

let obj1 = ClassC()
print("\(obj1.d?.string?.characters.count)")

let obj2 = ClassC()
obj2.d = ClassD()
obj2.d?.string = "I have value."
print("\(obj2.d?.string?.characters.count)")

---output-------
nil
Optional(13)

重點三:透過 Optional Chaining 可以取用多層級下的變數值

If let 與 guard 判斷式

續上段,當我們使用 Optional Chaining 時,為了判斷該變數值存不存在,會使用 if let 將值存到另外一個區域變數內:

let obj3 = ClassC()
obj3.d = ClassD()
obj3.d?.string = "I have value."

if let count = obj3.d?.string?.characters.count {
print("obj3 的字數有: \(count)")
}else{
//值不存在
}

---output-------
obj3 的字數有: 13

雖然 if let 很好用,但是在函式內常使用也可能會陷入 if let {} 的無限迴圈,這時候可以用 guard 敘述讓函式看起來更簡潔,也可以簡略其他不必要的判斷。

guard [condition == true] else {
// if false 就必須馬上跳出
return [函式回傳值]
}

// 上面條件過關,所以繼續執行

例如從網路讀取 JSON string 轉成 struct object, 這時候使用 guard 可以讓 init 建構式清爽又乾淨。

struct Item {
let title: String
let marked : Bool

init?(_ dist: [String: Any]) {
guard let title = dist["title"] as? String,
let marked = dist["marked"] as? Bool
else {
return nil
}

self.title = title
self.marked = marked
}
}


重點四:雖然針對 Optional 變數有很多拆法,但是保持乾淨也是很重要的。

總結

最後直接拿常用的 UITableViewDataSource cellForRowAt 函式來說明三種拆法:
1. 使用 ! 拆包:看起來很乾淨實際危險性高,因為必須確定不會有錯誤發生

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "Cell") as! Cell
cell.textLabel?.text = "Row: \(indexPath.row)"

return cell
}

2. 使用 if let 判斷:安全性夠,但是一旦 cell 需要做很多事情的話,會有很多 {} 包圍

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
if let cell = tableView.dequeueReusableCell(withIdentifier: "Cell") as? Cell {
cell.textLabel?.text = "Row: \(indexPath.row)"
return cell
}else{
return UITableViewCell()
}
}

3. 使用 guard 判斷式: 安全且函式內較乾淨,建議採用

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
guard let cell = tableView.dequeueReusableCell(withIdentifier: "Cell") as? Cell else {
return UITableViewCell()
}

cell.textLabel?.text = "Row: \(indexPath.row)"
return cell
}

Comments

Popular posts from this blog

[Unity] erinylin.lazylib - Cookie for PlayerPrefs

有鑑於 PlayerPrefs 測試與版本更新問題,將大家都愛用的 PreviewLabs.PlayerPrefs 打包起來,製作重點還是以懶人為主,基本上 PlayerPrefs 資料更新與數量並不可能會有強烈衝擊效能的狀況產生,所以為了方便開發,就弄了一個視覺化工具,方便除錯用。

雖然 PreviewLabs.PlayerPrefs 作者都宣告放棄他們的版權,不過為了尊重程式,僅僅加入了兩個公用函式,其他並無更改。

內有:
Cookie ManagerCookie 用 DataObject 混合編輯 ScriptableObject執行階段除錯視窗工具當然還是有懶人常數檔案輸出資料版本控制,方便更新版後儲存資料更新功能其實很多,有興趣的請自行到 Github 下載並參考範例吧!

PureMVC 我也會 [1]

為什麼要學 PureMVC ? 明明網路上一堆免費的 MVC 微型框架,為什麼 Erin 特別愛用 PureMVC?
嚴格說起來,使用 PureMVC 開發的專案寫出來的 class 檔一定比 一些簡化版 PureMVC base 的 framework 如 Robotlegs 多,也比較難入門,但是為什麼要特別推薦它?

答案很簡單,越基本的東西反而是最好延伸,留白越多的紙最好畫!也因為如此才令人著迷啊...(咦?)

百分百真情推薦:
大家的職責切分的很乾淨...棒訊息傳遞機制是好物由於架構超然於 Flash / Flex 架構上,反而在 team work 分工的時候更方便擁有多個程式語言的版本,想要入門其他語言是個不錯的選擇Source code 公開化,要改要加什麼隨便你~~出來的時間比較久相關資源多
接下來就來看圖說故事。
PureMVC Diagram, 出處:PureMVC 官網

當初第一眼看到這張圖的時候,真的挺像個變形蟲,不過想要快速了解 framework 的基本運作流程,最容易的方法就是看圖說故事...

PureMVC 核心是由四個單例(singleton design pattern) 組成: Facade, Model, View and Control,唯一出入口就是 Facade,你會發現圖示中 Model, View and Control 都是雙向指向連接到 Facade,它們互相不清楚其他人的存在。

這四個 Class 你也只需要認識 Facade 即可...=)

Facade :
圖示中, Facade 下方有三個圈圈分別是 Mediator, Command and Proxy,意思是所有實作這三種 class instance 都是透過 Façade 來註冊移除或取用其他資源。拿 Flash 來比喻, Facade 很像是 root,所有的 DisplayObject 顯示、操作和移除都可以透過 root 抓取實體後執行,所有實體都可以透過 root 去找到其他實體。在 PureMVC 中, 它最大的作用就是切開 MVC 彼此的依賴,也提供 user 一個統一的操作出入口。

Model, View and Control
你會發現這三個大圈圈旁邊都有一堆同色的 Proxy, Command and Mediator,當各自的 class inst…

[AIR] JoSiResize - Mobile 開發小工具

JoSiResizev0.6.0,Adobe AIR 3 runtime之前開發 tool app 的時候並沒有很深刻的體認到圖片素材的 resize 是一個很麻煩的事情...畢竟圖片使用量並不大,等到開發遊戲類的 app 才發現光處理不同螢幕尺寸的圖片素材是一個相當折磨人的工作。
因此 JoSiResize app 誕生了~~~原理是採用最小 scale 長寬比例不變的方式進行放大縮小。使用方法非常簡單,設定好變更的尺寸,接下來,將需要處理的圖片檔案全選直接拖曳到視窗內,畫面即會跳出預備儲存的檔案夾選擇畫面,確認後即開始轉檔。