Swift UIにおけるデータの重要事項

Swift UIにおけるデータの重要事項

Appにおいてデータは難解な部分ですが、SwiftUIがあれば、試作から生産に至るまで、スムーズでデータ駆動型の経験を容易にすることが可能になります。 Source of Truthを保存し、シームレスにアップデートすることが可能な@State および@Bindingの2つのパワフルなツールについてお伝えします。また、ObservableObjectを使い、あなたのビューをデータモデルに接続する方法もご紹介します。トリッキーな挑戦、クールな新しい解決方法を専門家が直々にお話します！このセッションを有効に活用するためには、 SwiftUIに慣れていることが望ましいです。“App essentials in SwiftUI”および"Introduction to SwiftUI"をご覧ください。

リソース
- Model data
- - HDビデオ
  - SDビデオ
関連ビデオ

WWDC22
- UIKitでSwiftUIを使用する
WWDC21
- SwiftUIでの並行処理
- SwiftUIの徹底解説
WWDC20
ダウンロード

こんにちは WWDCへようこそ “Swift UIにおけるデータエッセンシャル” “Swift UIにおけるデータエッセンシャル” へようこそ SwiftUIチームエンジニアのカートです後ほど友人であり同僚のルカとラージも登場します今回は主に３つのテーマを扱いますまずSwiftUI Appのデータフローをお話しし StateやBindingなどにも触れます次にこうしたアイディアをどうやってビルドし Appのデータモデルを設計するかを説明します最後にデータモデルをAppに統合するためのテクニックをご紹介しますその中でSwiftUIビューのライフサイクルや便利な新機能についてもご説明します Swiftの値や参照型がSwiftUIのデータフローとどのように相互作用するのか理解が深まります私からはSwiftUIの基本的なデータフローを説明し新しいSwiftUIビューを作る際に考慮すべき質問についてお話ししますルカはブッククラブに夢中です彼はクラブメンバーの読書記録やメモが残せるAppが必要だと思いました私も読書が好きなので一緒にAppを作ることにしました
まず読んでいる本を表示するビューのプロトタイプを作ります SwiftUIで新しいビューを作成する時に考慮したい３つの重要な質問がありますジョブを行うために必要なデータは何か？今回の例ではブックカバーのサムネイルタイトル著者名進捗状況などが必要ですビューはデータをどのように処理するか？この例ではデータを表示するだけで変更はしませんデータはどこから来るか？これが“信頼できる情報源”になります今回の説明ではこのバッジを使って信頼できる情報源を示していきますこの信頼できる情報源に関する質問がデータモデルの設計において最も重要ですビューをビルドしながら考えてみましょう
さて今回のジョブには何のデータが必要でしょう？ bookの値が表紙の画像の名前タイトル著者名を示しています progressの値が表すのは進捗状況です次にビューがデータをどのように処理するかですデータを表示するだけなので “let”プロパティにします
そしてデータはどこから来るか？ブックカードがインスタンス化された時に superviewから渡されます信頼できる情報源はビュー階層のさらに上の方にあります superviewがブックカードのインスタンスを作成する時に信頼できる情報源を渡します superviewのbodyが実行する度に新しいブックカードがインスタンス化されます SwiftUIがレンダリングし終わるとインスタンスは消えます図を使って内部構造を可視化してみます左の四角はブックカードのビルドを構成する SwiftUIのビューを表しています右のカプセルはビューのレンダリングに使われるデータですセッション全体で同様の図を使います
次は今より少し面白いビューの例です本をタップすると読書の進捗状況を確認できる画面が出てきます “Update Progress”ボタンをタップすると進捗状況を更新したりメモが追加できますこんな感じです
親ビューとこのシートはどのように協働するのでしょうか
シートの表示方法に注目します “Update Progress”ボタンをタップすると presentEditorメソッドが呼び出されますメソッドがstateをいくつか変更しシートが表示されますシートの表示には何のデータが必要でしょうか？シートが提示されているか追跡するにはブール値が必要ですメモの追跡にはStringが進捗状況の把握にはDoubleが必要です関連性のあるプロパティが複数ある時には常に独自の構造体に引き出します
この方法にはBookViewを読みやすくする以外に２つの優れた点がありますカプセル化の利点がすべて得られます EditorConfigのプロパティの不変量は維持され独立したテストも可能ですまたEditorConfigは値のtypeなので EditorConfigのプロパティに変更があった場合 EditorConfig自体の変化として可視化できます次の質問はデータをどのように処理するかです “Update”ボタンをタップしたら isEditorPresentedを“True”にセットし進捗を現在の状況に合わせる必要があります StateをEditorConfig構造体に抽出したので更新の責任をEditorConfigに持たせられますそしてBookViewに EditorConfigへの作業を依頼するだけです
それから変更メソッドを EditorConfigに追加しますこんな感じです
ではデータはどこから来るのか？エディタコンフィギュレーションはこのビューではローカルなのでデータを渡す親ビューがありませんそこで信頼できる情報源をローカルに確立する必要があります SwiftUIの信頼できる情報源で最も簡単なのがStateです
このプロパティをStateにマークすると SwiftUIがストレージ管理を引き継ぎます図で見てみましょうここでも左側のボックスがビューを右側のカプセルがデータを表していますカプセルが太い線で囲まれているのは SwiftUIが管理しているデータという意味ですそれがなぜ重要かというとビューは一時的な存在だからです SwiftUIがレンダリングパスを完了した後には構造体自体は消えてしまいますしかしStateとしてマークされたプロパティは SwiftUIが管理してくれます次にこのビューのレンダリングが必要になった時には構造体を再構築して既存のストレージに再接続します
次にProgressEditorを見てみます ProgressEditorが必要なデータは何でしょう？ EditorConfigからのデータすべてですどのようにデータを処理するか？変更する必要があるのでvarを使いますデータはどこから来るでしょうか？この場合は興味深い例なので図に戻ります BookViewとProgressEditorに注目してください EditorConfigを通常のプロパティとして ProgressEditorに渡す場合を想定します EditorConfigは値のtypeなので Swiftはその値の新しいコピーを作成します ProgressEditorが行った変更はすべてこの新しいコピーのみを変更し SwiftUIが管理するオリジナルの値は変更されませんつまりProgressEditorがBookViewと通信することは許可されないのですでは次にProgressEditorに独自のStateプロパティを与えてみますこれは私たちが望むもののように思えます SwiftUIに新しいデータの管理をさせるということです
悲しいことにこれも間違いです Stateは信頼できる情報源を作り出します ProgressEditorによる変更はすべて自分のStateに対してなされ BookViewと共有しているものにではありません信頼できる情報源は１つなのです必要なのはBookViewからの信頼できる情報源への書き込みアクセスを ProgressEditorと共有する方法です SwiftUIでは書き込みアクセスを共有するために Bindingというツールを使います BookViewがEditorConfigへの Bindingを作成します既存データへの読み書きを参照しその参照をProgressEditorと共有します
このBindingを通して EditorConfigを更新することで ProgressEditorはBookViewと同じStateを変更していることになります SwiftUIはEditorConfigへの変更を通知 BookViewとProgressEditorがその値に依存関係を持っていると分かるので値が変更されるとビューを再レンダリングします
ProgressEditorはBookViewにデータを戻す必要がありますこのタスクにはBindingが適しているとお話ししましたコールのドル記号は StateからBindingを作成します Stateプロパティラッパーの見積値が Bindingだからです BindingプロパティラッパーはProgressEditorと BookView内のeditorConfigStateとの間にデータ依存関係を作成します SwiftUI管理の多くのビルトインは Bindingの取得もします例えばnoteに使われている新しいTextEditorコントロールは BindingをString値へ導きますドル記号の予測値アクセサーを使って EditorConfigの中にあるnoteに新しいBindingを付けることができます SwiftUIでは既存のBindingから新しいBindingをビルドできます BindingはStateだけのものではありません
SwiftUIでデータフローを始める際のコツをご紹介しました SwiftUIビューを追加する時には３つの質問を念頭に置いてくださいどんなデータが必要か？そのデータをどのように使うのか？そしてデータはどこから来るか？
変化しないデータにはプロパティを使うことができますビューが所有している過渡的なデータには @Stateを使用します別なビューが所有している変化するデータには @Bindingを使用します
次はデータモデルの設計についてルカから説明しましょう Stateがすべてではありませんありがとうカートこんにちは私はルカですカートはStateとBindingを使って UIの変更を促進する方法を説明しましたビューのコードを早く反復処理するにはこうしたツールが有効ですしかしStateは過渡的なUIステータス用に設計されたローカルなものですこのセクションではモデルの設計に話を移し SwiftUIが提供するすべてのツールを説明します一般的にAppのデータの保存と処理には UIとは別のデータモデルが使われていますある重要なポイントに達したらデータのライフサイクルを管理したり副作用の処理や既存のコンポーネントとの統合が必要になりますこのような時に使うのが ObservableObjectですまずObservableObjectがどのように定義されるか見てみましょうこれはクラス制約のあるプロトコルで参照型別でのみ適用されます ObjectWillChangeプロパティのみを要求します ObjectWillChangeはPublisherですその名のとおりObservableObjectプロトコルの意味的要件としてオブジェクトに変更を適用するより前に Publisherが表示されていなくてはなりませんデフォルトではPublisherはボックスから出してすぐに使えますただ必要ならカスタムして提供することができます例えばタイマーに特定のPublisherを使ったり既存のモデルで見られるKVOPublisherも使えます
プロトコルの次はObservableObjectを理解するためのメンタルモデルです TypeがObservableObjectに変換される時皆さんは信頼できる情報源を作成し変更にどう対応するか SwiftUIに教えていますつまりUIのレンダリングに必要なデータを定義しそのロジックを実行しているのです SwiftUIがデータとビューの間にある依存関係を確立します図の青いボックスがビューです SwiftUIはこの依存関係を使用して自動的にビューの一貫性を保ちデータを正しく再現します
ObservableObjectをデータ依存性サーフェスとして考えてみますこれはビューにデータを公開する部分ですが必ずしも完全なモデルである必要はありませんこのようにObservableObjectを考えれば必ずしもデータモデルでなくてもよいのですストレージやライフサイクルからデータを切り離すことができます値の型を使ってデータをモデル化できそのライフサイクルと副作用を参照型で管理できます例えばデータモデル全体を一元管理する単一のObservableObjectを持つことができこの図のようにすべてのビューで共有ができますこうすればすべてのロジックを１つの場所にまとめ App内であり得る状態や変更をすべて簡単に推論することができますまたはデータモデルに特定の投影をもたらす ObservableObjectを複数持つことで Appの一部にフォーカスできます必要なデータだけ公開するよう設計されているデータモデルをですこれが効果的なのはデータモデルが複雑な時に厳密にスコープされた無効化を Appの一部で提供したい場合です先ほど構築していたAppに戻り実際の適用方法を見てみましょうカートが作業していたビューに戻りますこれは読書の進捗状況を更新できるビューで読書会で面白いと思った事をメモすることもできます
カートはprogress sheetのデータに焦点を当てましたこのビューに必要な残りのデータに注目し ObservableObjectを使って豊富な機能を追加してみますディスクへのデータ保存や iCloudとの同期などです
ObservableObjectに準拠した CurrentlyReadingという新しいクラスを作成し本とその進捗状況を保存しますこれはデータを表示したり変更に対応するためにビューに公開するモデルの一部です特定の本は変わることはないのでプロパティはletにします進捗状況を更新すると UIがそれに反応するようにしますこれは@Publishedプロパティラッパーで progressプロパティに注釈を付けると可能です @Publishedの仕組みを見てみましょう @PublishedはPublisherを公開することでプロパティを観測可能にするプロパティラッパーですほとんどのモデルでは ObservableObjectに準拠し変更の可能性があるプロパティに @Publishedを追加するだけで完了ですビューとデータの同期について心配する必要はありませんデフォルトのObservableObject publisherで @Publishedを使う場合値が変化する直前にシステムが配信し自動的に無効化が実行されます高度なユースケースでは @Publishedの予測値はPublisherで反応性のあるストリームを構築できます
データモデルを設計する際に考慮すべき３つの質問を再考してみましょう ObservableObjectの場合２つ目の質問の答えはとても簡単です常に変化のしやすさを推測します今度は残りの２つの質問に対する答えを考えてみましょうモデルは定義したので次はそれをビューで使う必要があります SwiftUIにはObservableObjectへの依存関係を作成するためにビューで使用できるプロパティラッパーが３つありますそのツールとは@ObservedObject 今年新しくなった@StateObject そして@EnvironmentObjectですまずはObservedObjectを見てみましょう ObservedObjectはプロパティラッパーで ObservableObjectに準拠したtypeを持つビューのプロパティに注釈を付ける際に使いますこれを使いビューの依存関係としてプロパティの追跡開始をSwiftUIに通知しますビューがジョブを行うのに必要なデータを定義しています
これは最もシンプルで柔軟性があるツールです ObservedObjectは提供されるインスタンスの所有権を取得するわけではないのでライフサイクルの管理責任は皆さんにあります Appでの使い方を見てみましょう BookViewは本とこれまでに記録した全進捗状況を表示するビューですこの画面から読書の進捗状況の更新もできます currentlyReadingというtypeのプロパティを追加します @ObservedObjectプロパティラッパーで今作成したtypeに注釈を付けますこのプロパティに割り当てられたインスタンスがこのビューの信頼できる情報源ですこれでビュー本体のモデルを読み込めるようになりました SwiftUIではビューは常に最新の状態になります必須のコードもビューを同期するために管理するイベントもありませんデータからビューの書き方を宣言的に書き込みするだけであとはSwiftUIが全部やってくれます SwiftUIのアップデートライフサイクルについてこの後ラージから詳しく説明しますがその前にSwiftUIが何をしているのか裏側をお見せします ObservedObjectを使用すると SwiftUIはその特定の@ObservableObjectの objectWillChangeを購読しますこれでObservableObjectが変更される度にそれに依存するすべてのビューが更新されることになりますなぜ更新“される”ではなく “されることになる”なのでしょうかそれは SwiftUIは変更しようとしている時を知りすべての変更を１回の更新にまとめるからですしかしどう変更するのでしょう？ SwiftUIで提供されるUIコンポーネントの多くはデータの一部へのBindingを取りますここまでの説明の中でコンポーネントに同様の設計をする例をご紹介しましたこれはSwiftUIの基本的な設計原則の１つですコンポーネントはBindingを受け入れることでデータの一部への読み書きアクセスが可能になり単一の信頼できる情報源も維持できます
StateからBindingを派生する方法をカートがお見せしました同様のことがObservableObjectでもとても簡単にできます
ObservableObject上の値のtypeのプロパティから Bindingを取得することができますそれには変数の前にドル記号の接頭辞を追加しプロパティにアクセスするだけですブッククラブAppで具体的に見てみましょう本の最終章を読み終えると大きな満足感を得られるので何か大きな表示でマークを付けたいと思います思いついたのは“この本を読み終えた”というトグルをタップすることですまず変更を加えるのはモデルです新しいプロパティの “isFinished”を追加し @Publishedで注釈付けすることで値が変わればUIに変更が反映されるようにします BookViewがどう変わるか見てみましょう Label付きのToggleを追加して読み終えたらマークできるようにします Toggleには現在の状況を表示するための Bindingが必要でタップされると値が変更されます currentlyReadingにドル記号の接頭辞を追加し isFinishedプロパティにアクセスするだけで isFinishedにBindingを与えることができますこれでユーザーがトグルを操作する度に currentlyReadingが更新され SwiftUIがそれに依存するすべてのビューを更新します例えばこのビューでは本を読み終えたら進捗状況を更新するボタンを無効にしましょう App全体で表示されるブックカバーはネットワークから非同期にロードさせたいですつまり画面に表示される直前です高負荷なリソースのため生かすのはビューが表示されている間だけにしたいのです一般的にObservableObjectのライフサイクルはビューに結びつけたいと思うでしょう Stateと同様です ObservedObjectにはそのObservableObjectのライフサイクルがありませんそこでより使いやすいツールを用意しました
それが今年新しくなった@StateObjectです @StateObjectでプロパティに注釈を付ける時は初期値を指定しますするとSwiftUIは初回にbodyを実行する直前にその値をインスタンス化しますビューのライフサイクル全体でオブジェクトを存続させるのですこれはすごい追加機能です使い方を実際に見てみましょう特定の画像を名前でロードするための CoverImageLoaderクラスを作成してみましょうここではこのクラスのスケルトンを示しているだけです ObservableObjectにした方法は示しておらず画像を保持するプロパティに @Publishedを注釈付けしました一旦画像を取得すると SwiftUIは自動的にビューを更新しますビューではCoverImageLoaderを使うことができるのでプロパティに@StateObjectを注釈付けしますビューが作成される時に CoverImageLoaderはインスタンス化されませんその代わり bodyが実行される直前にインスタンス化されビューのライフサイクル全体のために維持されますあるビューがもはや不要になると SwiftUIは想定どおり CoverImageLoaderをリリースします OnDisappearをいじる必要はもうありませんその代わりObservableObjectのライフタイムを使ってリソースを管理することができます SwiftUIではビューが非常に低負荷なのですこれを主要なカプセル化メカニズムにすることや理解しやすく再利用しやすい小さなビューを作成することをお勧めしますしかしそうすると最終的にこの図のように深くて広いビューの階層になるかもしれませんこれをデータフローの観点から見てみるとビュー階層の上位に ObservableObjectを作成し同じインスタンスを多くのビューに渡す必要があるかもしれません時々ObservableObjectを離れたサブビューで使用する必要がありますしかしデータを必要としないビューにも渡して下すことは面倒であり多くのボイラプレートを巻き込んでしまうことがあります幸いなことにこの問題を解決する方法が EnvironmentObjectにあります EnvironmentObjectはビュー修飾子でもあり同時にプロパティラッパーでもあります ObservableObjectを投入したい親ビューでそのビュー修飾子を使用しますそして特定ObservableObjectのインスタンスを読みたいすべてのビューでプロパティラッパーを使用しますフレームワークは必要な場所でその値を渡しそれが読み込まれた場所だけ依存関係として追跡しますこのパートで見てきたのは ObservableObjectでモデルを設計する方法や SwiftUIであなたの要求に沿うアーキテクチャをビルドするための基礎的primitiveでした
またビューとデータの一部の間に依存関係を作成する方法や新しい@StateObject プロパティラッパーを使って @ObservableObjectのライフサイクルをビューに結びつける方法を見てきましたそして最後は@EnvironmentObjectを使ったビュー階層内にObservableObjectを流すのに便利な方法ですではラージに引き継ぎます SwiftUIのビューのライフサイクルとパフォーマンスとの関係性や副作用への対処法と新しいツールを深く掘り下げてくれますありがとうございました素敵なWWDCをお楽しみくださいありがとう　ルカ SwiftUIでデータを使い始める方法とすばらしいモデルを設計する方法が分かったかと思いますさて私からは最高のパフォーマンスを発揮するための設計方法と信頼できる情報源を選ぶ際さらに考慮すべきことをお話しますまず始めに SwiftUIシステムにおけるビューとその役割についてお話しましょうビューは単純にUIの一部の定義です SwiftUIはこの定義を使って適切なレンダリングを作成します SwiftUIはビューのIDとライフタイムを管理しますそしてビューはUIの一部を定義するため軽量で安いものでなければなりませんブッククラブAppでは他のAppと同様に画面上のすべてのものがビューですビューのライフタイムはそれを定義する構造体のライフタイムと別物であることに注目してください Viewプロトコルに準拠して作成した構造体は実はライフタイムが非常に短いのです SwiftUIがレンダリングを作成したらそれはなくなってしまいますビューを軽量化することの重要性について図を使って説明してみましょう
この図はSwiftUIの更新ライフサイクルを示しています一番上のUIからはじめます反時計回りに移動してあるイベントが発生すると何らかのクロージャやアクションが実行されますその結果信頼できる情報源の変更が起こります
そうして一旦信頼できる情報源を変更してからビューの新しいコピーを取得しレンダリングに使用しますこのレンダリングがUIですこれが基本ですこの図は少し後でまたお見せします今ここでは単純化してみましょうそしてもう少しだいぶいいですね
その名の通りこのライフサイクルは円です Appの実行中は何度も繰り返しますこのサイクルはパフォーマンスにとっても本当に重要ですそして理想ではこのようにサイクルがスムーズに進むのです
しかしこれらのポイントで高い負荷のブロッキング作業が行われていると Appのパフォーマンスが低下してしまいます
私たちはこれをスローアップデートと呼んでいますつまりフレームを落としたり Appがハングしたりする可能性がありますスローアップデートを避けるにはどうしたらいいでしょうか？
スローアップデートを避けるために最初にできることの一つとしてビューの初期化の負荷を楽にできるか確認しますビューの本体は副作用のない純粋な関数でなければなりませんつまりビューの記述を作成して返すだけでよいのですディスパッチや他の作業は必要ありませんただいくつかビューを作成して次に進みましょう bodyがいつどのくらいの頻度で呼び出されるかの仮定条件の作成は避けましょう SwiftUIは時々かなり賢く仮定があるとそれに伴って bodyを呼び出さないかもしれません
Bodyの負荷が軽いことの重要性を図示するので例を見てみましょう
これはCurrently Readingのリストがどのように見えるかを単純化した例です ReadingListViewerでは bodyをNavigationViewとして定義しその中にReadingListを入れますそれからReadingListで @ObservedObjectを使ってデータを生成しますかなり理にかなって見えますが実はここにバグが潜んでいますお分かりですか？
ReadingListViewerのbodyが作成される度 ReadingListStoreの割り当てが何度も繰り返されることが分かりますこれがスローアップデートの原因かもしれませんビュー構造体には定義されたライフタイムがないということを思い出してくださいこれを書くと実際には毎回オブジェクトの新しいコピーを作成することになってしまいます割り当てが何度も繰り返されるのは負荷も時間もかかります毎回オブジェクトがリセットされるためデータロスも発生します問題が判明しましたがどうやって解決すればいいのでしょうか？今まではどこか別の場所でモデルを作成して渡す必要がありましたしかしインラインで行うことができたらすばらしいのでは？今年はこの問題を解決するツールである @StateObjectを紹介できますそしてルカが先ほど説明したように @StateObjectはSwiftUIがObservableObjectを正しい時にインスタンス化できるようにしますそのため不必要に多くの割り当てが発生せずまたデータを失うこともありませんつまりすばらしいパフォーマンスと正確性を得ることができるということですここで新たな信頼できる情報源を宣言しているのでそのバッジを貼っておきましょうではまた図を見てみましょうそして高度にしますいいですね注目すべき点は左上にイベントの複数のソースがあることです Appがボタンのタップなどのユーザーの相互作用で生成されたイベントに反応したりあるいはタイマーや通知といった配信の停止に反応したりするかもしれませんイベントのトリガーに関係なくサイクルは同じです信頼できる情報源を変更させビューを更新し新しいレンダリングを生成しますこれらのトリガーはイベントソースと呼ばれこれらはビューの変化を加速させます先ほども述べたようにユーザーの相互作用やタイマーなどのパブリッシャーがよい例ですそして今年は新しく環境やbindingの変更などのイベントに反応したり URLやユーザーアクティビティを扱う新しい方法がありますこれらの修飾子それぞれがパブリッシャーや比較値などのパラメータを取るほかクロージャも取ります SwiftUIは適切なタイミングでクロージャを実行してスローアップデートを回避し bodyの負荷を安く保つのに役立ちますしかしSwiftUIはこれらのクロージャをメインスレッド上で実行しますそのため高負荷な作業が必要な場合はバックグラウンドキューへのディスパッチを検討してみてください詳細を知りたい方はドキュメントでの確認をお勧めします以上がスローアップデートを回避する方法と優れたパフォーマンスの実現のための設計方法でした次に例の３つの質問に戻りましょう
最初の２つの質問は大体説明しましたが３つ目は簡単ではありませんこの質問に答える時あなたは使用する信頼できる情報源を決定していることになりますこれは難しい質問ですここに正解はありませんので手助けとして考慮すべきことを説明したいと思います
重要な問題は誰がデータを所有しているのかということですデータを使用しているのはビューなのかそれともそのビューの祖先なのでしょうかもしかしたらAppの別のサブシステムかもしれません
ここにガイドラインがあります前述したように共通の祖先とデータを共有すべきですまたObservableObject のビュー所有の信頼できる情報源として @StateObject をうまく使うことです最後に App内にグローバルデータを配置することを考えてくださいこれについては次で説明します
次にデータのライフタイムについて説明しますデータのライフタイムをViewsやScenesやAppsに結びつけることについてです SwiftUIのシーンとAppについては “App Essentials in SwiftUI”のセッションを参照してくださいまずViewsから始めましょう
この話でご覧になった通りビューはデータのライフタイムを関連付けるためのすばらしいツールですそして今日説明したすべてのプロパティラッパーはビューで動きます StateとStateObjectのプロパティラッパーを使用してデータのライフタイムとビューのライフタイムを結びつけられます次にscenesについて説明しましょう SwiftUIのscenesはそれぞれ独自のビューツリーを持っているのでツリーのルートから重要なデータをぶら下げることができます例えばウィンドウグループ内のビューに信頼できる情報源を置くことができますそうすることでウィンドウグループが作成する sceneの各インスタンスはそれ自身の独立した信頼できる情報源を持つことができますそして基礎となるデータモデルのレンズとして機能しますこれは複数のウィンドウを使用した場合に効果的ですご覧のように２つのscenesは同じ基礎となるデータを表す独立したUIのstatesを持ちますこれでルカは２つのオンラインブッククラブを同時に行くことができるようになりました次にAppsについて話しましょう Appsは今年のSwiftUIの強力な新しいツールで SwiftUIだけでApp全体を書くことができますしかしAppsのすばらしい点はビューで行うのと同じように App内でStateや他の信頼できる情報源を使用できることです例をお見せしましょう @StateObjectプロパティラッパーを使って App全体のグローバルブックモデルを作成します変更される度にAppのすべてのscenesが更新され結果的にすべてのビューが更新されますそしてこれを書くことでApp全体の信頼できる情報源を作成しました信頼できる情報源の置く場所を検討する時本当のグローバルデータを表示する場合は App内に置くとよいでしょう
データのライフタイムは重要ですしかしそのライフタイムはその信頼できる情報源のライフタイムと結びついており私たちはStateやStateObjectや Constantのようなツールを使用してきましたしかしこれらのツールにはプロセスのライフタイムに縛られるという制限がありますつまりAppが強制終了したりデバイスが再起動したりした場合 Stateは戻ってきませんこの問題を解決するために今年はストレージを導入しましたライフタイムを延長しかつ自動的に保存および復元できるものですただしこれらはモデルには該当しませんむしろモデルと一緒に使う軽量な貯蔵庫です
SceneStorageから見始めていきましょう
SceneStorageはsceneごとにスコープされたプロパティラッパーで SwiftUIによって完全に管理されたデータの読み書きを行いますビュー内からのみアクセス可能なので Appの現在の状態に関する軽量な情報を保存するのに最適な候補となります例を見てみましょう
これは先ほどのブッククラブAppで２つのシーンを横に並べたものです SceneStorageを使用する際に最初に考えるべきことは本当に復元が必要かということです今回の場合保存と復元に必要なのは選択範囲だけですブックの名前や進捗状況ノートはすべてモデルに蓄積されているのでそれらを保存して復元する必要はありませんではコードに移りましょう選択したStateの保存や復元のために SceneStorageを使用する方法です保存しているデータの種類に合わせて必ず固有のキーを渡しますそうするとStateと同じように使うことができます SwiftUIが私たちの代わりに自動的に値を保存して復元してくれますこれはStateと似た挙動をするので今回は事実上すでに新しい信頼できる情報源をここに宣言しますそのためこれがシーン全体の信頼できる情報源となりますこれでデバイスの再起動やシステムがあるシーンを保存しているリソースを取り戻す時も次の起動時にデータを利用できるようになりますこれでルカはブッククラブの活動を前に閉じたところから取り出すことが可能ですさてSceneStorageの動作の後は AppStorage についても説明したいと思いますこれはAppに焦点をあてたグローバルストレージでユーザーのデフォルトを使って保持されるものですどこからでも利用できるので App内からでもビュー内からでもアクセスできます AppStorageはユーザーデフォルトと同様に設定などの小さなデータを保存するのに非常に便利です私たちのブッククラブAppでも設定をいくつか導入することにしましたこれを達成するために AppStorageを使用する方法を見てみましょう設定ビューでは AppStorageプロパティラッパーを追加してキーを与えるだけですデフォルトでは標準ユーザデフォルトを使用していますが必要に応じてカスタマイズすることができます詳細についてはドキュメントを参照してくださいこの場合ここでは２つの設定のそれぞれに対してAppStorageを設定しますこれらは独立したデータなのでそれぞれにユニークなキーを与えます SceneStorageと AppStorageを使用する際にはデータ固有の部分に固有なキーを持たせることが重要ですそして他のプロパティラッパーと同様に信頼できる情報源でもあり Toggleで使用するためのbindingを得られることを意味しますこれでデータが変わる度に自動的に保存されユーザデフォルトから復元されるようになりました今日はプロセスのライフタイムとライフタイムの延長に使えるツールを見ました各ツールを使ってここでUIレベルの Stateを蓄積しますストレージのtypeについては永続性が無限なわけではないので何でも一緒に蓄積しないようにしてくださいもう１つ ObservableObjectというツールを紹介したいと思います ObservableObjectは非常に柔軟に設計されているのでこれを使って非常にカスタムしやすい挙動を実現することができサーバや他のサービスでのデータバックアップなどが可能ですこれらのツールを組み合わせることでニーズに最も適したものを選択する自由度の高いファミリーを形成しています今日は多くのツールとその使用法を見てきましたが主な残課題とは１つだけで万能なツールは存在しないということですそれぞれに特徴があるので典型的なAppはさまざまなツールを使用しているわけです私たちがブッククラブAppでそれを実行してきましたねボタンと進捗状況ビューには Stateを使用していますが Currently ReadingモデルにはStateObject 選択範囲にはSceneStorage 設定にはAppStorageを使用していますデータのプロパティや正しく信頼できる情報源は何かと考えることが重要ですそして煩雑さを減らすために信頼できる情報源の数を制限してみてください最後に再利用可能なコンポーネントをビルドする方法としてbindingを活用しましょう bindingは信頼できる情報源に全く依存しないのでクリーンな抽象化をビルドするための強力なツールとなることを覚えていてください学んだ要点を生かしすばらしいモデルをビルドしてくださいありがとうございました
すばらしいWWDCをお楽しみください

struct BookCard : View {
    let book: Book
    let progress: Double

    var body: some View {
        HStack {
            Cover(book.coverName)
            VStack(alignment: .leading) {
                TitleText(book.title)
                AuthorText(book.author)
            }
            Spacer()
            RingProgressView(value: progress)              
        }
    }
}

3:35 - EditorConfig

struct EditorConfig {
    var isEditorPresented = false
    var note = ""
    var progress: Double = 0
    mutating func present(initialProgress: Double) {
        progress = initialProgress
        note = ""
        isEditorPresented = true
    }
}
struct BookView: View {
    @State private var editorConfig = EditorConfig()
    func presentEditor() { editorConfig.present(…) }
    var body: some View {
        …
        Button(action: presentEditor) { … }
        …
    }
}

5:59 - ProgressEditor

struct EditorConfig {
    var isEditorPresented = false
    var note = ""
    var progress: Double = 0
}
struct BookView: View {
    @State private var editorConfig = EditorConfig()
    var body: some View {
        …
        ProgressEditor(editorConfig: $editorConfig)
        …
    }
}

struct ProgressEditor: View {
    @Binding var editorConfig: EditorConfig
    …
        TextEditor($editorConfig.note)
    …
}

13:15 - CurrentlyReading

/// The current reading progress for a specific book.
class CurrentlyReading: ObservableObject {
    let book: Book
    @Published var progress: ReadingProgress

    // …
}

struct ReadingProgress {
    struct Entry : Identifiable {
        let id: UUID
        let progress: Double
        let time: Date
        let note: String?
    }

    var entries: [Entry]
}

15:36 - BookView

struct BookView: View {
    @ObservedObject var currentlyReading: CurrentlyReading

    var body: some View {
        VStack {
            BookCard(
                currentlyReading: currentlyReading)

            //…

            ProgressDetailsList(
                progress: currentlyReading.progress)
        }
    }
}

17:50 - CurrentlyReading with isFinished

class CurrentlyReading: ObservableObject {
    let book: Book
    @Published var progress = ReadingProgress()
    @Published var isFinished = false

    var currentProgress: Double {
        isFinished ? 1.0 : progress.progress
    }
}

18:21 - BookView with Toggle

struct BookView: View {
    @ObservedObject var currentlyReading: CurrentlyReading

    var body: some View {
        VStack {
            BookCard(
                currentlyReading: currentlyReading)

            HStack {
                Button(action: presentEditor) { /* … */ }
                    .disabled(currentlyReading.isFinished)

                Toggle(
                    isOn: $currentlyReading.isFinished
                ) {
                    Label(
                        "I'm Done",
                        systemImage: "checkmark.circle.fill")
                }
            }
            //…
        }
    }
}

19:58 - CoverImageLoader

class CoverImageLoader: ObservableObject {
    @Published public private(set) var image: Image? = nil

    func load(_ name: String) {
        // …
    }

    func cancel() {
        // …
    }

    deinit {
        cancel()
    }
}

20:20 - BookCoverView

struct BookCoverView: View {
    @StateObject var loader = CoverImageLoader()

    var coverName: String
    var size: CGFloat

    var body: some View {
        CoverImage(loader.image, size: size)
            .onAppear { loader.load(coverName) }
    }
}

25:36 - ReadingListViewer (Bad)

struct ReadingListViewer: View {
    var body: some View {
        NavigationView {
            ReadingList()
            Placeholder()
        }
    }
}

struct ReadingList: View {
    @ObservedObject var store = ReadingListStore()

    var body: some View {
        // ...
    }
}

26:39 - ReadingListViewer (Good)

struct ReadingListViewer: View {
    var body: some View {
        NavigationView {
            ReadingList()
            Placeholder()
        }
    }
}

struct ReadingList: View {
    @StateObject var store = ReadingListStore()

    var body: some View {
        // ...
    }
}

30:52 - App-wide Source of Truth

@main
struct BookClubApp: App {
    @StateObject private var store = ReadingListStore()

    var body: some Scene {
        WindowGroup {
            ReadingListViewer(store: store)
        }
    }
}

32:43 - SceneStorage

struct ReadingListViewer: View {
    @SceneStorage("selection") var selection: String?

    var body: some View {
        NavigationView {
            ReadingList(selection: $selection)
            BookDetailPlaceholder()
        }
    }
}

33:49 - AppStorage

struct BookClubSettings: View {
    @AppStorage("updateArtwork") private var updateArtwork = true
    @AppStorage("syncProgress") private var syncProgress = true

    var body: some View {
        Form {
            Toggle(isOn: $updateArtwork) {
                //...
            }

            Toggle(isOn: $syncProgress) {
                //...
            }
        }
    }
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC22

WWDC21

WWDC20