複数のウインドウで使用できるAppを構築する

(音楽)

(拍手) 私はジャン･トリヴェディ UKitフレームワークチーム 所属です

アプリケーションの マルチウインドウ化の話をしましょう iOS 13ではアプリケーションを マルチウインドウで表示でき ユーザの生産性が大幅に向上します

今日は重要な点を３つ話します まずiOS 13における マルチウインドウを可能にする― アプリケーションのライフサイクルの 変更について触れます

続いて 新たなUISceneDelegateで― 行うべきことを話します

最後はベストプラクティスを見て ユーザがマルチタスクを― スムーズに行える環境を 提供できるようになりましょう

まずはiOS 12以前の― Appデリゲートの役割と 責任について話します

１つ目の役割は プロセスレベルの イベントのアプリケーションへの通知で システムはプロセスの起動や終了時に Appデリゲートに通知していました もう１つの役割は― UIの状態をアプリケーションに 知らせることです didiEnterForegroundや willResignActiveで― システムがUIステートを 知らせます

iOS 12以前なら問題ありません アプリケーションの プロセスは１つで― それに対するUIインスタンスも １つでした

皆さんのAppデリゲートは このような感じでしょう もっと長いとは思います

didFinishLaunchingWithOptionsで データベースへの接続や データ構造の初期化などワンタイムの 非UIのグローバルセットアップを行い その後すぐUIの設定に入ります

iOS 12以前では有効ですが iOS 13でも同様とは言えません アプリケーションの プロセスは１つです しかし複数のUIインスタンスや シーンセッションを共有するからです

Appデリゲートの責任も変わります プロセスイベントや ライフサイクルは そのままですが― UIライフサイクルの責任は負いません 代わりにSceneデリゲートが担います 皆さんへの影響は？ UIのセットアップや分解作業は Appデリゲートでなく Sceneデリゲートの 対応するメソッドで行います

新しいシーンライフサイクルを 採用している場合― iOS 13はAppデリゲートメソッドの 呼び出しはしません 新しいSceneデリゲートメソッドを 呼び出します 大抵１対１でマップするため シンプルです iOS 13でマルチウインドウを 導入しても― iOS 12以前のサポートも可能です 単に両方のメソッドを保持して― 実行時は UIKitが的確なほうを呼び出します

メソッドの話をする前にもう１つ Appデリゲートには 責任が１つ加わります シーンセッションの作成や 廃棄が行われると― システムが Appデリゲートに通知します

このライフサイクルを 形にしてみましょう 青のアプリケーションを 初めて起動するとします コールスタックで見ましょう Appデリゲートが didFinish LaunchingWithOptionsを受けます ワンタイムの非UIセットアップでも 構いません

直後にシステムが シーンセッションを作成します しかし実際のUISceneの作成前に アプリケーションは― UISceneConfigurationを 要求されます Sceneデリゲートや Storyboardを指定し 作成したいシーンの シーンサブクラスを指定します シーンコンフィギュレーションは コードで動的に設定もできますが― info.plistで 静的にするといいでしょう

そして 正しいコンフィギュレーションを選択 メインシーンコンフィギュレーションや アクセサリシーンがあります ここでオプションパラメータを確認し 正しいシーンコンフィギュレーションを 選ぶ コンテキストとして使います

info.plistで設定した場合には nameで参照し― 次のsessionRoleに 渡していることを確認します

アプリケーションは起動し シーンセッションもあります UIは表示されませんが Sceneデリゲートが― シーンセッションに接続しています

新しく指定された UIWindowイニシャライザで― UIWindowの設定をしていきます windowSceneを渡していますね しかしウインドウを設定するため 関連のuserActivitiesや stateRestorationActivityの 確認も必須です 詳しく説明しましょう

こちらが青のアプリケーションです ユーザが上にスワイプして ホームに戻ると… willResignActiveと didEnterBackgroundが― Sceneデリゲートに呼び出されます その後 ある時点で― シーンの切断が起こり得ます なぜでしょう？ バックグラウンドに入った後 リソース回収のため― メモリからシーンが 解放されることがあります Sceneデリゲートも同じです Sceneデリゲートの ウインドウ階層や― ビュー階層も同様になります

シーンに関連する多量のリソースが メモリに保持されているので 割り当てを解除します ただしユーザデータなどは 消去しないでください シーンが再接続し 戻ることがあります

ではユーザが 本当に消したい場合で― 上にスワイプすると どうなるのでしょう？ didDiscadSceneSessionが 呼び出されます

これでテキストの下書き等の シーンに関連するユーザデータは― 完全に消去することが可能です

まだあります アプリケーションのプロセスが 実行されていない時に― スイッチャーからUISceneを 削除した場合です システムは 破棄されたセッションを追跡し 次回起動時にすぐ呼び出します

次はアプリケーションに統合可能な アーキテクチャパターンの話です

State Restorationから始めましょう iOS 13では もはや難しいものではありません

シーンベースのState Restorationを 実装することが重要です 理由は何でしょう？ アプリケーションのスイッチャーです 旅行に関する４つのドキュメントの セッションを開いていますが― 持ち物表と旅程に注目しましょう ある時点で― バックグラウンドの残りの２つは 切断され解放されます State Restorationを実装していないと 戻った際に― 編集していたドキュメントが 見られなくなります 全部初めからで ユーザにとって快適ではありません

解決方法です iOS 13には新たに― シーンベースの State Restoration APIが入っています

ビュー階層ではなく stateのエンコードで― シンプルに ウインドウを再作成することが可能です

これも全部 NSUserActivityに 基づいており アプリケーションが― SpotlightやHandoffを活用する場合も 使うことができます iOS 13では State Restorationのアーカイブは― 他の部分の データ保護機能クラスと一致します

コードを見ましょう

SceneDelegateで stateRestorationActivityを実装します 続いて現在のウインドウで 最もアクティブな― 関連ユーザアクティビティフォームを 探すメソッドを呼び出します 返しましょう

シーンがフォアグラウンドに戻り 再接続された際― stateRestorationActivityが 含まれているか確認します あれば それを使います なければ 新たなウインドウを作成します いずれにせよ ユーザは― バックグラウンドでシーンが 切断されることには気づきません

マルチウインドウを 導入する際に― 注意すべき もう１つの問題があります アプリケーションシーンの同期です 私の新しい チャットアプリケーションは― iOS 13のマルチウインドウの サポートを導入したばかりです

後で登壇するジョヴァンニと チャットをしているところで― 同じものを２つのインターフェイスと シーンで同時に見ています ジョヴァンニへ メッセージを送ってみます 片方しか更新されません なぜでしょう？

多くのiOSアプリケーションで 見られますが メッセージの送信などのイベントを ビューコントローラが受け取ると― ビューコントローラが自らのUIを 更新します そしてモデルや モデルコントローラに通知するのです １つのUIインスタンスであれば これでも平気です ２つ目なら どうでしょう？ 別のシーンで 同じデータを表示するものは― 新しいデータで更新するよう 通知は受けません 原因は分かりましたね 解決もできます ビューコントローラが イベントを受信すると― すぐにモデルコントローラへ 通知のみ行います モデル関連のサブスクライバや ビューコントローラに 新しいデータで 更新するよう伝えられます

Delegateや Notificationでも可能です 今年の新しいSwift Combineも使えます 今回はアプリケーションへの統合を考え Swiftを使用します メッセージ送信時に“戻る”を押すと 呼び出されるメソッドです ビューコントローラが 自らのビューを更新します

モデルコントローラに 続けるよう通知します ビューコントローラが 自分で変更を行わないように― いったん コードを取り除いておきます

モデルコントローラのaddメソッドが やっていることはシンプルです 例の新しいメッセージの持続です しかし他のビューコントローラや シーンの更新を― モデルコントローラが 通知するようにしたいのです

どうすべきでしょうか このイベントを パッケージ化する構造が必要です 役割を固定でき デバッグや―

テストも簡単なものです “UpdateEvent”という データ型を作りましょう 値の関連するSwift列挙型です NewMessageを加えます メッセージの受信時に モデルコントローラが作成し 関連のビューコントローラや シーンに送られます 投稿のため NSNotificationCenterを バックストアにし― postメソッドを１行加えましょう UpdateEventを作成し サブスクライバに投稿できます

NewMessageNotificationNameに notificationをpostするだけの実装です コツとしては UpdateEventオブジェクト自体を― Notificationオブジェクトに含め ひと目で分かるようにします

モデルコントローラに 新しいメッセージの追加が通知され 新しいイベントを作成して 投稿を呼び出せます

次にビューコントローラへ移ると― NewMessageNotificationNameがあります そして引数から― 通知を得る ハンドラメソッドを作成します UpdateEventを notification.objectに渡すと― 通知からすぐ イベントの取り出しが可能です

イベントの種類の切り替えも容易で― 列挙型の作成により メッセージも引き出せます

ついにユーザインターフェイスの 更新です

新たなアーキテクチャを実装した後は どうなるでしょう？ シーンが更新されました (拍手) 濃い内容でしたね AppデリゲートとSceneデリゲートの 違いに触れました 主要な Sceneデリゲートメソッドで― すべきことも確認しました iOS 13でState Restorationが 重要な理由と― シーンベースのAPIの 活用方法も話しましたね データ共有時に すべてのシーンを同期するための― 一方向データフローの 作成パターンも説明しました 以上です (拍手)