SwiftUI

SwiftUI是開發iOS、iPadOS、watchOS和macOS應用程序的現代化方式。 它從“舊有”方式轉變，使許多現有的蘋果框架（UIKit，AppKit和WatchKit）變得過時。 這些框架有一個共同點：它們是命令式的。 作為程序員，您可以確定事物應該以每個像素為單位如何顯示。然後，您會對用戶事件作出響應並手動更新數據。在每次更改時，您還需要決定UI應該如何更改。 SwiftUI是一個完全的變革，因為它是反應式的，UI反映了數據的狀態。不再像在UIKit中“連接事物”。 而且，您需要編寫的代碼要少得多。如果以前曾使用UIKit編寫過iPhone應用程序，您將一直在想“就這樣嗎？”。 談到代碼，使用SwiftUI，您只需編寫代碼即可。不再使用StoryBoard或Interface Builder。 我認為這很完美，因為我可以將我的代碼存儲在Git中，並可以立即看到隨時間所做的更改，而不是一些XML的亂碼。 現在，如果您以前從未使用過UIKit，您可能不明白我的意思。這對您來說是好事，不用擔心。 由於蘋果能夠從頭開始使用SwiftUI，我們有很多優勢。 第一次接觸SwiftUI應用程式令人著迷。 以下是Hello World應用程式的代碼： import SwiftUI struct ContentView: View { var body: some View { Text("Hello World") } } 您導入SwiftUI模塊，並聲明一個符合View協議的結構。 該協議要求該結構具有一個名為“body”的計算屬性，該計算屬性返回“some View”。 這就是我們在結構內部做的事情。 “body”計算屬性返回一個類型為“Text”的單個視圖，其中包含內容“Hello World”。 由於您將始終在SwiftUI中看到“some View”使用，現在是解釋為什麼使用它而不僅僅是“View”的好時機。 該聲明強制“body”始終返回相同類型的視圖，這對於SwiftUI的工作方式至關重要。 其中一個原因是性能。為了具有高性能，SwiftUI需要將某些事情視為理所當然。其中之一是每個結構始終返回相同類型的視圖，以便可以輕鬆檢查是否需要在屏幕上重繪。 在這種情況下，我們返回一個“Text”視圖，這是我們的結構始終返回的視圖，而不管其狀態如何。

我已經在這個博客上寫了很長一段時間了。在這段時間裡，我涵蓋了許多不同的主題。 回顧往事，我從一些隨機的 Web 開發主題開始，然後專注於 Go、React、Node.js、CSS、HTML、瀏覽器 APIs、Next.js、Vue.js、Svelte、數據庫、Python、Swift，甚至電子學和 C 語言。 有時候，當我有希望寫一些與我通常所寫的主題不同的內容時，我會考慮一下。 這是我的博客，它不是一本名為“Web 開發”或其他類似的出版物。 儘管如此，當你長時間寫關於一個主題時，即使是像我這樣涵蓋了廣泛範圍的主題，你也會開始覺得自己與讀者之間有一個“合約”。 如果我決定寫關於 X 的內容而讀者對此不感興趣，會發生什麼事呢？他們會停止閱讀或關注這個博客嗎？他們會取消訂閱郵件通訊嗎？ 除非你完全偏離了主題，否則幾乎從不會有這種情況。 你讀到了上面的主題列表嗎？它們之間幾乎沒有什麼相關性，除了它們都與編程有關。但是一位 React 開發者對於 C 語言或 CSS 沒有興趣。 因此，廣泛的專業領域是編程，在這個領域下我可以寫關於任何事情。 如果我開始寫關於園藝、狗、或者徒步旅行之類的內容，那就不一樣了。 有時候我會談論商業方面的事情，或者內容的製作，但這些都是相關的。 我考慮過在旅行時寫一些類似“旅遊博客”的帖子，只是為了做些不同的事情。也許有一天我會寫，儘管我不想讓讀者困惑。還有 Google 啊哈哈。 對我來說，規則是寫我想寫的內容。每天寫一篇帖子是關鍵。否則我早就停下來了。如果有一天我想寫關於旅行、烹飪或其他任何事情的內容，我就會去寫。 有時候我寫一篇關於如何為數字遊牧在整個歐洲旅行期間設置我的面包車的帖子，說實話，關於這些主題我獲得了更多的回覆。也許只是因為在他們那個時代這有些不尋常。 我將來要做的一件事是開始寫關於 SwiftUI 和 iOS 開發的內容。我已經考慮了好幾個月了。其實，我想已經有幾年了。 但現在我覺得是合適的時候了。 過去，我決定寫一些我不是非常熱衷的主題，比如數據庫。我對數據庫有多少熱情呢？我開始寫了幾天後就停下來了。 但我想，我可以寫一些我對於 iOS 應用的想法，計劃階段，開發過程，上架 App Store，等等的內容，這可能是我的一部分讀者非常感興趣的內容。 也許他們也有一個 iOS 應用的想法，這可能會是他們開始的觸發點。 我是否對 Web 開發厭倦了？絕對不是。而且任何 iOS 應用也需要與 Web 或 API 相應的對應組件，所以這不意味著我會停止寫關於它的內容。 而且我喜歡 JavaScript。 我只是喜歡編程。用代碼創造事物。不管是 Web 應用、iOS 應用還是桌面應用，都無關緊要。 對我來說，改變一下我寫關於什麼的方式只是為了多元化並保持我的能量水平高。 對我來說一直都是這樣。我會工作在一個 Web 應用上，然後轉到 iOS 應用，然後再轉到 macOS 開發，然後再回到 Web 應用。...

過去幾週，我一直在認真學習SwiftUI。 再次嘗試之前，我曾經嘗試過，但只堅持了幾天。 它和React非常相似，除了語言不同，SwiftUI使用的是Swift而不是JavaScript。 當然，這並不是什麼新鮮事。SwiftUI無疑受React和React Native的啟發。我只是作為一位資深的React開發者對其印象做個表述。 React在Web上引入了一些徹底改變我們構建應用程序方式的事物: 声明式UI、不可變性和基於數據的UI更改。 這些都是具有改變思維方式的概念，也是Apple平台(如iOS、macOS、iPadOS、watchOS)的一個徹底變革。 當Apple在2014年引入Swift時，他們做出了一個明智的選擇，即與我們使用Objective-C的現有框架UIKit和AppKit進行無縫集成。 由於這個原因，Swift在早期階段就獲得了廣泛的應用，因為開發者對這些框架的工作方式已經非常熟悉，只不過語言發生了變化。 5年過去了，Apple的所有開發者都有足夠的時間用Swift來開發新的應用程序，這使得SwiftUI(於2019年推出)成為了一個徹底的變革。 我敢說，它甚至比Swift本身的引入更加徹底。 現在距離SwiftUI首次推出已經過去了2年。 除非你是早期採用者，否則在跳入"新熱門"之前，你應該等待一段時間以改善問題。 一開始，只有錯誤和沒有文檔，第三方庫的支援也很差。 現在SwiftUI已經成熟到足夠的程度，每個Swift教程也可以算是SwiftUI教程，而Apple也正在不斷努力使其更加優越。 我對Playground應用程序特別感興趣，因為它可以直接從iPad上構建SwiftUI應用程序。 我認為這是一種非常好的構建軟件的方式，但目前尚不可用。我們只是在WWDC上得到了一個潛在的預覽。 特別適合簡單的軟件開發，特別是初學者在學習編程時所寫的軟件。