SwiftとSwiftUIへのCore Dataの並行処理の導入

SwiftとSwiftUIへのCore Dataの並行処理の導入

Core DataがSwift 5.5の新しい並行処理機能をどのように採用し、より簡潔で効率的、かつ安全な非同期コードを実現しているかを紹介します。並行処理で動作するようにApp内のCore Dataを更新する方法を示し、SwiftとSwiftUIでの作業をより表現力豊かで強力なものにするフレームワーク全体での他の多くの改善点を詳しく説明します。

リソース
- Loading and Displaying a Large Data Feed
- - HDビデオ
  - SDビデオ
関連ビデオ

WWDC21
ダウンロード

♪ ♪ 皆さん　こんにちは私はCore Dataチームのマイケル・リーヒューです本日は Core DataとSwiftの機能が目覚ましく向上したことについてお話できることを嬉しく思いますまずCore DataがAppleの全プラットフォームにおいてデータの永続化というお客様のニーズを満たすことをお話しますそして Core Dataに新たに採用した Swiftランタイムの同時実行処理における方法を　議論を交えてお届けします次に　Swiftでより表現豊かなコードを作成するための Core DataAPIの改善点について紹介します最後に 2020年に既存のSwiftUIサポートに追加した Core Dataの動的機能を紹介して締めくくろうと思いますでは始めましょうどのようなAppleのプラットフォームの開発にも　まず Appが必要ですそのAppはどこかの時点でユーザーデータの保管が必要となりますそこで最適な選択は Core Dataを使うことです Core Dataは特徴豊かな Appleのフレームワークでユーザーデータを強固かつ機能豊かな状態で長期間保持したい開発者に向けたものですこのフレームワークはメモリ内での表現方法からストレージ内でのモデル化方法など複雑な処理を多くの担いユーザーデータを適切に管理しますこのフレームワークはまたメモリの使用量や待ち時間などのランタイムの重要事項を管理しますこのフレームワークの機能は拡張も可能です例えば簡単なローカルストアから始めて機能を拡張することにより複数の実行コンテキストを使用することもできますまたCloudKitを介して強力なデータを共有することもできます Core DataはAppleの全てのプラットフォームで使えますこの最後の点を強調したいと思います Core Dataを使い始めると Mac　iPhone AppleWatchなどのプラットフォームで学んだことを生かすことができます勿論Core DataはSwiftを使っても上手く機能します Core DataAPIが Swiftを用いても同程度に表現力豊かになれるように数年間開発を続けてきましたそして今年は Swiftにとってかなり刺激的な年です言語とランタイムにおける新たな同時実行処理機能を導入しました Core Dataの開発当初からコードの同時実効性を意識してきましたこれには十分な理由がありますデータの永続化には外部記憶媒体との間の読み書きが必要となります新規同時実行モデルが上手く調和するようにサポートしますこれが地震のサンプル Appのコンテキストで　どのように機能するかをお見せしますこのAppは米国地質調査所のデータフィードから過去に起きた地震のマグニチュード位置日時などのデータを読み取り Core Dataを使って保存します構造的にEarthquakesは Swift Appケーションです UIを起動するためのビューコンテキストと地質調査所からデータを取り込むバックグラウンドコンテキストがあります App用のローカルコンテナに地質調査所のJSONフィードから地震データを収集します
ダウンロード時にデータを JSONパーサーに送信しバックグラウンドコンテキストにインポートしますそして管理オブジェクトに変換しローカルストアに保存します次にビューコンテキストは変更点を融合しUIを魔法のように更新します 2020年にはこのデータをバッチ操作を用いて効率的に処理する事に焦点を当ててきましたしかし今はこれらの操作を同時に実行させることに焦点を当てています特にデータを Appにインポートする際の 3つのステップに焦点を当てますステップ1は生データのダウンロードが完了すると Appはそれを特定のローカルな表現に変換する必要があります最後にこの新たなオブジェクトを永続的なストアに保存しますハイレベルコードに変換してみましょう各操作を独自の機能又はクロージャに要約しました Appはまずサーバから生データを取得しローカル表現に変換します次にバックグラウンドで managedObjectContextにバッチ挿入を要求しオブジェクトをCore Dataにインポートします
このように書くと潜在的な難所を視覚化しやすくなりますネットワーク経由でデータをロードすると非同期処理を検討するようになります変換も考慮すべき点でしょうさらに永続的なストアへのデータのインポートは極めて適切です
しかし今まではこれら全てのケースにおいて非同期で処理するには自身で実行するか又は既存の枠組みで処理するかに大きく頼ってきましたここでCore Data特有の抽象化についてお話します
PerformAndWait を呼び出すと管理オブジェクトのコンテキストが独自の保護環境下において提供されたクロージャを実行しますこれは作業が完了するまで呼び出しスレッドと関連する可能性があります
これを視覚化するとすれば 3つのブロックのコードをイメージできます BEFORE, DURING そして AFTERとラベル付けをしました
コードが実行されると最初にBEFOREのラベルのコードが元のスレッドで実行されます次にperformAndWaitを呼び出すと DURINGのクロージャの処理が完了するまでスレッドはブロックされますその作業完了後AFTERのコードが実行されます
クロージャの終了を待つ必要がない場合は完全に非同期のバリアント型を常時提供していますしかし今年Swiftが強力な同時実行モデルを獲得し深層言語も統合したことにより APIの意図を正確に説明できるCore Dataが実現しました構文は少し異なります貴方は実行の結果を待つように指示しますがこの新たなAPIを使用するためのメンタルモデルは管理オブジェクトを常にサポートしてきたものと全く同じです利点としては同時処理の詳細がもはや隠されておらず代わりにSwift言語に深く統合されているということですこのためコンパイラは一般的な同時実行バグを多く自動的に防止することができます例えばデータ競合やデッドロック　さらにはタスクが待ち状態の時の効率的なリソースの活用などですコードに戻って　実際に使った場合どのような感じなのかを見てみましょう
前述のように非同期関数に待機を指示します前の状態に戻り非同期関数が制御を回復するまで呼び出し実行コンテキストが中断する可能性があります
Swiftの既存の構造化エラー処理機能とともに途切れなく機能し呼び出しフレームに提示されたエラーを経路制御します非同期関数呼び出しの例を見てきましたコンテキスト内で非同期作業を実行するためにどのように宣言されているのか Core Dataの新規の方法を見てみましょうこのSwiftコードの一節にかなりの機能が詰め込まれていますまずは重要な点についていくつか紹介しその後　実際にどのように使うかをお見せしたいと思います新たな実行オーバーロードの宣言をすると結果に基づき戻すことができる非同期キーワードで装飾された一般的なものであることがわかります　この機能が新たなSwiftの同時実効性の機能を選択しますこの新たなAPIの優れた点は提示されたクロージャによりエラーをスローしたり値を戻したりすることが出来ることであり手動で呼び出しフレームにルーティングするよりも手間を省くことが出来ることですこれがどれほど凄いことかをいくつかのシナリオに沿って見てみましょうこれまでは同時実行機能が実装内部に隠れていたためエラーを転送する唯一の方法は performAndWait外のオプションで閉じた後にチェックすることでしたこれは完全に非同期のバージョンを使用すると更に複雑になりますなぜなら完了ハンドラを通過する多くのプラミングし　それを一貫して使用することを確認する必要があるからです新たな同時実行モデルを備えたSwiftでは全てのプラミングが処理されます一度試して非同期での作業を見てみて下さいエラーが発生した場合はスローするだけで自然に呼び出しフレームで解決されます
エラーに注目しましたが結果はどうでしょう？私が説明した事は全て同じ様に機能します具体例を見てみましょうコードに入る前に概略をお話しましょうこの例では過去5時間に発生した地震の数を確定するためのフェッチリクエストを設定します文章であれば表現するのは簡単ですしかしコードでは少し命令し直しますはじめに5時間前を定義する必要がありますこれを確実な方法で計算するにはカレンダーAPIを使用します次にその日のフェッチリクエストを述語付きで構成しカウント結果を要求しますコードはほぼ計画通りです今から5時間前を計算するためにカレンダーのオフセットAPIを使用します次に述語付きカウント結果を一致する日付に帰すために Quake FetchRequestを構成しますこれまでは結果を返した場合エラーを攻略した時と似たパターンをたどりました変更が必要な時　どのような状態でも一旦閉じてから managedObjectContextで計算を実行しますコントロールを取り戻した後結果を使用します
そして実行コールの結果をただ待ちますその結果を実行ディレクトリ用に呼び出しフレームに返します残りのコードは全く同じです回避すべきなのは手作業での値のルーティングとそのコードの潜在的なバグとニュアンスですこの新たなコードは非常に簡潔で表現力豊かです
ただし注意が必要な時もあることをお伝えしなければなりません別の例でその理由を見てみましょうこの例では直近の地震を管理オブジェクトとして返そうとしています新たなAPIではたやすく値を返せますが既に managedObjectContextに登録されている managedObjectsを返すことは安全ではありません登録されたオブジェクトは実行呼び出しのクロージャ内で参照のみできます managedObjectを参照する必要がある場合は異なる実行コンテキスト間で ObjectIDを利用して必要に応じてリフェッチするか辞書表現オプションのフェッチリクエストを利用します別の例をお見せする前にお伝えすることがありますそれは ScheduledTaskTypeですこれまで見てきた全ての非同期処理はオプションに関してはデフォルト値の .immediateです 2番目のオプションは .enqueuedですこの２つのアプローチの違いを理解することによりスケジュール作業を指示する際に ManagedObjectContext内で何が起こるかについて知ることができます前述の通りimmediateは performAndWaitの Swift-async-aware版のような動作をします別の実行コンテキストをバックグラウンドコンテキストで走らせているのであればその作業を待つように指示しますそしてスケジュールがなされ作業が完了するまで待ちます
ただし既に同じ実行コンテキストにいる場合作業は楽観的にすぐに予定されます
一方enqueuedはもう少しシンプルです発信元の呼び出しサイトとの相性とは関係なくただ常に要求された作業をコンテキストのワークセットの最後まで追加するだけです先に進んで　もう１つ例を見てみましょうこれら全ての非同期機能を貴方も使うことが可能ですここにこれまでお話してきたインポート論理を新たな非同期キーワードで装飾された importQuakes関数に因数分解しましたこの関数は順に他の非同期機能に対して実行されます
この新たなSwiftの同時実行機能を活用するためのこの関数を待てば良いだけですこれまで見てきたことをまとめてみましょうこの新たなAPIによりSwiftの構造化された同時実行性が直接Core Dataに活かされます実行APIの新規バリアント型は既存の Core DataAPIのSwift の同時実行性を意識したバージョンで既に愛用されています貴方のAppでこの新たなAPIを利用されることを強くお勧めします
さらに　保護された同時実行ドメイン内でタスクをサポートする Core Dataは NSManagedObjectContext だけではありません NSPersistentContainer と NSPersistentStore Coordinatorに類似したAPIも追加していますこれらのAPIの全体的な形状と動作は既に説明したものと似ていますしかしその同時処理力をもってしても既存の利用可能なデバッグツールの使用をお勧めします XCodeはアドレスとスレッドサニタイザーを提供し　認知度が非常に低いバグでさえも捕らえることができます両方ともスキームエディターの設定の診断ペインで見つけることができます各サニタイザーは複数のスレッドから安全なメモリ使用の検証やデータの適切な使用など様々な問題を検出しますソフトウェアをユーザーのコミュニティにリリースする前に常にAppと関連するテストをサニタイザーを使って点検することは好ましい事ですサニタイザーが全てのコンテキストで役立つ一方で Core Dataによりドメイン固有のヘルプを利用できる特別なランタイムフラグも使えることをお伝えしますこのオプションを有効にするとCore Dataは内部ロックを検証し様々なタイプの Core Dataを適切に使用するための多くの有用なアサーションをオンにします
Swiftの同時実行性のサポートの採用だけが今年Core Dataに加えられた変更ではありません CloudKitの共有から新たなSpotlightの統合までこれまで紹介してきた新たなAPIは全て Swiftを念頭に置いたプレゼンテーションとともに作成されました今年はこれらのトピックごとにセッションを設けているのでチェックされることをお勧めしますさらにフレームワーク全体を通して Swiftで改善できる場所を特定するためのパスを作りましたこれから私達がサポートする様々な永続的ストアをいくつかお見せします Recallは永続的なストアで顧客のデータを保存する物理的な方法を説明します Core Dataは現在４つのストアを提供しています XML　Binary InMemoryそしてSQLiteです貴方はこれらの識別子を常に使用しています今年はこれらに Swiftにおける自然な名前を付けました既存の名前はこれからも使用可能ですしかしこれらを消費する新たなAPIは簡潔な名前と記号のオートコンプリート機能により更に人間工学的に使用されるようになりますもちろん永続的ストアだけが Core Dataの型に関与している訳ではありません型付きデータの保存に関してはフレームワークが全てでありそのような型が属性とともに記述されますそして今年は新たな拡張可能な列挙型を追加することにより各型で遙かに自然な構文を用いて属性を説明できるようになりました XCodeモデルビルダーでランタイムモデルが設計したものと一致するかどうかを検証するユニットテストを書いて動作を確認してみましょう
簡潔にするために地震オブジェクトモデルで定義された単一のランタイムについて検証しますこれにより測定方法をイメージすることができますこれは小テストのように思えるかもしれませんが将来はよりスピードアップし深く探究できるので検証することは好ましいことです新規のAttributeType の点について簡単なヘルパー関数を書きテストとしますこの関数について説明しましょうまずは属性名実体の説明さらに新規のAttributeType 列挙型の説明を含む署名をします
このユーティリティの定義は非常にシンプルです最初に指定された名称の属性があることを確認しますこれがないとテストに失敗しますそして属性の型が想定通りかどうかを検証します本当にそれだけのことですこれを実体とプロパティごとに繰り返しますそしてランタイムの動作が定義したモデルと一致することを確認します
これは今年 Swiftにおいて Core Dataの列挙子が人間工学的に改善されたサンプルです
ここまで下位レベルでのフレームワークの相互作用が Swiftでどのように表れるかについてお話してきましたがユーザーへのプレゼンテーションはどうでしょうか？ 2020年はCore Dataを SwiftUIで操作することの利便性について多く紹介してきましたここで私の同僚であるスコットが今年我々が成し遂げた向上した機能についてご紹介しますスコットありがとうマイケル！今年Core Dataと SwiftUIを用いた機能において改善された点は多くありますまずはフェッチリクエストにおけるレイジーエンティティの改善でイメージを構築する前に AppにセットアップされているCore Dataのスタックの要件の緩和です今年もフェッチリクエストはソート記述子と述語の動的構成をピックアップします
そしてセクションフェッチをサポートする新たな種類のフェッチリクエストがあります先ほどマイケルが紹介した地震サンプルApp を用いてレイジーエンティティの解決をはじめとして個々にお話していきます貴方のAppにはこのようなコードがあると思いますこのコンテナプロパティはこのタイプのコードやさらに広域のAppをサポートするのに実際のところ必要ありません QuakesProvider型から必要なものを直接入手することができますこのプロパティはこのモデルをロードする前にエンティティを参照する段階で Core Dataスタックが設定されていることを確認するためにありますこちらをご覧ください ContentViewの初期化の後に環境ビュー修飾子が呼び出されています今年のSDKに配置する時はこのトリックはもはや必要ありません FetchRequestのプロパティラッパーがフェッチ時にレイジーの名でエンティティを検索しますこの時点でCore Data スタックの設定環境が保証されていますですのでこのプロパティを今削除しても安全です
そして直接
環境呼び出しで QuakesProviderが共有するコンテナを参照します新規APIに移ります FetchRequestが動的構成をサポートしますリクエストの述語を直接変更するためのラップされた値には新規プロパティが２つありますまたソート記述子は使い慣れた NSSortDescriptorsと自動生成された管理対象オブジェクトのサブクラスのエンティティをフェッチするときに利便性と安全性が高い新規 SortDescriptor value タイプのものがあります
そして最後にラップされた値と同じプロパティセットを備えた構成バインディングがありビューとの統合を容易にしますこの新規APIの登場前はソートと述語パラメーターをビューのイニシャライザを通してイメージをデザインする必要がありました　またツールバーのコントロールを使用してフェッチリクエストの設定をしたり難しい作業が必要でもありましたこの摩擦は新たな動的構成プロパティにより排除されますこれから地震サンプルAppへの追加　並べ替えフィルタリングなどの使用方法をお見せしますまずソート記述子を見てみましょうデフォルトでは地震Appは時系列でソートされています更にマグニチュードでソート　されたデータも欲しい場合は　メニューを追加して結果の順序を制御できるようにしますまずサポートしたいソート記述子を含む
タプルの静的配列を名称とともに追加しますすると新しいSortDescriptor タイプも使用されています
どの並べ替え順を使用してきたかを追跡する機能も欲しいですねこのための型を既に作成してあるのでコンテンツビューのプロパティとして追加します次にツールバーメニューをリストビューへ追加します
onChange修飾子とともに選択後のものに変更されフェッチリクエストのソート記述子を更新します
プレビューでは新しいメニューを見ることができ地震データをマグニチュードでソートすることができます素晴らしい！フィルタリングを追加します地震の場所でフィルタリングしたいと思います最初に必要なのは検索フィールドのテキストのステートですそしてフェッチリクエストを更新する検索フィールド用の
バインディングプロパティを作ります
これらを配置するとあとはUIだけです便利なことに
Searchableは文字列とバインドするためここに落とすだけでいいのです
プレビューではこの新たなフィールドに ”サンドイッチ”と入力するだけでマッチした震源地の近隣地域を絞り込むことができます
これがフェッチリクエストの動的構成です他に機能面でよく要求されることはセクションフェッチのサポートですこれは SectionedFetchRequestと呼ばれる新たなプロパティラッパーとして今年登場しますこのタイプはFetchRequest として同じ新たな動的構成プロパティをサポートしますしかしこれは NSFetchedResultsController に似てセクションを識別するプロパティへのキーパスの追加パラメータとともに初期化されます
しかしフェッチ結果コントローラーとは違いセクションを識別するプロパティはハッシュ可能であれば任意のタイプを選べます SectionedFetchRequestの追加のジェネリックパラメータを使用して型システムにエンコードされます最後にこの新たな型を２次元の結果型にまとめます SectionedFetchResultsはセクションの集まりでそのそれぞれが結果の集まりです各セクションには識別子付きのプロパティもあります
これは非常に簡単に取り入れられるので地震Appにセクションフェッチを追加してみたいと思いますまずフェッチリクエスト宣言を更新します
Quakeには既に日付のプロパティがあるのでそれをセクショニングキーパスに使います
次にボディプロパティを更新して
新たなセクション化結果型と一致させます
ここで外側のループがセクションを繰り返すのでセクションビューを出力しますそして各セクションは地震の集まりで先程結果を繰り返していたようにこの内側のForEachがセクションを繰り返します
プレビューを見ると時系列で日ごとに区分された地震結果を得ましたそしてSwiftUIは自動的にセクションを折りたたむサポートを備えています
この新たな SectionedFetchRequest型はセクション識別子キーパス用の追加構成プロパティに加えて FetchRequestと同じ動的構成プロパティもサポートしています並べ替えを変更するのはもはや安全ではないのでこれは非常に重要です時間と地震のマグニチュードは完全には相関していないためセクションが断続的になる可能性があるからですこれを修正するには並べ替えを更新する必要があります
それぞれにセクション識別子キーパスが付与されました
ツールバーを下に行きます
ソート記述子を更新する度にセクション識別子キーパスも更新する必要があります
ここが重要な部分ですリクエストの変更は結果ゲッターが呼び出された場合は常にコミットされます並べ替えとセクショニングの両方を安全に更新するには
参照の構成を引き出したローカルの結果に更新する必要があります
プレビューでは順序を変更するとセクショニングも変更されていることが確認できます地震を時系列に並べて日付けで区分する事とマグニチュード順に並べて区分する事を切り替えることができます
これで完成ですスタックのレイジー初期化動的構成及びセクションフェッチはiOS15と MacOS Montereyを用いれば全て既存のAppに簡単に適用できますつまりCore DataはAppleの全プラットフォームにおいて Appデータの永続性ニーズを満たすワンストップショップのようなものです新たな同時実行性機能を備え　実行APIを介して Swiftで利用可能であり強力なスレッド安全性デバッグ機能も組み込まれています
新たな列挙型インターフェイスはSwiftでのストアと属性タイプの使用をサポートし更にはCloudKit の共有及びSpotlightの統合を実現しました SwiftUIを利用するとビューへのデータ接続が未だかつて無い程に簡単になり動的構成とセクションフェッチ機能も備えています
このトピックに関連する新たに学ぶべきことがまだ多くあります是非"SwiftUIで簡素化し Swiftで同時実行性を満たそう”をチェックされることをお勧めしますこれで終わりです！皆さんが新規APIを使って作り上げたものを拝見することをとても楽しみにしています [明るい音楽]

20:36 - FetchRequest dynamic configuration: sort descriptors

private let sorts = [(
    name: "Time",
    descriptors: [SortDescriptor(\Quake.time, order: .reverse)]
), (
    name: "Time",
    descriptors: [SortDescriptor(\Quake.time, order: .forward)]
), (
    name: "Magnitude",
    descriptors: [SortDescriptor(\Quake.magnitude, order: .reverse)]
), (
    name: "Magnitude",
    descriptors: [SortDescriptor(\Quake.magnitude, order: .forward)]
)]

struct ContentView: View {
    @FetchRequest(sortDescriptors: [SortDescriptor(\Quake.time, order: .reverse)])
    private var quakes: FetchedResults<Quake>

    @State private var selectedSort = SelectedSort()

    var body: some View {
        List(quakes) { quake in
            QuakeRow(quake: quake)
        }
        .toolbar {
            ToolbarItem(placement: .primaryAction) {
                SortMenu(selection: $selectedSort)
                .onChange(of: selectedSort) { _ in
                    let sortBy = sorts[selectedSort.index]
                    quakes.sortDescriptors = sortBy.descriptors
                }
            }
        }
    }

    struct SelectedSort: Equatable {
        var by = 0
        var order = 0
        var index: Int { by + order }
    }

    struct SortMenu: View {
        @Binding private var selectedSort: SelectedSort

        init(selection: Binding<SelectedSort>) {
            _selectedSort = selection
        }

        var body: some View {
            Menu {
                Picker("Sort By", selection: $selectedSort.by) {
                    ForEach(Array(stride(from: 0, to: sorts.count, by: 2)), id: \.self) { index in
                        Text(sorts[index].name).tag(index)
                    }
                }
                Picker("Sort Order", selection: $selectedSort.order) {
                    let sortBy = sorts[selectedSort.by + selectedSort.order]
                    let sortOrders = sortOrders(for: sortBy.name)
                    ForEach(0..<sortOrders.count, id: \.self) { index in
                        Text(sortOrders[index]).tag(index)
                    }
                }
            } label: {
                Label("More", systemImage: "ellipsis.circle")
            }
            .pickerStyle(InlinePickerStyle())
        }
        
        private func sortOrders(for name: String) -> [String] {
            switch name {
            case "Magnitude":
                return ["Highest to Lowest", "Lowest to Highest"]
            case "Time":
                return ["Newest on Top", "Oldest on Top"]
            default:
                return []
            }
        }
    }
}

21:33 - FetchRequest dynamic configuration: predicates

struct ContentView: View {
    @FetchRequest(sortDescriptors: [SortDescriptor(\Quake.time, order: .reverse)])
    private var quakes: FetchedResults<Quake>

    @State private var searchText = ""
    var query: Binding<String> {
        Binding {
            searchText
        } set: { newValue in
            searchText = newValue
            quakes.nsPredicate = newValue.isEmpty
                               ? nil
                               : NSPredicate(format: "place CONTAINS %@", newValue)
        }
    }

    var body: some View {
        List(quakes) { quake in
            QuakeRow(quake: quake)
        }
        .searchable(text: query)
    }
}

23:26 - SectionedFetchRequest

extension Quake {
    lazy var dateFormatter: DateFormatter = {
        let formatter = DateFormatter()
        formatter.dateFormat = "MMMM d, yyyy"
        return formatter
    }()

    @objc var day: String {
        return dateFormatter.string(from: time)
    }
}

struct ContentView: View {
    @SectionedFetchRequest(
        sectionIdentifier: \.day,
        sortDescriptors: [SortDescriptor(\Quake.time, order: .reverse)])
    private var quakes: SectionedFetchResults<String, Quake>

    var body: some View {
        List {
            ForEach(quakes) { section in
                Section(header: Text(section.id)) {
                    ForEach(section) { quake in
                        QuakeRow(quake: quake)
                    }
                }
            }
        }
    }
}

24:56 - SectionedFetchRequest dynamic configuration: sort descriptors

extension Quake {
    lazy var dateFormatter: DateFormatter = {
        let formatter = DateFormatter()
        formatter.dateFormat = "MMMM d, yyyy"
        return formatter
    }()

    @objc var day: String {
        return dateFormatter.string(from: time)
    }
  
    @objc var magnitude_str: String {
        return "\(magnitude)"
    }
}

private let sorts = [(
    name: "Time",
    descriptors: [SortDescriptor(\Quake.time, order: .reverse)],
    section: \Quake.day
), (
    name: "Time",
    descriptors: [SortDescriptor(\Quake.time, order: .forward)],
    section: \Quake.day
), (
    name: "Magnitude",
    descriptors: [SortDescriptor(\Quake.magnitude, order: .reverse)],
    section: \Quake.magnitude_str
), (
    name: "Magnitude",
    descriptors: [SortDescriptor(\Quake.magnitude, order: .forward)],
    section: \Quake.magnitude_str
)]

struct ContentView: View {
    @SectionedFetchRequest(
        sectionIdentifier: \.day,
        sortDescriptors: [SortDescriptor(\Quake.time, order: .reverse)])
    private var quakes: SectionedFetchResults<String, Quake>

    @State private var selectedSort = SelectedSort()

    var body: some View {
        List {
            ForEach(quakes) { section in
                Section(header: Text(section.id)) {
                    ForEach(section) { quake in
                        QuakeRow(quake: quake)
                    }
                }
            }
        }
        .toolbar {
            ToolbarItem(placement: .primaryAction) {
                SortMenu(selection: $selectedSort)
                .onChange(of: selectedSort) { _ in
                    let sortBy = sorts[selectedSort.index]
                    let config = quakes
                    config.sectionIdentifier = sortBy.section
                    config.sortDescriptors = sortBy.descriptors
                }
            }
        }
    }

    struct SelectedSort: Equatable {
        var by = 0
        var order = 0
        var index: Int { by + order }
    }

    struct SortMenu: View {
        @Binding private var selectedSort: SelectedSort

        init(selection: Binding<SelectedSort>) {
            _selectedSort = selection
        }

        var body: some View {
            Menu {
                Picker("Sort By", selection: $selectedSort.by) {
                    ForEach(Array(stride(from: 0, to: sorts.count, by: 2)), id: \.self) { index in
                        Text(sorts[index].name).tag(index)
                    }
                }
                Picker("Sort Order", selection: $selectedSort.order) {
                    let sortBy = sorts[selectedSort.by + selectedSort.order]
                    let sortOrders = sortOrders(for: sortBy.name)
                    ForEach(0..<sortOrders.count, id: \.self) { index in
                        Text(sortOrders[index]).tag(index)
                    }
                }
            } label: {
                Label("More", systemImage: "ellipsis.circle")
            }
            .pickerStyle(InlinePickerStyle())
        }
        
        private func sortOrders(for name: String) -> [String] {
            switch name {
            case "Magnitude":
                return ["Highest to Lowest", "Lowest to Highest"]
            case "Time":
                return ["Newest on Top", "Oldest on Top"]
            default:
                return []
            }
        }
    }
}

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

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

リソース

関連ビデオ

WWDC21