iOS 13向けにUIをモダナイズする

(音楽)

(拍手) 皆さん どうも このセッションではiOS 13での UIの実装について話します 私はデイヴィッド･ダンカン 後ほど同僚と交代します ラッセルとカイル ジェームズとモハメッドです

今回は６つのことを 話題にします 第１にアプリケーションを 柔軟なUIに対応させること 第２と第３に バーや表示の外観をどう改良したか 第４にアプリケーションに 適用できる新たな検索機能 第５にアプリケーションの生産性を 上げるために使える新しいジェスチャ これで不可能だったことも 可能になります 第６にコンテクスチュアルな メニューAPIです まず柔軟なUIの話をしましょう

柔軟性を獲得する第一歩は ユーザがアプリケーションを ローンチする時に最初に見るものです StoryboardはiOS 8の頃より UIを特定する人気の方法です iOSの始まりから サポートしている別の方法もあります Launch Imagesです サポートする画面サイズごとに 画像を特定し 新しい画面サイズを導入するたびに 見直します これは柔軟性に欠けます そこで 今度の春 2020年４月に iOS 13 SDKに関連付けられる アプリケーションは Launch Storyboardsを提供しないと Apple Storeに認められません Launch Imagesだけでは 提出できなくなります まだの人は この機に Launch Storyboardsを導入しましょう それが次の変化につながります

従来は新しい画面サイズの ハードウェアを導入すると アプリケーションが レターボックス化されました それも過去の話になります アプリケーションが iOS 13 SDK用に構築されているなら 常にネイティブに 全画面表示されます iOS 13用に構築された アプリケーションなら どんなサイズでも 適切なAPIを使い 正しいレイアウトを実行します iPad用アプリケーションを 開発しているなら 画面分割のマルチタスク機能にも 適用されます すなわち大半のアプリケーションは 没入型の体験を 提供するのでない限り 画面分割のマルチタスク機能を サポートします どんなサイズの アプリケーションを 他のどんなアプリケーションと 並べても問題ないのです サイズ変更のモードなどを サポートできるか不安でしょう iPad用アプリケーションなら macOS Catalinaに加える 新たなサポートで開発できて 好きなサイズに 変更することができます 簡単に言えば Launch Storyboardsを導入しましょう アプリケーションをローンチする時に Launch UIを入手する方法です どんなサイズもサポートできるよう レイアウトを整えます 最小サイズのiPhoneでも 最大サイズのiPadでもです 画面分割のマルチタスク機能を サポートできるようにもしてください 2020年４月までに 必要になるからです 続いてバーの話に移ります

ベータ版をインストールした後 iPhoneを見ると バーはこのようになっています 上にスクロールすると 背景がドロップアウトします 下にスクロールすると スムーズに元に戻ります

同様にiPadに Split View Controllerがあれば 両サイドを別々に動かせます 大きな文字をサポートするかは 関係ありません 個別に反応します どちらの背景が現れるかは スクロールの位置によります

どのように取り入れれば アプリケーションで動かせるのか 取り入れるのは簡単です iOS 13にリンクすれば 無料で入手できます でもアプリケーションで スムーズに動かすにはコツがあります そこで導入したのが Appearance Customization APIです ナビゲーションバーのカスタマイズを 見ていきましょう

最初にやることは 外観を示すオブジェクトの作成です UINavigationBarAppearanceです UIBarAppearanceのサブクラスで UINavigationBarのための カスタマイズオプションを カプセル化しています ナビゲーションバーに 不透明な色を使いたいので configureWithOpaqueBackgroundが 提供するデフォルト値を使います ナビゲーションバーの背景を ライトおよびダークモードの 不透明色にします ラベルの色も変更しましょう titleTextAttributesや largeTitleTextAttributesで カスタムカラーに設定します ライトおよびダークモードで 映える色です navigationBarの standardAppearanceにアタッチします standardAppearanceとは何か 見てみましょう

ナビゲーションバーに大きな文字を 使わなければスタンダードサイズです これがstandardAppearanceです 他の外観設定を 指定しないのであれば 他の２つのためのデフォルトを 作るベースにします これは後で話します

小さなiPhoneを横向きにすると compactAppearanceです これがそうですね 先ほど見たようにiOS 13では スクロールビューをプルダウンすると ナビゲーションバーの背景が透明に これがscrollEdgeAppearanceです ナビゲーションバーが スクロールビューと連動する時 スクロールビューのトップで使うのは scrollEdgeAppearanceです デフォルトは透明な背景です だからiOS 13では シームレスな外観を得られます

バーボタンアイテムの 外観もカスタマイズできます buttonAppearanceと doneButtonAppearanceを使います

ここでやめてもいいでしょう ナビゲーションバーが カスタマイズされました ツールバーとタブバーも すべてのバーを同様に カスタマイズできます 各クラスがUIBarAppearanceの サブクラスを使って カスタマイズします ToolbarAppearanceは navigationBarAppearanceの サブセットなので 目新しさはありません でもTabBarAppearanceは違います タブバーが違うからです

タブバーには追加の カスタマイズオプションがあります この３つのレイアウトです stackedLayoutAppearance iPadに見られる inlineLayoutAppearance 小さいiPhoneの compactInlineLayoutAppearance すべてをまとめて すべてのバーに使える カスタマイズです もう１つあります

新しいリマインダーでは リストにナビゲートすると リストに合わせて タイトルの色が変わります ナビゲーションのアイテムごとに 外観をカスタマイズします navigationBarにプッシュする ナビゲーションアイテムに基づいて 外観を指定できます ナビゲーションアイテムは ビューコントローラと連動するので ナビゲーションコントローラに それを使います 実際に見てみましょう

navigationItemはnavigationBarと 同じプロパティを持ちます だから navigationBarから standardAppearanceを選び コピーして その外観から切り離し 好きな変化を加えます 透明にしたければ そのように設定します バーボタンアイテムの 外観なども変えられます それをナビゲーションアイテムに 振り分け ビューコントローラや ナビゲーションアイテムが最新なら navigationBarベースの外観よりも これを使います ビューコントローラが プッシュされたら いつでもナビゲーションバーを カスタマイズできます

続いてラッセルが 表示の話をします (拍手) ありがとう こんにちは　ラッセルです iOS 13には表示の スタンダードなデザインがあります 紹介できるのが楽しみです 例えば連絡先アプリケーションの ＋をタップして連絡先を追加する時 新しい表示はこんなスタイルです 従来の全画面表示とは異なります rootViewControllerの ビューです スケールダウンしておらず ビュー階層から排除されていません アプリケーションのどこにいるかの コンテキストを伝えるデザインです 丸いトップの外観が 指示器の役割をします この表示はインタラクティブに システムのどこからも消せます (拍手) ありがとうございます (拍手) この新しい表示スタイルは 何でしょう この表示はシートと呼ばれ 目新しいものではありません デザインは新しいけれど 元になるのは既存の UIModalPresentationStyleの pageSheetとformSheetです これらのスタイルはコンパクト幅の 全画面表示に用いられていました それがシートになります レギュラー幅のレイアウトと異なる コンパクト幅の特別なレイアウトです

例を見てみましょう iPhoneの外観です 先ほど見ましたね 横向きにすると 全画面レイアウトになります

iPadも忘れていません シートを再考しました ページシートが 画面の中央にスタックされ ビューコントローラのトップに スタックができます

新しいサイズは読みやすい幅に 従っています 文字コンテンツに最適です ユーザが選ぶ文字サイズで 読みやすい幅が変わるので ページシートのサイズも変わります こんな感じや こんな感じに より広い幅を好むのであれば スタックされた外観を選べます

新しい外観は簡単に アプリケーションに適用できます この移行を容易にするために 時間をかけたからです

デフォルトのUIViewController ModalPresentationStyleは automaticという スタイルになりました automaticはダイナミックなスタイルで 表示の際に解決されます 実際に例を見ていきましょう

カスタムビューコントローラです これはフォトライブラリを表す UIImagePickerControllerの表示です モーダルな表示スタイルの セットはありません iOS 12でイメージピッカーを 全画面表示したのと同じコードで どこも変えることなく シートになっています

UIImagePickerControllerを カメラモードで表示する設定にすると iOS 12と同じようにiOS 13でも カメラが全画面表示になります automaticが働いています ビューコントローラの設定により スタイルが変わります コードの変更は必要ありません

では ビューコントローラを 表示するには？ UIViewControllerの カスタムサブクラスを インスタンス化して表示すれば シートとして表示されます デフォルトでautomaticが pageSheetになるのです 大半の表示に ふさわしいスタイルです コードの変更は不要です

次のケースではどうでしょう 全画面表示が必要な カスタムビューコントローラがあります カスタムカメラなど 没入型の体験です このコードは没入型の体験を シートにしてしまうのか？ 心配は要りません 修正は簡単です modalPresentationStyleを 全画面にすればいいのです プロパティは デフォルト値のままで 意図的に逸脱したい時に 明確な値を指定するだけです

ポップオーバーはどうでしょう ポップオーバーは 常にシートになります ポップオーバーはレギュラー幅で シートはコンパクト幅にしたいなら modalPresentationStyleを popoverにするだけです 希望した動作を得られます

Pull To Dismissをサポートするために やるべきことは何でしょう

全体としては何もありません シートとして表示する時は プルダウンできます ジェスチャ認識装置を 全表示ビューに置きます 非インタラクティブなエリアに プルダウンするとシートになります スクロールビューのトップを越えて プルダウンすると それでもシートが プルダウンされます

しかしシートのプルダウンを 望まないこともあります 例えば同じシートを表示し データを入れるなら シートのプルダウンは不適切です ユーザが変更を破棄するか 保存するか分からないからです プルダウンしようとすると ラバーバンディングします Action sheetが表示されて コンテキストから逃れるために ユーザが選べるアクションを示します

このエクスペリエンスには ２つの新しいAPIがあります 最初のisModalInPresentationは UIViewControllerのプロパティです これを任意のViewControllerで trueにすると シートがモーダルになり 消すことができません ラバーバンド現象が起きます このプロパティが isModalInPopoverに代わり シートとポップオーバーが 消えるのを防ぎます

２つ目は新しいUIAdaptivePresentation ControllerDelegateメソッドで presentationController DidAttemptToDismissです presentationControllerで delegateをセットすると モーダルの状態でプルダウンした時に UIKitはこのメソッドを呼び出し Action sheetを表示できます

これらのAPIの関係性です DidAttemptToDismissの呼び出しは isModalInPresentationがtrueの時のみ ユーザは消すためにプルするので 力と速度が加わります これがモーダルフローです こんな例をいかに実装するか サンプルを用意しました リンク先にダウンロード方法が 説明されています 他にもあります delegateのコールバックです presentationController ShouldDismissは delegateからの消去を回避し WillDismissはViewControllerの TransitionCoordinatorを把捉します 設定するのは アニメーションの他に インタラクション変更通知や アニメーション終了ブロックなどで DidDismissは stateのクリーンアップに有用です ユーザがシートをプルダウンし 移行を終了してから呼び出します

これらのコールバックが UIPopoverpresentationController Delegateコールバックに代わります これらのAPIはシートと ポップオーバーの両方で呼び出されます

ユーザがシートをプルダウンせず 引き上げ続けるなら delegateはShouldDismissと WillDismissを複数回 受け取って それからDidDismissを受け取れば 呼び出します

次はShare Extensionsの話です iOS 13 SDKでビルドする時 Share Extensionsが このメールのようにシートになります Pull To Dismissも使えます メインビューコントローラは Information Property Listで 指定されますが ユーザがデータを入れ始めたら isModalInPresentationに設定を メインビューコントローラが UIAdaptivePresentation ControllerDelegateに順応し DidAttemptToDismissを 実装するなら ユーザがプルダウンすると そのメソッドを呼び出します 他のdelegateメソッドは 呼び出しません

この動作は将来 手に入ります

皆さんに 考えてほしいことがあります 最初はUIViewControllerAppearance コールバックについてです 全画面表示中の ビューコントローラが 受け取る外観のコールバックと シート表示は何が違うのでしょう 全画面表示中の ビューコントローラのビューは ビュー階層から排除されます 結果として viewWillDisappearを受け取り 表示の移行が始まります 移行が終わると viewDidDisappearを受け取ります 消去の移行中も同じです ビューがビュー階層に戻ると viewWillAppearとviewDidAppearを 受け取ります しかしシートの表示では ビューコントローラのビューの表示は ビュー階層から排除されず 外観のコールバックから 何も受け取りません これらのコールバックのコードは シートが消える時に実行します 表示コントローラのWillおよび DidDismissメソッドを見てください

第２に考えてほしいのはビュー階層に プライベートビューを入れたことです UIWindowと rootViewControllerの間です この変更は影響しません デバッガに現れても 驚かないでください UIWindowとrootViewControllerを 結ぶのがUIKitの実装です このビューを管理し ビュー階層に加えるのはUIWindowです アプリケーションに所有されない ビュー階層の構造は 通告なしに変わることがあります コードを書く時に 気をつけてほしいのは プライベートビュー階層を 想定しないことです

アプリケーションで シート表示を使う方法です ほとんどのUIで使えますが 例外もあります ユーザがプルダウンさせる時は モーダルフローを実装してください 詳しく示したサンプルを 用意しています 活用してください

ありがとうございました カイルが検索の話をします (拍手) お疲れ様

ありがとう　ラッセル

こんにちは カイルです UIKitの担当です 新しくなったiOS 13の検索を 紹介します

これは従来のメールアプリケーションの 検索インターフェイスです UIKitが提供しています UIViewControllerのサブクラスの UISearchControllerです ユーザには なじみのもので アプリケーションで入手できます 多くの部分から構成されています 最大の部分がUISearchBarです 画面の一番上に見えます 検索バーにはキャンセルボタンを含む いくつかのコンポーネントがあり Scope Barと呼ばれるボタンも 検索フィールドの下にあります

iOS 13のScope Barは 外観が更新されています

アプリケーションは検索バーの 要素を隠すことができます UISearchControllerに 管理されていてもです アプリケーションにScope Barや キャンセルボタンが不要でも UIの状態に応じて 使えるようにしたいでしょう UISearchControllerの 新たなプロパティで直接 制御できます

UISearchBarの パブリックプロパティとして searchTextFieldを公開します カスタマイズが簡単になります (拍手)

searchControllerの外観を カスタマイズするために

UISearchControllerで これらのプロパティをfalseにし キャンセルボタンとScope Barの 可視性を制御します

searchTextFieldプロパティを使い UISearchTextFieldの インスタンスを参照 変えたいテキストフィールドの 全プロパティを変更します UITextFieldのサブクラスで スタイルプロパティは入手できます

UISearchControllerの動作が 検索の外観と消去に関わります スタンダードな動作は 検索フィールドをタップして 検索バーをアクティブにすると 画面の上部につり上げられます でも見えていたコンテンツは 消えていません

この場合は写真アプリケーションに 入力すると検索結果が表示されます

アプリケーションが提供する UIViewControllerに実装されています Search Results Controllerです

すべてのアプリケーションが 同じではありません メールアプリケーションの場合 検索フィールドをタップすれば 検索リストが提示されます

これはUISearchControllerの Search Results Controllerです iOS 13では この機能も 使っていただけます

(拍手) showsSearchResultsControllerの プロパティをtrueに設定し automaticallyShowsSearchResults Controllerで自動的動作を制御できます

検索の別の目玉機能です

メールや写真など システムにあるアプリケーションでは これらの提示された検索の結果が トークンになります より複雑な検索クエリを 視覚的に表示しています

UISearchTextFieldの どのインスタンスにあっても 新しいUISearchToken APIにより アプリケーションで使える機能です このトークンがコピー＆ペースト ドラッグ＆ドロップをサポートします すべてのアプリケーションで 同じ実装です (拍手) 例えば写真でも使っています 保存されたり推定されたりした 人 場所 物の検索を提供します Search Results Controllerの エントリをタップすると 部分的な入力でも 写真はトークンに変わります

UITextFieldのサブクラスなので テキストとインタラクトします 実際は常にテキストに先んじます

トークンを 検察フィールドに入れると 挿入ポイントが 検索フィールドの最後でも トークンは先頭に現れます

トークンが選ばれました トークンとテキストを含む形で 選択を広げることができます

トークンの作成は簡単です

selectedTextRangeで トークンにするテキストを決めます UISearchTokenオブジェクトを作成し searchTextFieldで このメソッドを呼び出して この範囲のテキストの部分を トークンに替えます アプリケーションでトークンの 挿入と削除ができるので 好きな意味を付け加えられます

UITextFieldが応じるのが UITextInputというプロトコルです プログラムで選択するなら UITextInputの局面を 理解することが重要です 範囲と配置です

普通のテキストフィールドでは すべての文字に UITextPositionが 割り当てられています 検索フィールドのコンテンツである ドキュメントの始めと終わりにある― ２つのよく知られた配置に比べて 相対的です

この配置を使って UITextRangeを作ります 例えばコンテンツの部分を プログラムで選択します

トークンも選択できるので UITextPositionを得ます

でも検索フィールドの テキストの長さは ドキュメントの始めからの距離と 最後の文字の配置で異なります これが重要で 例えばテキストの部分を選ぶために UISearchTextFieldは textualRangeというプロパティを エクスポートします textualRangeの始めは フィールドにおける トークンではない最初の文字です その終わりは ドキュメントの終わりです これはテキストの characterIndexに相当します

アプリケーションの 新機能を利用して UISearchControllerで 入手可能になったプロパティと カスタマイズオプションを 見てみましょう UISearchTextFieldの使用は UISearchBarか UITextFieldを使える場所なら どこでも可能です UITextFieldで使える カスタマイズオプションも すべて活用します UISearchTokenで複雑なクエリを 簡潔で編集可能な形で表し コピー＆ペースト ドラッグ＆ドロップをサポートします

多くの先端技術があります このセッションのWebサイトで サンプルを提供し トークンの効果的な使い方を 実演します

次はジェームズが ジェスチャについて話します (拍手) ありがとう どうも ジェームズ･マクガランです iOS 13に追加した 新たなジェスチャについて話します テーマは選択と整理 一般的な編集のショートカットなどです

これが今日 話すことです 大半の動作は自動かつ 無料で手にできるものです 何が新しいのか 新機能を活用するために 何が必要なのかを話します まずカスタムテキストビューの テキスト選択ジェスチャ機能です

iOSでジェスチャを使って テキストを選択する方法は いろいろあります iOS 13ではタップしてホールドすれば ハイライトになります 長押しで選択ループが現れ 挿入ポイントを移動できます パラグラフを３回 タップすれば パラグラフ全体を選択できます ジェスチャに適したネイティブな テキストウィジェットが UITextViewやUITextFieldです これは入手済みですね TextViewやTextFieldが できること以上のことが 必要な場合もあります 高度にカスタマイズされた テキスト描画の実装が必要です この例は本ですが カスタマイズされたテキストビューで 余白や行間などを制御しています

カスタマイズされたテキストビューで このような選択の動作を実現するには システムのテキスト選択ジェスチャを 手動でアプリケーションに追加し ネイティブなテキストウィジェットと 等価にするしかありませんでした 選択のために独自のUIを 実装している人もいるでしょう 青色の選択範囲とか 選択ハンドルなどで こうした動作を実行します

iOS 13ではこれが 新種のUIInteractionで 簡単に実現できます UITextInteractionです UIInteractionは 動作とジェスチャのセットを カプセル化する方法で UIKitのウィジェットに 関連しています ドラッグ＆ドロップの インタラクションに近いものです システムテキスト選択ジェスチャに 追加するのは３行のコードのみです ユーザがすでに知っているものです ジェスチャを編集可能かつ編集不可能な テキストインタラクションに提供します UITextInputプロトコルを使って 選択UIを きめ細かく制御できます 先ほど話した選択範囲や ハンドルなどです

行うことはカスタムテキストビューで UITextInteractionを始めることです 書くべきコードは３行だけです UITextInteractionで インタラクションを作ります ジェスチャのテキストフィールドは 編集可能か編集不可能かを知らせ UITextInputプロトコルを実装する ビューにtextInputを割り当てます コンテナビューや スクロールビューでも動くように分けて テキスト選択の動作を コンテインドビューで制御したい テキストを描写するような場合です 最後にaddInteractionで ビューにインタラクションを追加します

それでは移動します (拍手) テーブルとコレクションにおける 複数選択のジェスチャについて こちら側で話します

UICollectionViewとUITableViewで 複数選択モードをサポートしてきました Notesのようなアプリケーションは 右上に選択ボタンがあり タップして複数選択モードを起動し ノートを１枚ずつ選択して グループ化します ドラッグ＆ドロップか アクションボタンで整理します iOS 13ではコレクションビューと テーブルビューで 連続バッチを素早く選択する 新たな方法を導入します 巨大なiPadで説明しましょう ユーザは直ちに 複数選択モードに入ります テーブルかコレクションのどこかに 指を２本置いて パンすれば選択できます (拍手) すごいですね ファイルのリストビューを ２本の指でスライドすると 直ちに編集モードになって セルを選択します UICollectionViewの フローレイアウトのグリッドにも使え グリッドを２本の指でなぞれば 一度に多くのアイテムを選択できます ドラッグ＆ドロップの夢が 実現しました

ハードウェアキーボードを 接続している場合は Shiftあるいはcommandキーを押しながら 他のアイテムをタップすると macOSと同じように動作します

ありがとう (拍手) iPadアプリケーションは Macでも実行できます テーブルビューが しっくりくるでしょう

これらの新しい動作は オプトインされています ユーザが複数選択モードを 起動することを 念頭に置いてアプリケーションを 順応させるべきなのです 選択や編集ボタンを キャンセルと終了に替えたいとか やるべきことを示す アクションボタンを置きたいとか あるいはノートを追加ボタンのような UIを無効にしたいかもしれません

これらの動作に適用できるよう 新たなAPIを追加します 実装するのは ２つのdelegateメソッドだけ TableViewもCollectionViewも ほぼ同等のバージョンです

これです １つ目はshouldBeginMultipleSelection InteractionAtindexPathです ジェスチャを始めたければ trueを返します IndexPathで 選択不可能なテーブルビューから 選択するのを防ぎたければ falseを返します

２つ目はdidBeginMultipleSelection InteractionAtindexPathです 環境UIを適応させて TableViewが自動的に複数選択モードに なっていたようにします 先ほどのスライドで話しました

新しいジェスチャを使って 一般的な編集タスクに どんな強化を加えたかを 最後に簡単に話します

iOS 13ではジェスチャの 標準セットを導入し 一般的な編集タスクを 簡単にしました ３本の指でスワイプすれば 取り消せます 逆方向のスワイプでやり直しです

３本の指でつまめばコピー 離せばペーストです

この標準セットはシステムに 生産的ジェスチャをもたらすので 一般的な編集コマンドのために UIを実装する必要はありません システム全体で統一されます アプリケーション内で見つけ 直ちになじめるでしょう パネルやツールバーが不要なので 描画アプリケーションには最適です UndoManagerやNSUndoManagerを 使っていれば完全に無料です

機会があれば自分の アプリケーションで試してください スムーズに動けば問題ありません

でも不安に思う人もいるでしょう 他の３本指ジェスチャと 衝突するかもしれません 新しいAPI経由で 逃げ道を提供します UIResponderでオーバーライドする 簡潔なプロパティで editingInteractionConfiguration と言います ジェスチャをオプトアウトしたければ noneを返します これは今日のお土産です システム全域の 標準的テキスト選択ジェスチャを カスタマイズしたウィジェットに 提供します アプリケーションで 情報を整理する方法を変えるために 複数選択ジェスチャを使います これは取り入れてほしいです iPadを振らなくても ジェスチャの標準セットで 取り消しスタックを制御できます (拍手) つらいですよ

次はモハメッドが メニューの話をします (拍手) ありがとう

モハメッドです iOS 13に導入する パワフルなAPIについてお話しします リッチなプレビューを備えた滑らかで インタラクティブなメニューが可能に

最初のAPIが UIContextMenuInteractionです

UIContextMenuInteractionは UIInteractionで リッチなプレビューと複雑な階層を持つ メニューの表示を可能にします 階層には入れ子になったサブメニューと インラインセクションがあります その意味は後で説明します

センターアクションが示すメニューは 高度に順応しています コンテキストに応じて 正しいことをするのです iPhoneのポートレートです プレビューとアクションが 垂直に重なっています

横向きにするとプレビューと アクションが並び スペースを有効に活用します

iPadの場合はスペースとか プレビューやアクションリストの サイズに合わせて変わります

クロスプラットフォームAPIなので Macでアプリケーションを実行するなら macOSのコンテキストメニューに なります

インタラクションは 一貫したエクスペリエンスを提供します iOS全体で同じジェスチャを使い メニューを表示します ユーザはシステムのどこでも メニューが表示されることを期待します

ジェスチャは デバイスの能力に適応します 3D Touchを作動するiPhoneでは 3D Touchがメニューを素早く表示し フィードバックを提供します

3D Touchを使わないiPhoneでは Haptic Touchを使い メニューが表示されるたびに フィードバックを返します

他のiOSデバイスでは 長押しを使い Macでは右クリックを 使うことになります commandを押しながらクリックか ２本の指でタップかも

インタラクションは システム挙動に自動的に統合されます ドラッグ＆ドロップなどです UIDragInteractionを アプリケーションに入れるなら UIContextMenuInteractionも 取り入れれば どの時点でもドラッグに移れます ドラッグの 最初のしきい値に達すると 指を動かして写真を ファイルアプリケーションへドラッグ

メニューが表示されるまで待っても スムーズにドラッグに移行できます 指で画面に触れたまま― 滑らかで連続する エクスペリエンスを得られます

次のAPIパッケージは UIMenuとUIActionです

UIMenuとUIActionは 階層的なメニュー構築システムで 表示したいメニュー階層を 定義し 説明します

UIMenuは構成可能です ブロックを組み立てるように 異なる設定を組み合わせて 異なるメニュー階層を説明します

簡単な例として ２つのアクションメニューを作りました UIMenuを作成し それをUIActionの子に送ります アクションを共有し 削除します

サブメニューを加えるなどして 機能性を追加したいなら 別のUIMenuを作ります 階層の前のレベルで 表示する記述的なタイトルを与え 希望する子に送ります ここではコピーを含め アクションを複製しました

表示するメニューは こんな感じです 一番上に共有アクション 真ん中にサブメニューの 編集アクション 一番下が削除アクションです

編集をタップすれば サブメニューが表示され コピーと複製のアクションが現れます

アプリケーションに インタラクションを入れるのは簡単です UIDragInteractionや UITextInteractionなどのような 他のUIInteractionを 導入した経験があれば このパターンに 見覚えがあるでしょう まずオブジェクトをdelegateにして UIContextMenuInteractionを作ります 例えばViewControllerです UIViewのaddInteractionメソッドを 使ってViewに付けます

それが終わったらinteractionの delegateプロトコルに適合させます プロトコルは１つの必須メソッドで インタラクションが始まる時に 呼び出されます この時点でconfigurationを返して インタラクションを開始するか nilを返して現在の場所に 表示するメニューがないことを示します

configurationオブジェクトが メニューを記述します 識別子を持っています 識別子はオプションです 使用すれば インタラクションを識別できます 複数のdelegateのコールバックを 経てもです

previewProviderと actionProviderのクロージャもあります メニューが表示される時に 両方が呼び出されます これで潜在的にコストのかかる メニューとプレビュー作成を 必要な時まで延期できます

今 見た例によるとメニューは リッチなプレビューを持たず アクションだけです だから delegateメソッドの実装で actionProviderの作成に集中できます

呼び出されたactionProviderは システムから送られた アクションの提案リストを有しています

UIMenuとUIActionの 混合かもしれません システムから引き抜かれた 高度に構築された階層です これはResponder Chainで 定義できます iOS 13で新たに導入された UICommand APIを使えば可能です あるいは他のシステムコンポーネントが 提供するものを

カスタムメニューを作るので アクションの提案は無視します

まずeditMenuを作ります UIMenuを作って タイトルをEditにし ２つの子に送るだけです タイトルがCopyのUIActionと タイトルがDuplicateのUIActionです

続いてルートメニューを定義します ルートメニューにタイトルはないので スキップします タイトルに送るとアクションリストの ヘッダーに表示されます

送り先の子はShareアクションと editMenu スタイルがdestructiveの Deleteアクションです これはアクションが破壊的な 結果をもたらすことを示します

最後に識別子付きの configurationを作成し actionProviderに送ります

これだけで UIContextMenuInteractionを使い メニューを作って表示できます

作業はもう少しあります アニメーション カスタマイゼーションAPIを利用します インタラクションdelegateの提供で 高度に洗練された アニメーションを作れます ユーザにとって有意義でしょう

先ほどと同じメニューです ソース表示の カスタマイゼーションAPIを使い セルのアイコンから メニューが現れるようにしました セル全体からではありません 背景の色をカスタマイズし プレビューに丸い形を与えました

これらのカスタマイゼーションAPIは UITargetedPreviewで作りました iOS 13で導入される新たなAPIです UIDragInteractionと UIDropInteractionを導入し カスタムのドラッグあるいは ドロッププレビューを作ったなら 見覚えがあるでしょう UITargetedDragPreviewを 一般化して 他のインタラクションでも使える 一般的なAPIにしました

UITargetedDragPreviewは UITargetedPreviewのサブクラスです すでに有意義な ドラッグプレビューがあり 同じアイテムから発生していて メニューにとって適切なら 他のことをしないで 同じコードを再利用できます

アプリケーションに適用すると メニューを作るのが より簡単になります UICollectionViewとUITableViewに コンビニエンスAPIを導入します アプリケーションから メニューを作る あらゆるプラットフォームの Table Viewからメニューを作るために 必要なのはdelegateにメソッドを １つ実装することだけです 表示するメニューがあるなら configurationを返し 表示するものがないなら nilを返します

このコンビニエンスAPIは 洗練されたアニメーションを提供し メニューはTableあるいは Collection Viewから表示され 消えると元に戻ります 同じカスタム表示と 消滅のフックも提供するので 出たり消えたりする カスタムのアニメーションを作れます

PeekとPopのようだと 思われるでしょう それは承知しています

このAPIは より大きな機能セットを提供し 複数のプラットフォームで 使えます UIViewControllerのプレビューは iOS 13で廃止します PeekとPopを UIContextMenuInteractionに替えて あらゆるデバイスで一貫した エクスペリエンスを提供しましょう

長押しのメニューも 新しいインタラクションに替えて 新たな機能セットの利点を 十分に活用しましょう

ドラッグ＆ドロップで 表示しているメニューがあるなら これは最高の解決策です 協調的なジェスチャと 統合されたエクスペリエンスは iOS 13のユーザが 期待するものです

新たな知識を手に入れましたね iOS 13に備えて アプリケーションを改良してください 未来に向けて 柔軟性を与えましょう 新しいバーの外観や 表示のAPIを活用して ユーザが期待するモダンな アプリケーションにしてください 新たな検索APIを使って 求めていたエクスペリエンスを提供し 新たな生産的ジェスチャと コンテキストメニューで 機能を追加します

このセッションのテーマや UIKitに関する質問があれば 明日 ラボに来てください 追加の情報はセッションの Webサイトで提供します ありがとうございました (拍手)