Hsu Li-Heng

有時候，我們會需要在自己的 app 裡架一個小型的 HTTP 伺服器。可能的理由有很多，像是要做 API 測試或者是要顯示網頁內容等等。有些 app 會內建一個網頁介面，讓使用者可以從別的裝置來存取內容，像是檔案或者影片之類的；有些開發類 app 則是需要一個內建伺服器來做測試環境。而因為瀏覽器（包括

我們在開發 app 的時候，有時會跟 Google 或是 Instagram 等的第三方服務做連結，以提供像是存取雲端硬碟或者分享到社群等等的功能。通常這些服務商都會提供 SDK 給開發者，讓我們的 app 可以存取一些需要使用者登入的服務，但是使用服務商 SDK 有時也會有一些風險，比如說 Facebook

在 UIKit 當中負責處理使用者動作的東西，叫做回應鏈 (Responder Chain)。回應鏈是由許多部件一起組成的一個複合元件，包括 view、view controller、window、application 等等。這些元件經由單向鏈結串列 (singly linked list) 的架構連接在一起，使得接收動作與處理動作的物件可以不用是同一個。

在類 Unix 系統的終端機 shell 裡，有一個功能叫做管線 (pipeline)，可以把A程式的輸出口與 B 程式的輸入口串接起來，使 A 與 B 變成連動的程式。 比如說，我們可以把 ls -al（把當前資料夾底下全部的檔案用列表方式列出來）

在使用一個物件之前，我們經常會需要對其進行設定。比如說，使用一個 UIView 之前，有時我們會需要指定它的背景色彩等屬性： class ViewController: UIViewController { override func loadView() { // 建構一個 UIView 物件。 let view = UIView() // 設定

在 Apple 開發圈，我們都很熟悉所謂的 MVC 設計模式：把整個程式裡的物件分成 Model、View 與 Controller 三種不同的角色，讓它們分別負責解決不同的問題。Model 物件專責資料的封裝與相關的基礎行為，View 物件代表使用者看得到的介面元件，而 Controller 物件負責把

Swift 不同 Type Polymorphism (多型) 的實現方式各有差異，這些差異在語法中經常被刻意隱瞞。這雖然使程式碼更簡潔易讀，但也造成開發者容易碰到一些不明就裡的設計問題。此文將簡介各個 type polymorphism 的原理與異同之處，為你找出最適合的實作方式。

本篇原文（標題： View Controller 與狀態機）刊登於作者個人網頁，由 Li-Heng Hsu 所著並授權轉載。 我們常常會碰到一個 View Controller 要處理不同狀態的情況，比如說，它本身就提供了編輯與非編輯狀態。如果資料是從網路 API 抓回來的話，那可能要處理載入與錯誤狀態；

隨著 Apple 在 WWDC 2019 推出了官方的 Functional Reactive Programming 框架 Combine，FRP 可以說是大勢所趨。此文將帶大家打造一個基本版的類 Combine 框架，讓你一步一步了解 FRP 的基本概念。

最近，SwiftUI 正如火如荼地在全世界進行公開測試。如果你也有經意或不經意地接觸到 SwiftUI，那你可能會發現，它在設定 View 性質的語法上，跟我們以前學過的很不一樣。 一般在設定物件的時候，我們通常是這樣寫的： let imageView = UIImageView(image: myImage) imageView.frame = CGRect(

建造物件是一件耗時耗力的事。除了需要配置記憶體給它之外，可能還會牽涉到排版、渲染或載入外部資源等耗費大的動作。WKWebView 與 MKMapView 就是這樣的例子，都需要大量的時間去啟動。如果只有一次兩次的話還好，但如果它們經常出現的話，使用者就要常常等它們載入，很影響體驗。 解決的辦法很簡單：重複利用這些物件，省去生成這些物件所需的時間。 說起來簡單，但要怎麼實作呢？如果確定一次只會用一個物件的話，或許可以把該物件宣告成單例，

今年可以說是 Swift DSL 元年，建造者函數 (Builder functions) 與 SwiftUI 讓開發者們看到在 Swift 內設計內嵌 DSL 的各種可能性。雖然這樣說，但 Swift 一直以來都提供了許多 DSL 實作的功能，