TextKitのベストプラクティス

(音楽)

(拍手) こんにちは TextKitの ベストプラクティスをご紹介します TextKitエンジニアの ドナです オーサリングツールから エミリーも参加します TextKitの効率的な 使い方を共有しましょう では 始めます

まず TextKitの主な概念 次に アプリケーションに それを適用する方法 最後に 正確性 性能 セキュリティ面についてです

では 主な概念から

基本的なことから 始めましょう TextKitとは？

Xcodeを開き― “import TextKit”と 入力すれば使える？ 実は これでは作動しません

TextKitは他のフレームワークと 異なるためです 何かをインポートする 必要はありません テキストコントロールは TextKit上に構築されており ラベルやテキストフィールドや テキストビューにも使われています Core TextやCore Graphicsや Foundationで 簡単かつシームレスに テキスト表示できます ビルトインのコントロールでは TextKitが使用されています ローカライズ可能な方法で 表示 編集できるので 複雑な技術やスクリプトを 理解する必要はありません 無料で使える 多くの機能があります

編集ではOSが対応する 全技術サービスにアクセス可能 例えばアクセシビリティや スペルチェックなどでは コードを書かずに 優れた機能を利用できます すばらしいですね どの機能をどのように 使ったらよいか？

適切な選択について 解説します UIKitとAppKitのどちらを 使っているかで異なるため 見てみましょう

まずはUIKitから

テキスト入力が必要か 検討します

不要な場合は 選択やスクロールが必要か

それも不要なら UILabelを使用します UILabelは少量のテキストを 対象としています

テキストが多かったり 選択やスクロールが必要なら 編集を無効にして UITextViewを使用

テキスト入力が必要なら 安全な入力方法は？ パスワードのように隠したり コピー不可とするかです

そういったものが必要なら UITextFieldを使用します

不要なら 入力テキスト量の考慮を １行の入力のみ必要な場合は １行の入力だけをサポートする UITextFieldを使用

それ以上必要なら UITextViewです

AppKitの決定プロセスは 似ていますが少し違います

まず テキスト入力が 必要かを検討します

ラベルコントロールが ないので テキスト表示するには NSTextFieldで編集と選択を 無効化して ラベルの動作を実現

次に安全なテキスト入力の 必要性を検討します 必要なら NSSecureTextFieldを使用

不要なら テキストの量は？

NSTextViewは大量の テキストに適しているので 量が多いならNSTextView

少ないならNSTextFieldです UIKitの場合と異なり 複数行も扱えますが 短い文字列用なので 量が多いなら NSTextViewを使うべきです

TextKitに 慣れている皆さんは フローチャートに文字列描画が ないことに気づくでしょう 文字列描画を使用するには NSStringまたは NSAttributedStringの 描画メソッドを 直接呼び出します キットレベルでの ビューオブジェクトの オーバーヘッドが 避けられます

文字列描画を 使用する際のヒントを 少量の静的テキストに 使用します 描画メソッドを呼び出す 頻度を制限します 何度も呼び出す場合 キャッシュ効率が上がり 特に自動レイアウトでは ラベルやテキストフィールドの 性能が向上 カスタム属性付き 文字列を描画する場合 レンダリング前に 属性を検証するため 文字列描画が遅くなることも 最高の性能を得るには 余分な属性を取り除きます フォントや色など 外観の決定に 必要なものだけを渡します

最後に 文字列描画では テキストコントロールの 機能は使えません 可能な時だけ 使用してください

ビルトインのコントロールを使い TextKitで何ができるか学びました 機能以上のことをする場合 テキストスタック内で適切な カスタマイズポイントを見つけます TextKitは モデル/ビュー/コントローラの 設計パターンがベースです

NBCに直接対応する ３フェーズに分けられます ストレージ 表示 レイアウトです 各フェーズの TextKitオブジェクトを 見ていきましょう まずは モデルに対応する ストレージです

NSTextStorageは 文字列データと属性を保持 可変属性付き文字列の サブクラスなので 属性付き文字列と同様に 作業できます あとでテキストストレージの カスタマイズ法を紹介します

NSTextContainerはテキストの 配置領域の形状をモデル化 デフォルトでは長方形ですが フローや形は変えられます

ストレージオブジェクトの 操作の詳細は 過去のセッションと 資料を参照してください 詳細情報のリンクから 利用できます

次は ビューに対応する 表示フェーズ これについては 先ほど詳しく話しました その他の情報は 資料で確認してください 詳細情報のリンクから アクセスできます

最後は コントローラに対応する レイアウトフェーズです

NSLayoutManagerは このフェーズ唯一のコンポーネント そして とても すばらしいんです 全操作の中枢部として 全フェーズ間の変更を調整し レイアウトプロセスを制御

レイアウトプロセスの 仕組みを紹介します まず 不整合を除去するため テキストストレージ内の属性を修正 文字列内のすべての文字が フォントにあるか確認します この例では Times New Romanフォントが 全体に指定されています でも このフォントは漢字や 絵文字をサポートしません 属性を修正すると テキストストレージは このようになります 適切な日本語･絵文字フォントが 割り当てられます

属性が修正されると レイアウトプロセスが開始 グリフの生成後に グリフのレイアウトが行われます

配置されると 表示の準備が整います

ところでグリフとは？ １つ以上の文字を視覚的に 表現したものです 文字とグリフ間のマッピングは 必ずしも１対１ではありません

この“ffi”は ３つの文字から成りますが 合字として単一のグリフで 表すことができます 逆のパターンもあります 複数のグリフで表現できる 単一の文字“ñ”があります １つはn用 もう１つはチルダ用です

図に戻ります NSLayoutManagerがグリフの 生成とレイアウトを行います まずは文字から グリフを描画するかどうかを判断 そしてグリフを配置し 表示します

過去のセッションや 資料でも学べます こちらも詳細情報のリンクから アクセス可能です

テキストシステムの各段階と TextKitコンポーネントについて 理解できました

では 正しい設定を選択し さまざまな効果を作りましょう

標準的な設定では― テキストビューを ドラッグ＆ドロップすると 各コンポーネントを自動取得 大抵の場合 必要なのはこれだけ

複数ページや複数列が必要なら テキストコンテナと テキストビューを ページか列ごとに１組使用 同じテキストストレージ内の 同じレイアウトマネージャに接続し バッキングストアの レイアウト情報を共有します

異なるレイアウトが必要な場合 複数のレイアウトマネージャを使用 バッキングストアを 共有しているため テキスト更新で すべてのビューが更新

設定については2010年の セッションをご覧ください “Advanced Cocoa Text Tips and Tricks”です 詳細情報のリンクから アクセスできます

ビルトインの テキストコントロールと TextKitのコンポーネント そして その設定方法 これらの知識で 多くのことができますが 更にTextKitの カスタマイズも可能 その正しいアプローチの 選び方は

テキストツールボックスの 構築と同様です 例えばハンマーを買う時は 壁一面に並んだ商品から できるだけ安くて 使用目的に適した物を選びますね

さまざまな ハンマーがあります デリゲーションは ネイルハンマーのように 複数の作業をこなします カスタマイズも可能で とても便利です

通知は 丸頭ハンマーのようなものです 特定のタスクに適しており 決して用途は広くありません

サブクラス化は 大型ハンマーです 大型ハンマーは非常に強力で 何にでも使えますが 大抵の場合 大きすぎます

ハンマーの使い方は エミリーが説明します エミリー (拍手) ありがとう ドナ 開発者には多くの コントロールの選択肢があります さまざまな設定と 幅広いカスタマイズオプション ツールはいっぱいですが どのツールを選べばよいか？

TextKitの機能を活用する アプリケーションの例を見ましょう ほとんどのアプリケーションが テキストの表示 編集をします

２つのアプリケーションを見たあと 独自に構築してみましょう

最初のアプリケーションは iOS上のApple News パーソナライズされた記事の テキストを表示します

Spotlightのタブに 表示される記事の例です

上部に記事の詳細が 表示されます この見た目と操作感を TextKitでどう作るか？

ドナが示した フローチャートで 最適なコントロールを 選んでみましょう

使えるテキストコントロールは たくさんあります 表示するのは１行のみで テキストは少量なので ラベルを使用します

インスペクタパネルに 多くのオプションがあります

テキストをSpotlightに変え フォントをBodyに変更します

Dynamic Typeを有効にし アクセシビリティを設定すれば 好みのサイズと スタイルで表示できます

Interface Builderで ラベルをカスタマイズでき Swiftで プロパティを見られるので テキストと書式のプロパティを 動的に設定できます

Interface Builderに戻り ラベルを２つ追加します すべて順調ですが もう１つ必要なのです

Apple Newsの右のテキストは 黒と白の２色で 表示されています ２つのラベルで可能ですが １つしか 使用したくない場合は Interface Builderでは できません どうすればよいでしょう

属性付き文字列の機能と 柔軟性を利用します

属性付き文字列は文字の特定の 範囲に属性を適用できます デフォルトのフォントや テキストの色などの属性は 指定した値で上書きできます 今回は文字列の色を 部分的に白にします

表示するためには NSMutableAttributedStringの addAttributeメソッドを使用し 望む範囲だけテキストの色を 白に設定します ラベルのattributedText プロパティを設定します

非常に整理された見た目です

この種のテキストには UILabelが最適です 画面下部にある 見出しのテキストは 少し大きめで複数の行に またがっています

しかも他と違って選択可能です

どのコントロールを 使うべきでしょうか？ テキストフィールドも テキストビューもいいですが テキストフィールドは 通常は１行用です

見出しは複数行なので テキストビューを使用します

デフォルトで ダミーテキストが入ります インスペクタパネルの テキストを変更します

Apple Newsらしい フォントを選び

見出しを編集できないよう 編集機能を無効にします

UITextViewはデフォルトで スクロールが可能ですが

自動レイアウトを活用するなら スクロールを無効にします テキストビューのサイズが テキストに合わせて変更されます

この白い背景は不要なので 透明に設定します テキストビューを簡単に カスタマイズでき ラベルと同様 すべてコード内で設定できます Swiftでは実行時に動的に テキストと書式を設定できます 次はApple Newsではなく 別のアプリケーションを例に 見てみましょう

テキストエディットです macOS上のアプリケーションで リッチテキストの 表示と編集が可能です

実はNSTextViewの シンラッパーです TextKitで何ができるか 見ていきましょう このインスペクタバーも その下のルーラービューも Interface Builderの チェックボックスを選択するだけ その下はテキストビュー

そしてテキストコンテナと レイアウトマネージャと テキストストレージです NSTextViewと UITextViewの標準的な設定です

似ているのは ここまで

テーブルはNSTextViewでのみ サポートされています すばらしいことに― TextKitはテーブルエディタを 提供します

大量のテキストを 編集する時に便利な― スペルチェッカーも 無料で使えます そして更に― フォーマット機能を使用して ページのように表示できます テキストコンテナのサイズが 用紙に合わせて変更されます

このようにテキストが 次のページへジャンプ 標準的な設定では不可能です ２つのテキストビューと テキストコンテナを使いました 同じレイアウトマネージャと テキストストレージで管理されます

テキストエディットの 仕組みをもっと知りたいなら ライブラリにソースがあります

適切なコントロールと 設定を選びましたが 求めるものを得るには ハンマーが必要です 使うべきハンマーは？

ジャーナルアプリケーションを 構築しながら ハンマーを選んでみます

まず今日の日付を 表示しましょう テキストフィールドを ラベルのように動作させるには

編集を無効にするだけです

ジャーナル入力部には テキストビューを使用します インスペクタでは テキストビューが選択･編集でき リッチテキストとUndoが サポートされていることを確認

テキストフィールドを２つ追加し 単語数を表示します

アプリケーション実行時に 単語数が変更されるように 正しいハンマーを 見つけましょう デリゲートに準拠させるか 通知またはサブクラスを処理します 今回はテキストストレージからの 通知を受けます

テキストストレージから 単語の数を取得できます 通知を受け stringValueプロパティを 更新します

入力を開始すると 単語数が変化します

テキストの一部を 強調する場合― ショートカットやメニューで 太字などの書式を適用

最新のテキストフォーマットも 使いたいですよね Markdownのように 制御文字で書式を指定したい 前後にアスタリスクを挿入したら 太字にするには どのハンマーを使うべきか？

変更がいつどこで生じたかを 知る必要がありますが 通知される情報では 不十分です

大きなハンマーを使用し NSTextStorageDelegateを 実装します 具体的には didProcessEditingメソッドです 既存のものから 太字のフォントを新たに作り テキストストレージに それを直接追加します

最後のアスタリスクで 太字になりました

それではコードスニペットを 挿入するとどうなるか？ Markdownでは こうです 最後のバッククォートを追加したら コードブロックのように 背景とヘッダを付けたい これは複雑で ２つの大型ハンマーが必要です まずは サブクラスNSTextStorage NSTextStorageの サブクラス化には ４つのメソッドが必要です 可変文字列の プライベートインスタンスを 操作しましょう

replaceCharactersメソッドで 段落スタイルに NSTextBlockを追加できます

そして段落スタイルを コードブロックの範囲で テキストストレージに追加 NSTextBlock自体は カスタム描画を行わないので サブクラスにする必要があります

NSTextBlockサブクラスでは いくつかのパディングが必要です 明るい灰色の背景も

drawBackgroundをオーバーライドし ヘッダを描画すれば テキストブロックが コードスニペットのように見えます

カスタムテキストストレージに戻り 新しいコードブロックの インスタンスを作成します

最後に― カスタムテキストストレージが 使用されるよう レイアウトマネージャの テキストストレージを置換

WYSIWYGなエディタに なりましたね Markdownエディタは 左右に並べて表示できます 左は編集版 右はレンダリング版です

２つのテキストビューを 左右に並べ

右側の編集を無効に 同じ内容でも 右側は 少し違う外観にしたいので

テキストストレージは１つで それ以外は２つ持たせます

右のテキストストレージを 左のものに置き換えます

結果を見ましょう

左側に文字を追加すると 右側にもすぐに表示されます 通常は右側にMarkdown文字は 表示されません しかしテキストストレージを 共有しているので レイアウトプロセス中に 文字を隠す必要があります

これには１つの方法しか ありません shouldGenerateGlyphsメソッドを NSLayoutManagerデリゲートに実装 これでグリフ生成プロセスに 介入できます

配置対象のグリフを取得し Markdown制御文字を 表す場合― グリフにnullプロパティを 適用します これでレイアウト処理中に グリフが完全に消滅

新しいグリフを新しいプロパティで 表示するよう指示します

左側はMarkdown文字を含む 編集可能なバージョン 右側にMarkdown文字は ありません どちらも 同じテキストストレージです

左右に並べるエディタの構築は 一般的ではありませんが TextKitの カスタマイズ例として 紹介しました

TextKitの使用法とカスタマイズは プログラミングガイドでご確認を では ドナに戻します (拍手) エミリー ありがとう とてもいい例でしたね 皆さんのアプリケーションでも ぜひ お試しください 次はベストプラクティスについて お話ししましょう

まず正確性について 思うように レンダリングされない場合は 属性付き文字列の属性が 不完全または不正です

例を見てみましょう ある属性の付いた― “Don't hate.”という テキストがあります フォントはComic Sans 24ポイント

プログラムで“Don't”に 太字の書体を適用したい Comic Sansの太字は かなり不評ですからね (笑い声) 最初に こんなコードを 思いつくかもしれません 元のフォントがあります

フォント記述子を使用して その太字版を作成し

元のテキストを使用して 可変属性付き文字列を初期化 新しい太字フォントを “Don't”に適用します 最初の５文字ですね この新しい文字列を使用するよう 属性付き文字列のプロパティに設定

新しい太字のフォントが “Don't”に適用されましたが 残りの文字は フォントが変わりました

Comic Sans嫌いは喜ぶでしょうが 結果は間違っているので残念です なぜこうなったのでしょう

属性付き文字列の初期化を 詳しく見ていきましょう

プレーンテキスト文字列を使用し 属性情報なしで初期化しました

新しい文字列を作成した際も 属性情報を指定せず デフォルトの属性を 使いました フォントはHelvetica 12ポイント

元の属性付き文字列から 見ていきましょう Comic Sansの24ポイントを 全範囲に適用し

新規属性付き文字列を作成し デフォルトの属性で初期化 そして “Don't”に太字を適用 Comic Sansの太字 24ポイントになりましたが 残りはHelveticaの 12ポイントに

これを直すには ２つの方法があります １つはプレーンテキストと 属性付きテキストを混在させない 元の文字列を使用して初期化し 属性を保持すれば リセット効果なしに 新しい属性を適用できます

テキストの混同を 避けられない場合は 明示的に属性を指定して プレーンテキスト文字列から 属性付き文字列を作りましょう 元のテキストの属性を適用すれば 正しい結果が出ます

リセット効果はデフォルト値を持つ 他の属性にも及びます デフォルト値を持つ 属性はたくさんあります

特に段落スタイルには 注意が必要です 先ほどの例で フォントを変更する代わりに 段落スタイルを変更し “hate”を切り詰めます

しかし このコードを 実行すると すべてHelveticaの 12ポイントに デフォルトの段落スタイルで ラッピングの改行モードが使われ Comic Sansフォントは 完全に失われました 前回とは違う結果です

なぜか？ レイアウト前に 属性の修正が行われ システムは 一貫性のない属性を修復 属性付き文字列に― 複数の段落スタイルを持つ １つの段落があります システムが この属性を修正する際― 最初に見つけた段落スタイルを 全体に適用 その結果 デフォルトの スタイルで表示されます

このような場合 重要なのは 属性を明示することです それでデフォルト属性での リセット効果を避けられます ダークモード用に アプリケーションを更新する際 非常に重要です NSColor.textColorのような 動的な色を明示することで コンテキストに適した色で テキストを描画できます

次のトピックは性能です 大量のテキストを扱う場合 非連続レイアウトが有効です

レイアウトプロセスを もう一度見ましょう グリフの生成とレイアウトで 構成されています 連続レイアウトでは テキストストレージの先頭から グリフの生成とレイアウトを実行 最後まで順番に処理されます テキストビューの途中まで スクロールすると レイアウトマネージャが 手前のグリフを すべて生成 レイアウト 赤く示されている部分です スクロールされて 見えないテキストも含む― テキストストレージの 先頭からです テキストが多いと レイアウト完了まで しばらく待たされます 非連続レイアウトなら この状況を回避できます 非連続レイアウトでは テキストストレージの先頭からの グリフ生成とレイアウトは 行いません テキストビューの途中に スクロールすると その中間セクションの グリフ生成とレイアウトを行います

非連続レイアウトを使用すると パフォーマンスが大幅に向上します

どうすれば使えるか？ 非連続レイアウトは NSLayoutManagerのプロパティです テキストにアクセスして そのプロパティを設定します

UITextViewの場合 デフォルトでオンになっています 大切なことが１つ UITextViewはUIScrollViewの サブクラスなので 非連続レイアウトでは スクロールを 有効にする必要があります スクロールを無効にすると すべてのテキストの配置が 必要となり 非連続レイアウトの 利点が得られません

ここで重要なポイントです 一度に大量のテキストの レイアウトを要求しないこと 非連続レイアウトを使う 意味がないからです テキストコンテナが１つなら 全体のレイアウトを要求しません 終わりを含む広範囲の 文字やグリフについてもです

テキスト処理の性能について 詳しくはWWDC2017の “Efficient Interactions with Frameworks”をご覧ください 詳細情報のリンクから ビデオにアクセスできます

次は誰もが好きな セキュリティの話題です

最近の事件をご存じでしょう ソフトウェアのバグを悪用し 問題を起こす人々がいます

こうした攻撃を防ぐ策を 私たちは練っています

強力な防御のために 何をしているか話しましょう 多層防御をご存じでしょうか

念のために説明すると 複数の保護対策を 組み合わせることです この概念は何世紀にも わたって存在しています 中世の城の周りは 視界確保のため木がなく 敵を近づけないよう 堀に囲まれていました 更に壁は高いため登りづらく 攻撃者に発砲できるよう 上部に穴が設けられていました いずれか１つでは 防衛には不十分ですが 組み合わせれば 力を発揮します

私たちも城と同様 複数の防御層を提供し 皆さんも独自の防御策を 実装できます これにより更に安全性が向上し 誰もが勝者に その方法をお話ししましょう

アプリケーションや フレームワークで テキスト入力を制限する これは常に 使えるとは限りません 例えばアプリケーションが オーサリングツールである場合 テキストの長さを制限しても 意味がありません

でもアカウントにニックネームを 設定するテキストフィールドなら 制限を付けられるでしょう

テキスト入力は信頼できないので 制限の設定を推奨します テキスト入力を許可すると コピー＆ペーストも許可されます 何でも入力可能です 悪意のある 文字列の場合もあるし とんでもなく長い 文字列ということも

長い文字列は たとえ悪意がなくても フリーズやハングアップの 原因に １行用のテキストフィールドに “戦争と平和”の 全文をペーストすると 英語では 約310万文字になります

妥当ですか？

おそらく違います

こうした場合は 制限が理にかなっています

この種の制限を設定する際は 入力文字列を 事前に検証すること UITextFieldでは UITextFieldDelegateを使用し NSTextFieldでは カスタムNSFormatterを使用

新たな安全性強化策も 準備中です 質問があれば今週 ラボにお立ち寄りください

もう時間なので まとめましょう コントロールと カスタマイズポイントと カスタマイズ方法の選び方 正確性 性能 セキュリティの ベストプラクティスを学びました この知識を活用しTextKitで よいものを作ってください 重要な情報リンクがあります 過去のセッションや 資料をご覧いただけます 木曜日と金曜日に ラボを訪ねてください

ありがとうございました (拍手)