原創(chuàng)鏈接：https://www.hackingwithswift.com/100/swiftui

以下內(nèi)容僅供學(xué)習(xí)參考：?

今天我們將為我們的應(yīng)用程序構(gòu)建用戶界面——除了我們處理網(wǎng)絡(luò)的部分之外的所有內(nèi)容。

雖然今天的工作基礎(chǔ)對(duì)你來(lái)說(shuō)很熟悉，但你仍然可以看到新事物的空間。隨著我們繼續(xù)突破 SwiftUI 的界限，這將變得尤為普遍——當(dāng)你的應(yīng)用程序簡(jiǎn)單時(shí)，一切都變得簡(jiǎn)單，但隨著我們更多地涉足更大的應(yīng)用程序，你會(huì)發(fā)現(xiàn)我們需要花更多時(shí)間來(lái)正確處理細(xì)節(jié)。

但沒(méi)關(guān)系。正如美國(guó)輪胎大亨哈維費(fèi)爾斯通曾經(jīng)說(shuō)過(guò)的那樣，“成功是細(xì)節(jié)的總和”。我希望你能看看 Apple 的 iOS 應(yīng)用程序并從中得到啟發(fā)：他們的用戶界面通常并不復(fù)雜，但他們投入了大量工作來(lái)確保細(xì)節(jié)正確無(wú)誤，因此整個(gè)體驗(yàn)感覺(jué)很棒。

當(dāng)用戶在他們價(jià)值 1000 美元的 iPhone 上啟動(dòng)你的應(yīng)用程序時(shí)，它會(huì)占據(jù)整個(gè)屏幕。你欠他們，也欠你自己，以確保你已盡最大努力讓事情盡可能順利地進(jìn)行。蘋(píng)果能做到，我們也能！

今天你要完成三個(gè)主題，在這些主題中你將使用屬性觀察器、觀察對(duì)象、disabled()等等。

獲取基本的訂單詳細(xì)信息

該項(xiàng)目的第一步是創(chuàng)建一個(gè)訂購(gòu)屏幕，顯示訂單的基本細(xì)節(jié)：他們想要多少紙杯蛋糕，想要什么類(lèi)型，以及是否有任何特殊定制。

在進(jìn)入 UI 之前，我們需要先定義數(shù)據(jù)模型。之前我們已經(jīng)使用簡(jiǎn)單的@State值類(lèi)型和@StateObject引用類(lèi)型，并且我們已經(jīng)研究了如何讓一個(gè)ObservableObject包含結(jié)構(gòu)的類(lèi)成為可能，以便我們獲得兩者的好處。

在這里我們將采用不同的解決方案：我們將有一個(gè)單一的類(lèi)來(lái)存儲(chǔ)我們所有的數(shù)據(jù)，這些數(shù)據(jù)將從一個(gè)屏幕傳遞到另一個(gè)屏幕。這意味著我們應(yīng)用程序中的所有屏幕都共享相同的數(shù)據(jù)，正如你將看到的那樣，它會(huì)很好地工作。

現(xiàn)在這個(gè)類(lèi)不需要很多屬性：

• 蛋糕的類(lèi)型，加上所有可能選項(xiàng)的靜態(tài)數(shù)組。

• 用戶想要訂購(gòu)多少蛋糕。

• 用戶是否想要提出特殊請(qǐng)求，這將在我們的 UI 中顯示或隱藏額外選項(xiàng)。

• 用戶是否想要在蛋糕上加糖霜。

• 用戶是否想在蛋糕上撒些糖屑。

其中每一個(gè)都需要在更改時(shí)更新 UI，這意味著我們需要用 @Published標(biāo)記它們并使整個(gè)類(lèi)符合ObservableObject.

因此，請(qǐng)創(chuàng)建一個(gè)名為 Order.swift 的新 Swift 文件，將其 Foundation 導(dǎo)入更改為 SwiftUI，并為其提供以下代碼：

我們現(xiàn)在可以通過(guò)ContentView添加此屬性在內(nèi)部創(chuàng)建它的單個(gè)實(shí)例：

這是唯一創(chuàng)建訂單的地方——我們應(yīng)用程序中的每個(gè)其他屏幕都將傳遞該屬性，因此它們都使用相同的數(shù)據(jù)。

我們將分三部分構(gòu)建此屏幕的 UI，從紙杯蛋糕類(lèi)型和數(shù)量開(kāi)始。第一部分將顯示一個(gè)選擇器，讓用戶從香草、草莓、巧克力和彩虹蛋糕中進(jìn)行選擇，然后是一個(gè)范圍為 3 到 20 的步進(jìn)器來(lái)選擇數(shù)量。所有這些都將被包裝在一個(gè)表單中，該表單本身位于一個(gè)導(dǎo)航視圖中，因此我們可以設(shè)置一個(gè)標(biāo)題。

這里有一個(gè)小的減速帶：我們的蛋糕頂部列表是一個(gè)字符串?dāng)?shù)組，但我們將用戶的選擇存儲(chǔ)為一個(gè)整數(shù)——我們?nèi)绾纹ヅ鋬烧?？一個(gè)簡(jiǎn)單的解決方案是使用indices數(shù)組的屬性，它為我們提供了每個(gè)項(xiàng)目的位置，然后我們可以將其用作數(shù)組索引。這對(duì)于可變數(shù)組來(lái)說(shuō)是個(gè)壞主意，因?yàn)閿?shù)組的順序可以隨時(shí)更改，但這里我們的數(shù)組順序永遠(yuǎn)不會(huì)更改，所以它是安全的。

現(xiàn)在將其放入ContentView的正文中：

我們表單的第二部分將包含三個(gè)分別綁定到specialRequestEnabled、extraFrosting和addSprinkles的撥動(dòng)開(kāi)關(guān)。然而，第二個(gè)和第三個(gè)開(kāi)關(guān)應(yīng)該只在第一個(gè)啟用時(shí)可見(jiàn)，所以我們將在一個(gè)條件下包裝。

現(xiàn)在添加第二部分：

繼續(xù)并再次運(yùn)行該應(yīng)用程序，并嘗試一下——注意我是如何將第一個(gè)開(kāi)關(guān)與animation()附加的修改器綁定在一起的，這樣第二個(gè)和第三個(gè)開(kāi)關(guān)就可以順利地滑入和滑出。

然而，還有另一個(gè)錯(cuò)誤，這次是我們自己造成的：如果我們啟用特殊請(qǐng)求，然后啟用“額外糖霜”和“額外灑水”中的一個(gè)或兩個(gè)，然后禁用特殊請(qǐng)求，我們之前的特殊請(qǐng)求選擇保持活動(dòng)狀態(tài).?這意味著如果我們重新啟用特殊請(qǐng)求，之前的特殊請(qǐng)求仍然有效。

如果你的代碼的每一層都知道這種問(wèn)題并不難解決 – 如果當(dāng)specialRequestEnabled設(shè)置為 false時(shí)，應(yīng)用程序、你的服務(wù)器、你的數(shù)據(jù)庫(kù)等都被編程為忽略值extraFrosting和addSprinkles。然而，一個(gè)更好的想法——一個(gè)更安全的想法——是確保在specialRequestEnabled設(shè)置為 false 時(shí)將extraFrosting和addSprinkles都重置為false。

我們可以通過(guò)將didSet屬性觀察器添加到specialRequestEnabled.?現(xiàn)在添加：

我們的第三部分是最簡(jiǎn)單的，因?yàn)樗皇?span id="2s04ssssssss" class="color-pink-02">NavigationLink指向下一個(gè)屏幕。我們沒(méi)有第二個(gè)屏幕，但我們可以足夠快地添加它：創(chuàng)建一個(gè)名為“AddressView”的新 SwiftUI 視圖，并為其提供一個(gè)order觀察對(duì)象屬性，如下所示：

我們很快就會(huì)使它更有用，但現(xiàn)在這意味著我們可以返回 ContentView.swift 并為我們的表單添加最后一部分。這將創(chuàng)建一個(gè)NavigationLink指向 AddressView，傳入當(dāng)前訂單對(duì)象。

請(qǐng)現(xiàn)在添加最后一部分：

這完成了我們的第一個(gè)屏幕，所以在我們繼續(xù)之前最后一次嘗試一下 - 你應(yīng)該能夠選擇你的蛋糕類(lèi)型，選擇一個(gè)數(shù)量，然后切換所有開(kāi)關(guān)就好了。

檢查有效地址

我們項(xiàng)目的第二步是讓用戶將他們的地址輸入到表單中，但作為其中的一部分，我們將添加一些驗(yàn)證——如果他們的地址看起來(lái)不錯(cuò)，我們直接繼續(xù)第三步。

我們可以通過(guò)向之前創(chuàng)建Form的結(jié)構(gòu)添加一個(gè)視圖來(lái)完成此操作，該AddressView結(jié)構(gòu)體將包含四個(gè)文本字段：名稱(chēng)、街道地址、城市和郵編。然后我們可以添加一個(gè)NavigationLink移動(dòng)到下一個(gè)屏幕，用戶將在該屏幕上看到他們的最終價(jià)格并可以結(jié)帳。

為了使這更容易理解，我們將首先添加一個(gè)名為 CheckoutView的新視圖，一旦用戶準(zhǔn)備好，地址視圖將推送到該視圖。這只是避免了我們現(xiàn)在必須放置一個(gè)占位符然后記得稍后再回來(lái)。

因此，創(chuàng)建一個(gè)名為的新 SwiftUI 視圖CheckoutView，并為其提供相同的Order觀察對(duì)象屬性和預(yù)覽，AddressView具有：

同樣，我們稍后會(huì)再談這個(gè)，但首先讓我們實(shí)現(xiàn)AddressView.?就像我說(shuō)的，這需要有一個(gè)表單，其中有四個(gè)文本字段綁定到我們Order對(duì)象的四個(gè)屬性，加上一個(gè)NavigationLink傳遞控制到我們的簽出視圖。

首先，我們需要四個(gè)新@Published屬性來(lái)存儲(chǔ)Order交貨細(xì)節(jié)：

現(xiàn)在用這個(gè)替換現(xiàn)有body的AddressView：

如你所見(jiàn)，這將我們的order對(duì)象傳遞到更深一層，到CheckoutView，這意味著我們現(xiàn)在有三個(gè)視圖指向相同的數(shù)據(jù)。

繼續(xù)并再次運(yùn)行應(yīng)用程序，因?yàn)槲蚁胱屇忝靼诪槭裁催@一切都很重要。在第一個(gè)屏幕上輸入一些數(shù)據(jù)，在第二個(gè)屏幕上輸入一些數(shù)據(jù)，然后嘗試導(dǎo)航回到開(kāi)頭然后前進(jìn)到結(jié)尾——也就是說(shuō)，回到第一個(gè)屏幕，然后點(diǎn)擊底部按鈕兩次以進(jìn)入結(jié)帳再次查看。

你應(yīng)該看到的是，無(wú)論你在哪個(gè)屏幕上，你輸入的所有數(shù)據(jù)都會(huì)保存下來(lái)。是的，這是為我們的數(shù)據(jù)使用類(lèi)的自然副作用，但它是我們應(yīng)用程序中的一個(gè)即時(shí)功能，無(wú)需執(zhí)行任何操作——如果我們使用了結(jié)構(gòu)體，那么如果我們移動(dòng)，我們輸入的任何地址詳細(xì)信息都會(huì)消失回到原來(lái)的視圖。如果你真的想為你的數(shù)據(jù)使用一個(gè)結(jié)構(gòu)，你應(yīng)該遵循我們?cè)陧?xiàng)目 7 中使用的相同的結(jié)構(gòu)內(nèi)部類(lèi)方法；當(dāng)你評(píng)估你的選擇時(shí)，記住這一點(diǎn)當(dāng)然是值得的。

現(xiàn)在AddressView可以了，是時(shí)候阻止用戶進(jìn)行結(jié)帳了，除非滿足某些條件。什么條件？嗯，這取決于我們。雖然我們可以為四個(gè)文本字段中的每一個(gè)都編寫(xiě)長(zhǎng)度檢查，但這常常會(huì)讓人們感到困惑——有些名字只有四個(gè)或五個(gè)字母，所以如果你嘗試添加長(zhǎng)度驗(yàn)證，你可能會(huì)不小心將人排除在外。

因此，我們只是要檢查訂單的name、streetAddress、city和zip屬性是否為空。我更喜歡在我的數(shù)據(jù)中添加這種復(fù)雜的檢查，這意味著你需要添加一個(gè)新的計(jì)算屬性給Order，像這樣：

我們現(xiàn)在可以將該條件與 SwiftUI 的disabled()修飾符結(jié)合使用——將其附加到任何視圖以及要檢查的條件，如果條件為真，視圖將停止響應(yīng)用戶交互。

在我們的例子中，我們要檢查的條件是我們剛剛編寫(xiě)的計(jì)算屬性，hasValidAddress。如果那是錯(cuò)誤的，那么包含我們的表單部分NavigationLink應(yīng)該被禁用，因?yàn)槲覀冃枰脩粝忍顚?xiě)他們的送貨詳細(xì)信息。

因此，將此修飾符添加到第二部分的末尾AddressView：

代碼應(yīng)如下所示：

現(xiàn)在，如果你運(yùn)行該應(yīng)用程序，你會(huì)看到所有四個(gè)地址字段都必須至少包含一個(gè)字符才能繼續(xù)。更好的是，SwiftUI 會(huì)在條件不為真時(shí)自動(dòng)使按鈕變灰，從而在交互和非交互時(shí)為用戶提供真正清晰的反饋。

準(zhǔn)備結(jié)帳

我們應(yīng)用程序的最后一個(gè)屏幕是CheckoutView，它實(shí)際上是一個(gè)分為兩半的故事：前半部分是基本的用戶界面，應(yīng)該不會(huì)給你帶來(lái)真正的挑戰(zhàn)；但下半部分是全新的：我們需要將我們的Order類(lèi)編碼為 JSON，通過(guò) Internet 發(fā)送它，并獲得響應(yīng)。

我們將盡快查看整個(gè)編碼和傳輸工作塊，但首先讓我們解決簡(jiǎn)單的部分：提供CheckoutView用戶界面。更具體地說(shuō)，我們將創(chuàng)建一個(gè)ScrollView帶有圖像、他們的訂單總價(jià)和一個(gè)下訂單按鈕來(lái)啟動(dòng)網(wǎng)絡(luò)。

對(duì)于圖像，我已經(jīng)將紙杯蛋糕圖像上傳到我的服務(wù)器，我們將使用AsyncImage進(jìn)行遠(yuǎn)程加載——我們可以將其存儲(chǔ)在應(yīng)用程序中，但擁有遠(yuǎn)程圖像意味著我們可以動(dòng)態(tài)地將其切換為季節(jié)性替代品和促銷(xiāo)活動(dòng)。

至于訂單成本，我們的數(shù)據(jù)中實(shí)際上沒(méi)有任何紙杯蛋糕的定價(jià)，所以我們可以發(fā)明一個(gè) - 這并不是說(shuō)我們真的要在這里向人們收費(fèi)。我們將使用的定價(jià)如下：

• 每個(gè)紙杯蛋糕的基本成本為 2 美元。

• 我們會(huì)為更復(fù)雜的蛋糕增加一點(diǎn)成本。

• 每個(gè)蛋糕額外的糖霜費(fèi)用為 1 美元。

• 添加灑將是每個(gè)蛋糕另外 50 美分。

我們可以將所有邏輯包裝在一個(gè)新的Order計(jì)算屬性中，如下所示：

實(shí)際視圖本身很簡(jiǎn)單：我們將VStack在垂直視圖中使用一個(gè)ScrollView，然后是我們的圖像、成本文本和下訂單按鈕。

我們將在一分鐘內(nèi)填寫(xiě)按鈕的操作，但首先讓我們完成基本布局——用這個(gè)替換現(xiàn)有CheckoutView的body：

到現(xiàn)在為止，這對(duì)你來(lái)說(shuō)應(yīng)該都是舊新聞了。但接下來(lái)是棘手的部分……