基本は単純です<UISearchBarDelegate,UISearchDisplayDelegate>。テーブル ビュー コントローラーに実装するだけです。ここに適切なチュートリアルがあります。
秘訣は、テーブル ビュー コントローラーと検索表示コントローラーの 2 つのコントローラーがあることを認識することです。各コントローラには、独自のテーブル ビューがあります。したがって、通常のテーブル ビューと検索表示テーブル ビューの 2 つのテーブル ビューが使用されます。デリゲート メソッドに UITableView 引数がある場合、どのテーブル ビューが渡されたかを比較し、それに応じてさまざまなことを行います。
上記の基本を超えて、データ構造が私にとっての主な課題になります。より具体的には、検索結果をフィルタリングして保存する方法は? 次の 3 つのオプションがあります。
A.
通常のテーブル ビュー用の 1 つの FRC
結果を格納するための配列プロパティを作成する
filteredArrayWithPredicateフェッチされたオブジェクト (配列) をフィルタリングするために使用しますFRC のキャッシュを指定して、フェッチされたオブジェクトをメモリに格納し、パフォーマンスを向上させます
B.
通常のテーブル ビュー用の 1 つの FRC
FRC の述語を変更して、フィルターを実行します。Apple doc は、それを行うための 3 つの手順を指示しています。
- FRC キャッシュを削除します (そもそも使用しない方がよい)。
- 述語の変更
- performFetch を呼び出す
C.
各テーブル ビューに 1 つずつ、2 つの FRC。詳細な実装は、この人気のある投稿の受け入れられた回答で提供されています
Aが正しい道だと思います。私の理論的根拠は次のとおりです。
Aはすべての仕事をうまくやっています。また、FRC プロパティを使用してテーブル ビュー コントローラーにわずかな変更を加えるだけで済みます。より具体的には、すべてのデリゲート メソッドで 2 つのテーブル ビューを比較し、NSArray プロパティを追加してフェッチ結果を保存します。そしてもちろん、フィルタリング コードを追加します。
B には潜在的な欠点があります: FRC デリゲート メソッドは、どのフェッチ要求が使用されているかについて混乱しますか? 検索前ですか、検索中ですか、検索後ですか。そこに解決策があるかもしれませんが、解決策Aが機能している限り、時間の価値があるとは思いません.
2 つ目の欠点は、検索結果をその場で変更したい場合です。ユーザーが検索バーに文字を 1 文字入力するたびに、FRC が Fetch を実行しますが、これはかなりコストがかかります。
C は 2 つの FRC を使用することで B の最初の欠点を回避しますが、まったく同じ理由で 2 番目の欠点に悩まされます。
その他の考慮事項:
バックグラウンド キューでフィルタリングを行います。そのため、ユーザーが検索バーに入力すると、フィルタリングがどれほど高価であっても画面がブロックされません。
2 つのテーブル ビューを比較するためのヘルパー メソッドを作成します。関連するデリゲート メソッドでヘルパー メソッドを呼び出すと、コードがよりクリーンになります。
上記は、テーブルビューでの検索の実装に関する私の理解です。間違いがありましたら、ご指摘いただけると助かります。どうもありがとう。