您好，歡迎來到WWDC。
開場白
嗨，大家好。我叫蒂娜。我在SwiftUI上工作。今天，我將討論使用SwiftUI構建支持文檔的應用程序。
首先是什麼文件
首先是什麼文件。人們一直使用macOS iPadOS和iOS上的Finder和Files應用程序管理文件。他們可以使用標籤，雲文件提供程序和外部存儲設備等功能根據需要組織項目。他們期望能夠使用允許他們無縫地就地打開，查看和編輯這些文件的應用程序。這包括能夠在原始文檔上進行更改，所有支持打開文件的應用程序都可以訪問該更改。這與將這些文件導入到某個由應用程序管理的數據庫中的應用程序形成對比。添加導入的文檔時，您正在編輯原始文檔的副本，而原始文檔未更改。像Pixelmator這樣的專業應用程序不僅允許用戶執行就地打開文件管理，而且還啓用強大的編輯功能，包括一次打開多個文件。
Pixelmator，Keynote和Final Cut Pro等應用程序中的幾乎所有功能都集中於允許用戶執行此文檔管理。我們通常將這些基於文檔的應用程序稱爲該行爲的指示。但是打開文檔是您的應用程序可以支持的功能，而不必像Xcode這樣的完全基於文檔的應用程序具有其他UI和其他功能，而其文檔支持之外，而Mail和Console之類的應用程序主要表現爲非基於文檔的外觀，但支持打開其他文檔，例如eml文件或崩潰報告。
SwiftUI應用程序組成
SwiftUI應用程序由應用程序，場景和視圖組成。通過使用另一個稱爲文檔組的同步類型來完成對文檔的支持。一個簡單的文本編輯應用程序如下所示。
在您的應用程序中使用DocumentGroup時，您聲明您的應用程序支持就地打開和管理此類文檔，如SwiftUI談話中的App Essentials中所示。我們的代碼結構與應用程序的所有權層次結構匹配。在這種情況下，我們的應用程序包含一個文檔組場景，該場景能夠打開該文檔內容的多個窗口，並且作爲組成元素，它可以支持不同類型的多個文檔組或一個窗口組和一個文檔組。
您可以將這些場景組合到您的應用程序中，SwiftUI會自動爲您的應用程序提供這些場景的預期平臺行爲。其中包括特定於Mac和文檔瀏覽器上文檔應用程序狀態跟蹤和切換的標準UI元素，以及iOS上具有搜索字段和共享功能的導航欄。您將用最少的代碼獲得所有這些信息。
讓我們使用DocumentGroup API構建一些東西
現在，讓我們使用DocumentGroup API構建一些東西。因此，我在iPad背景上使用SwiftUI製作了一個繪圖應用程序的原型。我目前有一塊畫布，可以在其中添加不同顏色的形狀並更改其形狀。我認爲它運作良好。因此，我想將其製作成可以保存和管理圖形的應用程序。讓我們看看如何做到這一點。
讓我們打開Xcode並創建一個基於文檔的應用程序。我想讓它同時在macOS和iOS上運行。因此，我將選擇多平臺模板。我將其稱爲形狀編輯。這已經帶有一些模板。讓我們嘗試構建並運行它。
現在，我們有一個文本編輯應用程序，其中包含我們前面提到的所有文檔支持功能。現在，在深入探討之前，讓我們看一下項目的設置。
配置項目
我現在將重點關注macOS目標，但是我們將要使用的配置同時適用於iOS和macOS目標。讓我們看一下info.plist。 Xcode爲基於文檔的應用程序添加了文檔類型部分。該標識符字段中的值是統一類型標識符。系統使用該標識符將文件與您的應用程序相關聯，因此當系統上看到一個文檔時，它便知道在您的應用程序中打開此類文檔。在此，此標識符被聲明爲導入類型。之所以導入它，是因爲明文類型是由另一方聲明的，因此我們導入這些類型的聲明是爲了告訴系統應用程序知道它。對於我們的應用程序，我們將聲明自己的類型。所以，讓我們回到這裏。並創建一個。由於是我們發明的一種類型，因此需要導出類型聲明以告知系統我們是該類型的權威所有者。爲此，我們填寫了導出的類型標識符部分。讓我們對其進行描述。
我們將圖形存儲爲二進制數據，以使其符合公共數據和公共內容。我還將分配一個擴展名。
這就是我們需要在這裏進行更改的所有內容。讓我們看一下主要功能。
爲我們聲明瞭一種文檔類型ShapeEditDocument，它已經在創建新文檔時將要使用的文檔類型和基礎文檔都傳遞給了文檔組，閉包參數的document屬性是一個綁定，爲我們提供了對基礎對象的讀寫訪問權限數據模型，它是此文本編輯應用程序中的文本。文檔組支持就地打開，該綁定使SwiftUI知道何時更新了文本，以便它負責註冊撤消和弄髒文檔狀態。讓我們看一下內容視圖，它是呈現文檔的默認視圖。它包含一個文本編輯器。由於我們要創建一個形狀繪製應用程序，因此我們將其替換爲用戶可以繪製的畫布。但是我們稍後再講。讓我們看一下形狀編輯文檔。
它是一種符合FileDocument協議的值類型，該協議是磁盤上文檔的表示形式。首先，我們將定義可讀的內容類型。它是UT類型的數組，統一類型標識符。 SwiftUI使用它來識別您的用戶想要打開的文檔類型，並且僅允許此處定義的文檔類型。示例文本在此處定義。
這應該與我們之前在目標info.plist的“文檔類型”部分中輸入的內容匹配。因此，讓我們進行更改。注意兩個聲明之間的區別。在這裏，我們使用exportAs：構造函數。之前我們使用導入到此構造函數的方法是，導入的類型是一個計算變量，因爲它是導入的。這意味着其價值會隨着安裝或卸載應用程序的時間而變化。在這裏，我們使用導出的類型，以便可以將其聲明爲常量以獲得更多信息。請參閱開發人員網站上UTType的文檔。現在讓我們更改一下。以我們自己的類型。接下來，讓我們實現給定文件包裝器和內容類型的文檔的初始化。我們不需要此代碼，因此我將其刪除。
內容類型參數始終是應用程序支持的類型，並且有幾種方法可以執行此操作。在這裏，我們將使用我們的JSON解碼器。並且要使用JSON解碼器，該類型需要符合callable。我們還需要實現將文檔寫出爲指定類型的文件。
我們也不需要這些。因此，我還將刪除它們FileWrapper是序列化的目標。這是一個inout參數，我們可以創建一個新的FileWrapper或對其進行更新。再次，有幾種方法可以做到這一點，我們將使用JSON編碼器。
這就是我們要做的一切事情，以符合文件文檔協議。注意，我們在這裏使用值類型。這意味着您將獲得使用結構的所有好處，包括寫時複製行爲，並且應用程序可以在用戶仍在繪圖時開始保存。
現在，有了適當的文檔支持，讓我們將原型畫布代碼添加到項目中。我們有一個圖形類型，用於定義形狀的屬性和用於顯示形狀的畫布視圖。讓我們將文檔中的數據類型從文本更改爲圖形類型。
我們還添加一些初始形狀。讓我們用畫布替換掉文本編輯器。我們都準備好了。讓我們運行它。我們有一個支持文檔的繪圖應用程序。我可以保存
