SwiftUIのご紹介

SwiftUIのご紹介

宣言型プログラミングの世界を探求しましょう：フル機能のSwiftUI Appを一から構築する方法、そしてSwiftUIとXcode両方の力を合わせ、優れたAppをより短時間で構築する方法もお伝えします。

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

WWDC23
- SwiftUIでのデザイン
WWDC20
WWDC19
- SwiftUIでカスタムビューを構築する
こんにちは WWDCへようこそ
“SwiftUIの紹介” 私はジェイコブです後ほどカイルも登場しますよ SwiftUIをご紹介するのが楽しみです Appをより早く構築する素晴らしい方法です SwiftUIについて知るには実際に見るのが一番です SwiftUIは魔法のようですがトリックはありません Appを作りながらプロセスをご説明しますどんなAppを作りましょうかカイルと私はサンドイッチが大好きですそこでサンドイッチをリストから選べるAppにしました Xcodeで構築を始めましょう
まず新しいプロジェクトを作成
マルチプラットフォームの Appテンプレートを使用します
プロジェクト名は“Sandwiches”
新規プロジェクトにはiOSとMac OS向け両方に必要なものがすべて備わっています iOS専用アセットのグループと Mac OS専用アセットのグループです
ただほとんどは共有グループにありますこれがApp全体のコードです短すぎるように思えますがこれだけで十分ですこのコードは後で使います Appビュー用のコードから始めましょう
エディタの左側にはコード右側にはキャンバスがありコードを視覚的に表示します SwiftUIではビュー定義は Swiftコードのみですキャンバスとコードエディタは同じコードを異なる方法で表していますキャンバス上で何かを選択すればコードにも反映されますコードを変更すると
キャンバスにも反映されますシームレスに連携し自由に切り替えが可能です詳しい仕組みを説明しますキャンバスにはプレビューが表示され編集やコードの確認もできます Xcodeはコードをコンパイルして実行プレビューを表示しますプレビューもSwiftUIコードを使って作成されています後ほどプレビューのカスタマイズにいかに有効かお見せしますそれではサンドイッチのListのセルを作成しましょうこの下に別のテキストを追加して各サンドイッチの詳細を表示しますライブラリから追加します
キャンバスにドラッグするだけです
Xcodeではどこに置いたらどうなるかも確認できますドロップするとプレビューが更新され追加テキストが表示されますテキストを追加するコードも書き加えられました
これらのビューは VStackに埋め込まれています VStackはSwiftUIの一般的なレイアウトコンテナの一つでビューを垂直に配置しますビューを水平に配置するのが HStackです
スタックの中にはビューを自由に配置できます
このプレースホルダにサンドイッチの材料を入れますここではハードコードされた値にします
次にテキストの横に画像を入れましょうエディタ同様簡単にコードを編集できます HStackにビューを埋め込みますビューをコマンドクリックして “Embed In HStack”を選択します
その作業のためのコードが追加されましたこれで VStackの横に画像を追加できます
あとでアセットを追加しますがここではSFシンボル画像を使用します
基本のセルができたので次にセルのスタイルを設定しますビューをコマンドクリックするとプロパティを確認できます
VStackのアライメントを変更します
対応するコードが更新されます
材料のテキストを見てみましょうキャンバスを使います
コントロールキーとオプションキーとクリックでインスペクタへ行けます
フォントを小さくしましょうサブヘッドラインを使います
Xcodeでコードを編集すると SwiftUIの理解が深まりますこれがテキストのフォントを設定するコードですこのメソッドは“モディファイア”といって SwiftUIでビューの外観や動作をカスタマイズするのに使われますコードに別のモディファイアを追加して文字色をセカンダリカラーに設定します
それではセルをListにしましょうセルをコマンドクリックして “Embed In List”を選びます
同じセルが５つ並んだListができますこれがListにするコードですデリゲートやデータソースはなく Listのビューだけですここにデータをつなげてみます
既存のアセットとモデルファイルをドラッグします
このファイルには情報が入っています SwiftUIで使用するためタイプをIdentifiableにします
これでListアイテムの識別ができます IDプロパティはすでにあります
この中のテストデータは Appのデバッグに使えます
ビューに戻りデータを渡しましょう
sandwichesにビューのプロパティを追加します
プレビューでは独自のテストデータが使用できますここにテストデータを渡します
プレビューの上にバナーがあるのに気づきましたかプロパティの追加など大きな変更を加えると Xcodeは更新再開の準備が整うまでプレビューを停止しますこのボタンをクリックすると再開できます
次にListを動かしましょう Listにsandwichesを渡します
テキストを更新してサンドイッチの名前と
実際の材料の数を表示させます
サンドイッチのサムネイル画像も表示させましょう
セルの変化に気づきましたか？始めのセルの高さは44ポイントでしたが画像が大きくなるとそれに合わせてセルが自動的に拡張されます追加作業は不要ですコンテキストの画像はシャープに見えるのでモディファイアを使って角に丸みを付けましょう
使用可能なモディファイアが分からない場合は Xcodeライブラリで探せます
cornerRadiusモディファイアを検索しキャンバスにドラッグします
Listセルにあるビューの場合セルが同じ定義を共有しているのでモディファイアはすべてのセルに適用されます
画像にドロップして値を調整しましょう
セルとListはよくなりましたね次はセルをタップしてサンドイッチの詳細が見えるようにします
そのためにNavigationViewで Listを囲いましょう
NavigationViewを使えば App内を移動できます iPhoneではナビゲーションバーが表示されナビゲーションスタックにプッシュできますビューのnavigationTitleを設定してバーに“Sandwiches”と表示させます
次にスタックにプッシュするセルを構成しますそれにはセルの中身を NavigationLinkで囲います
NavigationLinkにはプッシュ先を取り込みますここではサンドイッチの名前を表示するテキストにします
そしてセルを NavigationLinkの中に入れます
UIが更新されすべてのセルに詳細インジケータが表示されました SwiftUIは詳細を自動的に処理するので UIがデフォルトで正しく表示されますセルの動作確認をする時にもプレビューが便利ですプレビューのプレイボタンをクリックしライブにするとキャンバスで実際のコードを操作できますセルをタップして想定通りに動作するか確認ができます
スワイプしてポップすれば SwiftUIによる高度な動作を確かめられますセルは強調表示されておりスワイプすると自動的に解除されます
あとはListにサンドイッチの数を表示させたいと思いますコードが大きくなってきたので単一のビューにはしたくありませんセルを独自のビューに抽出し分けることにしましょう Xcodeでは簡単な操作で行えます目的のビューをコマンドクリックし “Extract Subview”を選択します
ビューコード全体が新しいビューに移動名前も付けられます “SandwichCell”としましょう
sandwichのプロパティを追加し
そのsandwichを渡します
これはすばらしい改善です SwiftUIではビューが非常に軽いのでビュー追加のためにカプセル化やロジック分けは必要ありません Listコードがスリム化されたのでサンドイッチの数を追加しましょう
現在は単一のコレクションを使用していますがこれはデータ駆動型のListに最適です SwiftUIを使えば静的コンテンツと動的コンテンツを混在させられます現在のコレクションを ForEachに置き換えてみます
ForEachは各アイテムのビューを作成します
データ駆動型の要素に静的要素を追加できましたここにもう１つテキストを追加してサンドイッチの数を表示します
文字色をセカンダリカラーに変更します
テキストを中央に配置するために HStackにテキストを埋め込みます
スペーサーを追加
スペーサーは SwiftUIのレイアウト要素ですツールバーのフレキシブルスペースのように拡張してスペースを埋めます２つのスペーサーがスペースを分割しテキストを中央に配置します
次に詳細ビューを作りましょう新しいビューを作ります SwiftUIビューテンプレートを使用し “SandwichDetail”と名付けます
自動的にビュー構造とプレビューコードが生成されます
サンドイッチの詳細情報を表示するために入力として渡します
ここでもプレビューコードを使用してテストデータを渡します
それからサンドイッチの画像を追加します
画像が表示されましたが大きすぎますデフォルトでSwiftUIは画像を元のサイズで表示します画質が落ちることを避けるためですしかし今回のようにサイズを小さくしたい時には resizableというモディファイアを使います
サイズは合いましたが画像の縦横比が変わってしまいました別のモディファイアを使って縦横比を調整しましょう
ここで“fill”を選ぶと画像がフレーム全体に拡大され “fit”を選ぶと画像がフレーム内に収まりますプレビューを使えば簡単に違いを確認できます “fit”を選んで全体を表示させましょう
次にListへ戻りセルを更新して詳細ビューをプッシュします
SandwichDetailを作成
sandwichに渡します
プレビューをライブにしますセルをタップすると画像が表示されます
ただナビゲーションバーにタイトルを設定していなかったので詳細ビューに戻って修正します
ここでもnavigationTitleを追加しサンドイッチの名前を設定します
プレビューには表示されていませんがすぐに変更を確認したいです SwiftUIのビューの全機能はプレビューでも利用可能です他と同じようにNavigationViewにプレビューを設定します
プレビューのナビゲーションバーにタイトルが表示されました
私がサンドイッチを選ぶ時重要なことがありますソースの量が適切であるかです多すぎても少なすぎてもおいしくありませんこの画像でソースは見えますが適量かを知りたいと思います縦横比をfillにすると
アップで見られますよさそうですね fillとfitを切り替えることでアップと全体を交互に表示させることができますしかしApp実行中に切り替えたい場合はどうすればよいでしょうかそれを理解するにはSwiftUIのビューをもっと知る必要がありますカイルに説明を変わりましょうありがとうジェイコブこんにちは SwiftUIチームのカイルです SwiftUIは他のフレームワークと少し異なりますそのため先に進む前にまずはビューの動作について説明します SandwichDetailビューを実装したところまでお見せしました
SwiftUIではビューはビュープロトコルに準拠する構造体で UI Viewのように基本クラスを継承していませんつまり保存されているプロパティを継承しないのですスタックに割り当てられ値で渡されます
SandwichDetailにはサイズや重さだけが保存されていて追加の割り当てや参照カウントはありません
SwiftUIは裏でビュー階層を積極的にまとめレンダリング用のデータを作っていますそのためSwiftUIでは小さな単一目的のビューを自由に使えるのです
私がお伝えしたいのは SwiftUIのビューは驚くほど軽いということです SwiftUIコードはどんどんリファクタリングしてくださいサブビューの抽出にオーバーヘッドがないためです SwiftUIのビューの主な役割は従来のUIフレームワークと同じですつまり UIを定義しますビュープロトコルに必要なのは bodyのみです body自体がビューです
小さなビューを合わせて大きなビューを構築します SandwichDetailビューでは画像を使用しました解像度が元のままの画像を
resizableで画面のサイズに合わせて調整さらにaspectRatioを組み合わせ画像の縦横比を合わせました
ビューのレンダリングはそのbodyのレンダリングにすぎません
bodyの実装に設定したブレークポイントでデバッガが停止した場合新しいレンダリングが必要だと判断されたことを意味します
この通りレンダリングのタイミングはフレームワークが知っています UIの定義に加えてビューは依存関係も定義しているからです
SandwichDetailを拡張してユーザーがタップすれば画像の大きさの切り替えができるようにしましょう
まず必要なのは状態変数です画像がズームされているかを示します
SwiftUIでは状態変数を持つビューはビューの代わりに変数にストレージが割り当てられます
その状態変数に基づきフィルまたはフィットを行いますズーム時はこのように表示されズームなしではこうなります
タップの動作だけで２つの状態を切り替えることができるのですタップで画像が拡大されフィルになったり
縮小されフィットになったりします
何が起きたのかご説明します
SwiftUIは状態変数の読み取りや書き込みを観測できますズームされた箇所が bodyに読み込まれたと知っているためビューのレンダリングが bodyに依存すると認識できます
変数の変更に伴いフレームワークは再度bodyを要求し新たな状態値を用いてレンダリングを更新します別のコンテンツモードで試します従来のUIフレームワークでは状態変数と単純な古いプロパティを区別できませんしかしその２つの違いは明確なのです SwiftUIはUIのあらゆる状態を把握しますスクロールビューのオフセットやボタンのハイライトナビゲーションスタックの内容もです
これらは“真実のソース”と呼ばれる信頼度できるデータから取得されます
状態変数とモデルが合わさって App全体の真実のソースを構成します
先述のとおり縦横比を呼び出すとビューが作成されます
コンテンツモードが単純な古いSwiftプロパティの場合の定義では
すべてのプロパティを真実のソースまたは派生値に分類できます
ズーム時の状態変数は真実のソースです
コンテンツモードプロパティは状態変数から派生します
SwiftUIは状態変数の読み取りと書き込みを観測できるため変更があってもレンダリングが適切に更新されます
フレームワークが新たなbodyを要求しレンダリングを更新すると新たに縦横比ビューが作成されますそしてコンテンツモードや保存済みプロパティが上書きされます
こうしてすべての派生値が SwiftUIで最新の状態に維持されます
すべての状態変数は読み書き可能な真実のソースですが
すべての単純な古いプロパティは読み取り専用の派生値です SwiftUIは読み書き可能な派生値を渡すツール “binding”を発明しました技術的にはどの定数も読み取り専用の真実のソースとして機能しますプレビューを駆動するテストデータがその一例です
先述のとおり状態変数とモデルで構成されたものが App全体の真実のソースです後ほど観測可能なオブジェクトを使って SwiftUIにモデルオブジェクトの変更を観測させます
プリミティブの違いがまだ明確でなくても大丈夫です
どのデータフロープリミティブをいつ使うべきか直感的に分かるよう説明しますまずは一歩戻って現状を把握しましょう先ほどの例では従来のUIフレームワークとは全く異なりビュー自体が持続しすべてを最新かつ一貫性のある状態に保っていました
これは従来のUIフレームワークでは不可能でした従来はビューがデータを読み取るたびに暗黙的な依存関係になりましたデータの変更に応じてビューを更新し新しい値を反映させる必要があるためです
それが失敗するとバグになります SwiftUIは依存関係を自動的に管理します適切な派生値を再計算しバグが再び発生しないようにするのです一度に１つの依存関係を管理するだけではありません
私たちが扱っているUIは大きくて複雑です皆が頭を抱えるほど間違いを犯しやすい状態であり依存関係を手動で管理するのは非常に困難です最善を尽くした末に Appを出荷しているもののどれもUIバグの修正が必要になりましたこれらの線は依存関係を表しています
すべての線を理解していてもイベントハンドラのコールバックでのすべての順序で UIが一貫した状態かを確認する必要があります
UIKitに実装された旧バージョンのサンドイッチAppのバグを例に説明しますビューコントローラコードのスケッチですズームすると拡大ボタンが表示されます
このような低解像度の画像が表示された場合でもサンドイッチのソースが適量だと確認できました
ボタンを押すと機械学習操作がバックグラウンドスレッドに送られ画質を向上させます
よく見えますブラウンマスタードソースですね１つだけ問題がありました停止しないアクティビティインジケータが報告されたのです
バグの原因はイベントの予期しない順序付けです
この手のバグは真実のソースを更新し UIを派生させる時ではなくイベントハンドラのコールバックでサブビューを直接変更する時に起きます
原因はすぐに思い浮かぶハッピーパスにコードを記述しアンハッピーパスを見落としたことです
問題なのはイベント数の増加につれてアンハッピーパスの数が急増することですイベントを４つ取得する際何通りの順序があるでしょうか４つのイベントハンドラを呼び出す順序は 24通りあります
各イベントは複数回発生し得るので実際の数はさらに増えますユーザーが拡大ボタンを押すとしますその複雑度を管理することの難しさは非同期コールバックの調整や割り込み可能なアニメーションの実装をした人はご存じでしょうこれらの完了ハンドラは予期せず起動しがちです
５年前の自分に対し仕事について１つ言えることは UIプログラミングは難しいということですマルチスレッドコードの同期には誰もが苦労します数ヵ月かけてマルチスレッドコードのバグを修正してもその正確さに100%の自信を持てませんでした多くのUIコードでそのような状態ですビューの欠落や場所の間違いと見なされるため UIコードの難しさが軽視されがちです競合状態とUIの不統一に共通するのは複雑さの根本的な原因ですつまり見落としがちな順序付けです多くのビューで４つ以上のイベントを処理する必要がありますモデル通知やターゲットアクションやデリゲートメソッドライフサイクルチェックポイントや完了ハンドラなどです
12個のビューには大まかに12の階乗分の順序が存在しますつまり約５億通りですこれは脳でのビッグ・オー記法のようなものです
人間の頭に一度で収まる情報量を横線で示したとします点線は皆さんのAppを表します
２点の差が表すものは何でしょう
それはバグです
機能を追加すると存在し得る順序付けの数が急増しそれが一定数を超えるとバグを避けられない状態になります
従来のUIフレームワークを使用している時にビューの更新を１つのメソッドに収集し単純化する方法はご存じでしょう
これにより曲線の上昇は抑えられますメソッドが１つの場合呼びせる順序は１つだけだからです
このパターンでは UIに存在し得るすべての状態に対し真実のソースを定義する必要がありますそして真実のソースからビューのプロパティを派生させます
SwiftUIはこのベストプラクティスに直接影響を受けています bodyを唯一のエントリポイントにすることでフレームワークにコード化しています
こうして複雑なケースを解決できました従来のUIフレームワークではこのパターンの運用が難しかったケースもです例えばサブビューの削除やナビゲーションスタックへのプッシュテーブルビューへの更新の実行などです
こうしてビューに加え Appやシーン bodyを含むその他の SwiftUIの抽象化が機能します
変化したUIの新しいインスタンスを単純に取り出すこのパターンが皆さんの脳に対応します UIの不整合を事実上排除しますそれではデモに戻りサンドイッチの詳細ビューを終了しましょう次はサンドイッチを拡大するプロパティを追加しましょう
“zoomed”と呼ばれデフォルトでは“false”になります
ビューの実装内でのみアクセス可能にするため状態は非公開にします
ズーム時の“fill”とそれ以外の時の“fit”の切り替えのため縦横比のコンテンツモードで使用します
最後にズーム状態を切り替えるためタップジェスチャを追加します
ライブプレビューで確認します
モードの切り替えが可能です
ズームインすると下に空白が表示されます SwiftUIではセーフエリアと呼ばれる場所にビューが自動的に配置されるのです AppのUI要素は角の丸みによりクリップされませんしかしエッジからエッジまでの画像を画面全体に拡大したい場合
モディファイアを追加するだけでセーフエリアの無視が可能です
特に下端では無視してください
ズームできましたが何かが足りません
そこで SwiftUIアニメーションを追加します withAnimationで変更を囲います
異なる状態の間をアニメーションにします
アニメーションはインタラクティブでの割り込みも可能ですいつでもタップすることができ常に正しくアニメーション化されます
次に拡大ボタンを追加しますカイルが作業したモデルでは表示した1つの画像のみで機能しましたそこで便利な機能を追加しますカイルはスパイシーなサンドイッチが好きです
サンドイッチがスパイシーかどうかを確認するため詳細ビューの下にインジケータを表示します
既存のサンドイッチ画像の周りに VStackを追加します
そして一般的なモディファイアを移動し VStackに適用します
ここに画像とテキストを表示するには Labelを使用します
Labelに“スパイシー”というタイトルを入れます
アイコンも関連付けています “flame.fill”と呼ばれるシステム画像を使用します
Labelにはアイコンとタイトルが一緒に表示されますリストやメニューなどの他のコンテキストでも使用可能です Labelの外観間隔サイズが自動的に変更されます
画面の下部に背景がある下部バナーを作りたいと思いますスペーサーを追加するだけで
バナーが下に移動し画像が上に配置されます
画像を中央に配置するには画像の上に別のスペーサーを追加します
スペーサーは要素間のパディングを維持するため自動的に最小サイズとなりますこの場合画像がコンテナの端まで移動できるように minLengthをゼロに設定しましょう
バナーにパディングも追加します表示している時にスペースができるので画面の端にぶつかりません
インスペクターをクリックすると
ビューのパディングをオンにできます
見やすくなりましたフォントサイズも大きくします
テキストサイズだけでなくシンボル画像も大きくなるので注意が必要ですシンボル画像はテキストと同じフォント情報を自動的に使用しますヘッドラインフォントを使ってみましょう
次にスパイシーさを表現するため赤い背景にします
backgroundモディファイアを使用すると適用先ビューの後ろに任意のビューを配置できますこれらはビューに単色の背景を与えるために単色で使用されます
ビューの背景が赤くなったのは小さな範囲だけです
SwiftUIでは表示サイズはコンテンツに合わせて調整されていますこの場合画像とテキストは自然なサイズになり適用したパディング用のスペースもありますスペーサーとHStackを追加することでエッジからエッジまでの拡張が可能になります
最後に文字色を黄色にしてスパイシーなテーマに合わせます
スモールキャップを使用するためにフォントを更新します
いいですねスパイシーなサンドイッチの場合にのみバナーを表示したいと思います宣言構文の“IF”を使用することで簡単にできます
サンドイッチがスパイシーな場合は
バナーを表示します
表示を確認するにはプレビューデータを変更しスパイシーでない別のサンドイッチを表示します複数のバージョンを表示するようにプレビューを設定することも可能ですプラスボタンをクリックするとプレビューのコピーを追加できます
使用しているデータを更新し
様々なサンドイッチを表示することができますスパイシーなバナーを含むビューと含まないビューの確認が可能です
編集を行う際にビューの両方のバージョンが確認可能です
Xcodeで別のプレビューを追加するにはビューの別の具体例を追加するだけです
拡大した時にこのバナーがサンドイッチ画像の邪魔にならないように変更しますズーム時に画像を非表示にするには条件を更新するだけです
ズームするとバナーは非表示となります
アニメーション化してフェードインとフェードアウトも可能です
別のtransitionを設定しアニメーション動作のカスタマイズができます
下端で“.move”を使用してみましょう
スライドアウトスライドインができます
アニメーションが続いている時にタップすると
アニメーションが向きを変えて戻りますすべてがインタラクティブで常に正しい位置で終了します詳細ビューで作成したものを確認します表示するサンドイッチで構成されていますこれは親ビューによって渡される派生値ですズームを確認する状態プロパティもありますフレームワークによって永続化され縦横比のコンテンツモードを制御します
バナーはスパイシーなサンドイッチでズームされていない場合にのみ表示されます
スライドインとスライドアウトを行うための transitionも指定します transitionの間に何が起きているのでしょうか？削除するとビューは新しい位置のオフスクリーンにアニメーション化されます SwiftUIはアニメーション終了まで待機して階層からビューを実際に削除しますそして戻った時に SwiftUIがオフスクリーンを挿入しアニメーションで元の位置に戻しますアニメーションを使用し階層構造からビューの追加や削除が簡単にできます
このアニメーションは箱から出してすぐにインタラクティブにできるのです
イベント駆動型ではなくデータ駆動型の長所です先ほどカイルが説明したイベントはアニメーション化中にも発生する可能性がありますアニメーションの開始と終了ではさらに多くのイベントがありますこのようなものをイベント駆動型の世界で構築するのは非常に困難ですが SwiftUIではコードの1行にすぎません
サンドイッチのListに戻りこのAppを仕上げます
ここまではマルチプラットフォームの Appテンプレートを使用した― iPhoneの作業を説明しました他のプラットフォームでの作業もご紹介します実行先をiPhoneからiPadに切り替えます
そしてライブにします
SwiftUIはナビゲーションビューを分割ビューに変換しました左側でサンドイッチを選ぶと右側に表示されます
サンドイッチを選択していない場合空白エリアしか表示されないためサンドイッチの選択を可能とするプレースホルダーを示すにはナビゲーションビューに2つ目のビューを追加するだけです
複数のビューをスタックに追加することができます
それらのビューをスタックするかわりにナビゲーションビューが付与されます
この場合最初のビューが左側に表示され２番目のビューが右側のビューのプレースホルダになります iPhoneではプレースホルダは自動的に削除されます
次にMac OSを見てみましょう
iPadと同じプレースホルダが表示されています
すべてのAppleプラットフォームで同じビューコードモデルコード― そしてアプリコードを使用できますまたプラットフォーム特有の改善を加えることも可能です
サンドイッチのListを変更可能とするため編集サポートを追加しデータモデルをもう少し現実的なものとします現在 Appのデータは完全に静的ですサンドイッチの配列を作りましたがこの配列は常に必要となりますモデルを更新しサンドイッチを含むルートストアオブジェクトを作成し― 時間の経過とともに変更できるようにします
サンドイッチストアを使って事前に作成されたモデルファイルをドラッグします
サンドイッチを販売する場所ではなくデータストアのようなストアです
サンドイッチを含む変更可能なオブジェクトであることに注意します
単集合インスタンスもテスト用に用意しています目的を変更する時には SwiftUIへの指示が必要です
ObservableObjectプロトコルに準拠します
次に@Publishedで確認したいプロパティにマークを付けます
新しいモデルをどのように使用するのでしょう？
@Stateを使用し値に関する真実のソースを作成したのと同様に
@StateObjectを使用し変更可能なオブジェクトの真実のソースを作成します
StateObjectはビューの変更時に自動的にオブジェクトを監視しビューを更新します StateObjectをビューコードに追加することも可能ですこれはApp全体のストアなので Appコードに入れた方がよいです
Appコードでどのようにモデルにリンクできるかを確認します
最初に使用したコードです先ほどのビューコードと似ていることに注目してください Appプロトコルに準拠する構造体です bodyプロパティではビューと同様に必要なものを構築します WindowGroupを使用して Appのすべてのウィンドウで使用するビューを指定しますこのAppの特徴は @main属性を持っていることです Swiftにこの構造体がAppの出発点であることを伝えます
ストアとStateObjectを追加します
AppはState StateObjectとその他の特殊なプロパティが使用できます次にストアをビューコードに渡しましょうそれをビューの初期化に渡します
ビューコードに戻ります
定数サンドイッチをストアのプロパティに置き換えます
このオブジェクトを ObservedObjectにすることで変更の監視をSwiftUIに通知します
ストアからサンドイッチを引き出すため Listを更新します
最後にプレビューを更新しテストストアを使用します
ストアからデータを引き出し編集サポートを追加する準備ができました
スニペットからストアに変更を加えるための便利な機能を紹介します
新しいサンドイッチの追加やサンドイッチの移動それに削除が行えます
ForEachのListでは onMoveモディファイアを追加し
“moveSandwiches”メソッドを呼び出せます
onDeleteを追加すれば
“deleteSandwiches”も
この変更を加えただけで Appに戻れます
スワイプしてListから行を削除することもできます削除するとSwiftUIからコールバックが呼び出され
ストアからサンドイッチが取り除かれます
UIが更新されて変更が反映されます Mac OSの編集サポートに必要なものは以上です iOSでは編集モードに切り替える方法を追加する必要があります編集ボタンをツールバー項目に追加しましょう
toolbarモディファイアを使用して
SwiftUIビューをツールバー項目に加えますその中に編集モードを自動で切り替えられる編集ボタンを追加します iOSでのみ表示したいのでボタン周辺に“if os（iOS）”を追加し
ツールバーにのみ追加されるようにします
Listの編集モードを切り替えましょう
各データ行には編集コントロールがありますが下部の静的要素にはありません SwiftUIは編集コントロールを必要な行だけに自動的に表示します
アイテムの並べ替えやタップによる削除ができます
新たにサンドイッチを追加するボタンを作るには toolbarモディファイアに別のビューを追加しますこのビューでは “add”というLabelが付いたボタンと
makeSandwichメソッドを呼び出すアクションを作ります
ボタンをタップすると新しいサンドイッチが現れました
追加内容をざっと確認しましょうまず編集操作をListに追加する方法です
これらのモディファイアと
データを変更する関数のみ使用しました
サンドイッチタイプを特定する方法を覚えていますか？ ForEachはコレクションへの変更を監視し正しい挿入と削除を合成するため Listに行を加除する指示は不要ですつまりデータソースの不整合の例外がなくなりました
toolbarモディファイアを使用し
Listを編集して新項目を加えるツールバー項目も追加しました最小限のビューコードでこの洗練されたList UIを作成できます
Appはすぐに構築できましたが製品として必要な作業はまだあるとお考えでしょう Dynamic Typeやダークモードローカリゼーションなどへの対応です SwiftUIを使えばそれらも自動的に行えますプレビューを使用して簡単にテストできますプレビューを見てみましょう “プレビュープラス”ボタンをクリックし 2つ目のプレビューを追加します
次に“検査”ボタンをクリックして新しいプレビューを設定
Dynamic Typeのサイズをより大きな値にします
見栄えが良くなりましたね
このプレビューの変更で追加されたコードを見てみます
Xcodeはプレビューの環境で値を設定するモディファイアを追加しましたプレビュー環境ではビューに関するコンテキスト情報を設定でき情報はビューの階層を流れすべてのビューの側面を変更しますビューにカスケード変更を加えるのに便利です
別のプレビューインスタンスを追加しましょう
今回はプレビューインスペクタで
カラースキームを“暗い”に設定
すべてが自動的に表示されます最後に他言語による Appの動作を見てみましょう英語の文字列ファイルを Appにドロップします
これらのファイルのローカライズを Xcodeに指示します
次にプロジェクトファイルに移動し
ローカリゼーションをアラビア語にインポートします
ビューコードに戻り再度プレビューを追加します
環境のレイアウト方向を
右から左に設定します
既にすべてが機能していますね
最後にロカールの設定を
アラビア語に
ローカライズされました私たちのコードが優れているのは
これらの機能への対応が簡単な点ですローカライズを可能にする文字列のマークアップも不要でした文字列リテラルを使用してテキストを自動的に推測しローカライズします
テキストはモデル値と同様にそのまま使用する必要があります文字列補間を使用したローカライズも可能ですぜひSwiftUIをご活用くださいこれらの動作は無料で入手できより迅速に優れたAppを構築できます
構築した際は今一度見直し正しく機能するかを確認しましょうダークモードバージョンを使用し Appをライブにします今回はデバイス上で実行します
iPhoneが接続されているのでこのボタンをクリックして
ビューを送信しプレビューします
サンドイッチのListですタップすると詳細が表示されます
タップでズームすると transitionのある “スパイシーな”バナーが非表示になりますこのアニメーションは常にインタラクティブです
Listの編集もできます
上に移動します
場違いなホットドッグは削除して
新しいサンドイッチを追加します
今回のAppについて最後に１つ補足しておきます App全体を構築し高性能な動作のテストを Appを一切使わずに実施した点です Xcodeプレビューにより Appの表示編集デバッグが未だかつてなく高速に行えますご視聴感謝します SwiftUIをお楽しみください

struct SandwichDetail: View {
    let sandwich: Sandwich

    var body: some View {
        Image(sandwich.imageName)
            .resizable()
            .aspectRatio(contentMode: .fit)
    }
}

18:30 - Views are composed

struct SandwichDetail: View {
    let sandwich: Sandwich

    var body: some View {
        Image(sandwich.imageName)
            .resizable()
            .aspectRatio(contentMode: .fit)
    }
}

19:52 - View are dynamic

struct SandwichDetail: View {
    let sandwich: Sandwich
    @State private var zoomed = false

    var body: some View {
        Image(sandwich.imageName)
            .resizable()
            .aspectRatio(contentMode: zoomed ? .fill : .fit)
            .onTapGesture { zoomed.toggle() }
    }
}

21:40 - Where is truth?

struct SandwichDetail: View {
    let sandwich: Sandwich
    @State private var zoomed = false

    var body: some View {
        Image(sandwich.imageName)
            .resizable()
            .aspectRatio(contentMode: zoomed ? .fill : .fit)
            .onTapGesture { zoomed.toggle() }
    }
}

リソース

関連ビデオ

WWDC23

WWDC20

WWDC19