Rambler。Mailの例でのCoreSpotlightの統合

iOS 9で、Appleはサードパーティアプリのスポットライト検索を追加しました。 これは、同じ種類のコンテンツ（ニュースアプリケーション、電子メールクライアント、イベントポスター）を持つアプリケーションにとって特に重要です。 Rambler＆CoのiOS開発部門は、すでに一部のアプリケーションに検索機能を統合しています。

この記事では、 CoreSpotlightの既存プロジェクトへの統合について説明し、発生した問題とその解決策について説明します。

Search API

まず、現在の機能とそのアプリケーションの場所の全体像を示すために、サードパーティアプリケーションでコンテンツを検索するための機能がiOS 9で現在利用可能であることを明確にする価値があります。
現在、Search APIは次のコンポーネントで構成されています。

NSUserActivity- 表示されたコンテンツとユーザーアクティビティを保存および復元するクラス。 このクラスは、 ハンドオフ （別のデバイス上の同じアプリケーションで作業を継続する機能）を実装するためにiOS 8で導入されました。 iOS 9では、このクラスは検索結果からアプリケーションを開くときにも使用されます。 以下を含むモデルです。

• インターフェイスの状態を復元するための情報。
  
• この情報とやり取りする方法の説明。
  
• この情報をシステムに保存する方法。
  

このアクティビティを公開することができます。つまり、このアクティビティはこのデバイスの検索結果だけでなく、他のユーザーにも表示されます。 この機能が機能するのは数か月以内に開始されることに注意してください。

CoreSpotlightは、開発者がアプリケーションコンテンツにインデックスを付けて、 後でSpotlight検索結果に表示できるようにするフレームワークです。 次の2つのモデルがあります。

1. 検索に表示する属性。
   
2. コンテンツを識別するためのプロパティ。
   

CoreSpotlightには、検索からオブジェクトを追加および削除するためのメソッドも含まれています。

Webマークアップは、Appleボットがサイトコンテンツ （特別なメタタグ）のインデックスを作成して、アプリケーションでの検索とオープンの結果として表示できるようにする技術です。

WebマークアップとNSUserActivityの詳細については、WWDC 2015、ドキュメント、および記事の最後にあるリンクを参照してください。

問題の声明

例として、 Rambler.Mailアプリケーションを使用したCoreSpotlight統合を見ていきます。 アプリケーションは、データベース（CoreData）に保存されているフォルダー、レター、添付ファイル、連絡先の検索を追加します。 更新時までに、このデータベースはすでにいっぱいになっています。 これに基づいて、最初の要件は、 保存されているすべてのデータのプライマリインデックスです 。

これらのオブジェクトはすべて作成、削除、および変更できるため、メインデータベースとインデックス付きオブジェクトの整合性を維持する必要があります 。 多くのデータ変更操作があり、それらが互いにオーバーラップする可能性があるため、システムは変更セットを処理するように実装する必要があります。

上記の要件に基づいて、 インデックス作成のための操作の数を「縮小」する必要があります。 同じオブジェクトに複数の変更を加えた場合、1回の更新操作のみを処理すれば十分です。 オブジェクトを削除する場合、そのオブジェクトにすでに存在する変更のインデックス付けの要求を処理することは意味がありません。

将来的には、他のプロジェクトへの統合が計画されているため、インデックス付けシステムは可能な限り独立し、あらゆる種類のオブジェクトにインデックスを付けることができ 、 簡単に統合、変更、拡張する必要があります。

インデックス作成には時間がかかり（特にプライマリ）、中断される可能性があるため、その状態を保存する必要があります。 つまり、 未処理の変更をすべて保存し 、アプリケーションの再起動時にインデックス作成を開始する必要があります。 同時に、 データベースへの呼び出しの数を最小限に抑えるようにシステムを実装する必要があり、変更を保存するための補助オブジェクトの数は、変更されたオブジェクトの数よりも少なかった。

構造

タスクを設定した後、システムをいくつかのモジュールに分割し、各モジュールが機能タスクの1つを担当します。 同時に、インデックス付きオブジェクトを操作するモジュールはプロトコルによって閉じられるため、必要に応じてモジュールの独自の実装を記述でき、システムは引き続き動作します。

データソースは<ChangeProvider>です。 このプロトコルを実装するクラスは、オブジェクトへの変更に関する情報をモニターに提供します。 インデックスを作成する必要がある各エンティティには、独自のプロバイダーが必要です。 便宜上、NSFetchedResultsControllerによって初期化され、デリゲートとしてそれ自体を公開し、IndexerMonitorの変更に関するすべてのイベントをプロキシする基本クラスが実装されます（これについては後で説明します）。

@protocol RamblerChangeProvider <NSObject> @property (weak, nonatomic) id<RamblerChangeProviderDelegate> delegate; @end 

 @protocol RamblerChangeProviderDelegate <NSObject> - (void)changeProvider:(id<RamblerChangeProvider>)changeProvider didChangeObject:(id)object changeType:(RamblerChangeType)changeType; - (void)processChanges; - (NSArray *)obtainObjectsForInitialIndexing; @end 

 @interface RamblerFetchedResultsControllerChangeProvider : NSObject <RamblerChangeProvider> + (instancetype)changeProviderWithFetchedResultsController:(NSFetchedResultsController *)controller; @end 

インデクサーは<Indexer>です。 データベースからのデータのインデックス作成に関与しているオブジェクトのプロトコル。 インデックスを作成する必要があるエンティティごとに、独自のインデクサーオブジェクトが追加されます。 彼は、一連の変更を処理し、自分に渡されたオブジェクトとオブジェクトを識別子で一意に識別する方法を知っています。 便宜上、基本クラスも実装されており、そこから継承する必要があります。 インデクサーはバッチ処理操作を作成し、モニターに返します。

 @protocol RamblerIndexer <NSObject> - (NSOperation *)operationForIndexBatch:(RamblerIndexTransactionBatch *)batch withCompletionBlock:(RamblerErrorBlock)block; - (BOOL)canIndexObjectWithIdentifier:(NSString *)identifier; - (NSString *)identifierForObject:(id)object; - (id)objectForIdentifier:(NSString *)object; @end 

 @interface RamblerIndexerBase : NSObject <RamblerIndexer> @property (strong, nonatomic) CSSearchableIndex *searchableIndex; - (CSSearchableItem *)searchableItemForObject:(id)object; - (BOOL)canIndexObjectWithType:(NSString *)objectType; @end 

動作するには、RamblerIndexerBaseの2つのメソッドとRamblerIndexerプロトコルの最後の3つのメソッドをオーバーライドする必要があります。

識別子ジェネレーター -IndexIdentifierFormatter-ソースオブジェクトを検索するために、 識別子を生成して「重要な部分」（回復に必要な文字列の部分）に分割するための補助オブジェクト。 たとえば、レターの識別子は「 RCMMessage_129_Inbox 」のようになります。 「RCMMessage」 -オブジェクトタイプ、「 129 」-フォルダー内のレターの識別子、「Inbox」-メッセージが配置されているフォルダーの名前。 この情報に基づいて、オブジェクトのタイプを一意に決定して見つけることができます。

 @protocol RamblerIndexIdentifierFormatter <NSObject> - (NSString *)identifierForObject:(id)object; - (BOOL)isCorrectIdentifier:(NSString *)identifier; @end 

 @interface RamblerMessageIndexIdentifierFormatter : NSObject - (NSNumber *)messageUIDFromIdentifier:(NSString *)identifier; - (NSString *)folderNameFromIdentifier:(NSString *)identifier; @end 

ストアの 変更 -StateStorage-後続の処理のために変更を保存するモジュール。 彼は、変更のタイプ、変更されたオブジェクトのタイプ、およびその識別子を格納するトランザクションを受け取り、それをデータベースに保存します。 インデックス付きオブジェクトのタイプごとに、このデータベースには1つのレコードがあります。 各オブジェクトには、さまざまなタイプの変更の識別子のOrderSetが含まれています。 これは、あるタイプのオブジェクト変更の識別子が繰り返されないようにするために必要です。

 @interface RamblerIndexerStateStorage : NSObject - (void)insertTransaction:(RamblerIndexTransaction *)transaction; - (void)insertTransactionsArray:(NSArray<NSArray *> *)transactionsArray                    changeType:(RamblerChangeType)changeType; - (RamblerIndexTransactionBatch *)obtainTransactionBatch; - (void)removeProcessedBatch:(RamblerIndexTransactionBatch *)batch - (BOOL)shouldPerformInitialIndexing; @end 

システムのコア（モニター） -IndexerMonitor-このモジュールは、システムの他のすべての部分を接続します 。 モニターには以下が含まれます。

• 各タイプのオブジェクトのインデクサーとプロバイダーのセット。
  
• プロバイダーからの変更を保存するStateStorage。
  
• 操作が一連の変更のインデックスを作成するキュー。
  
• CSSearchableIndex、およびそのデリゲートとして機能します。
  

 @interface RamblerIndexerMonitor : NSObject - (void)startMonitor; - (void)stopMonitor; - (void)addIndexer:(id<RamblerIndexer>)indexer withChangeProvider:(id<RamblerChangeProvider>)changeProvider; @end 

作業アルゴリズム

プロセス全体を2つの論理期間に分けることができます。

• 変更の保存 -この段階で、変更に関するイベントが収集され、データベースに保存されます。 この期間の段階は、図上で赤いマーカーでマークされています。
  
• 変更の索引付け - 変更セットを取得して索引付けします。 期間の段階は紫色のマーカーでマークされています。
  

変更を保存する手順：

1. NSFetchedResultsControllerは、デリゲートメソッドを使用して、ソースデータベース内のオブジェクトの変更についてプロバイダー（<ChangeProvider>）に通知します。
   
   

    - (void)controller:(NSFetchedResultsController *)controller didChangeObject:(NSManagedObject *)anObject atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type newIndexPath:(NSIndexPath *)newIndexPath; 

   
   
2. プロバイダーは、モニター上のデリゲートメソッドを呼び出します。デリゲートメソッドでは、プロバイダー自体、オブジェクト、および変更の種類を渡します。
   

    - (void)changeProvider:(id<RamblerChangeProvider>)changeProvider didChangeObject:(id)object changeType:(RamblerChangeType)changeType; 

   
   
3. モニターは、プロバイダーによって関連付けられたインデクサーを判別し、このオブジェクトの識別子を要求します。 インデクサーは、このためにIndexIdentifierFormatterを使用します。 次に、モニターは識別子と変更の種類からトランザクションを生成し、それをStateStorageに渡します。
   
4. StateStorageは、現在のタイプのオブジェクトのIndexState（NSManagedObject）を要求または作成し、そのOrderSet（insertIdentifiers、updateIdentifiers、deleteIdentifiers）を埋めます。 変更の関連性を判断するために必要な変更日を設定します。 そして、変更をデータベースに書き込みます。
   

インデックス作成の変更手順：

1. たとえば、インデクサーのデリゲートメソッドの呼び出し、監視の開始、バックグラウンドの終了などの特定のイベントによって、モニターは、現在実行されていない場合はインデックス作成を開始する必要があることを認識します。
   
2. モニターは、StateStorageに、1種類のオブジェクト（IndexStateから作成）の変更のみを含むIndexTransactionBatchオブジェクトの形式で一連の変更を要求します。
   
3. メソッドを使用して監視する

    - (BOOL)canIndexObjectWithType:(NSString *)objectType 

   特定のタイプのオブジェクトで一連の変更を処理できる最初のインデクサーを見つけ、このセットに渡してインデックス作成操作を作成します。
   
4. インデクサーは操作を作成し、モニターに返します。
   
5. モニターは、操作を処理キューに追加します。 操作完了ブロックが呼び出されると、インデックス作成が成功すると、バッチがStateStorageに渡され、データベースから処理されたすべての識別子が削除されます。 その後、次の変更を処理できます。
   

操作：

1. insertIdentifiersとupdateIdentifiersを組み合わせて、一意の識別子のみを残し、その後、結果のOrderSetからdeleteIdentifiersから識別子を削除します。
   
2. インデックス作成のためにインデックス付きオブジェクトのインデクサーを照会します。
   
3. 結果のオブジェクトに対して、CSSearchableItem'ovの配列を要求し、CSSearchableIndexにインデックスを付けるためにそれらを提供します。
   
4. 完了したら、deleteIdentifiersを検索結果から削除するためにCSSearchableIndexに渡します。
   
5. その後、完了ブロックが呼び出され、メソッドに渡されます。
   

一次索引付け

システムの最初の起動時に、モニターはStateIndexにプライマリインデックス化が実行されたかどうかを尋ねます。 StateStorageは、少なくとも1つのIndexStateが存在するかどうかを確認します。 レコードが存在しない場合、プライマリインデックスはまだ発生していません。 モニターはすべてのプロバイダーにプライマリインデックスのオブジェクトのリストを要求し、それらからトランザクション配列の配列（オブジェクトの種類ごとに1つの配列）を作成します。 これらはすべて、StateStorageのストレージに転送されます。

StateStorageは、これらすべての変更を1つのperformBlockAndWaitに保存します。これにより、原子性が保証されます。 その結果、すべての変更が保存されるか、単一の変更が保存されない場合（アプリケーションがオフになっている場合）、その場合はプライマリインデックスが再度実行されます。

まとめ

任意のタイプのオブジェクトにインデックスを付けるために簡単に拡張および統合でき、記事の冒頭で設定した他のすべての要件も満たすシステムを手に入れました。

統合のためには、RamblerIndexerBaseクラスの基本機能を継承する独自のインデクサーをいくつか定義する必要があります。オブジェクトがデータベースに保存されていない場合は、いくつかのプロバイダーを定義する必要があります。 それ以外の場合は、RamblerFetchedResultsControllerChangeProviderクラスを使用できます。 その後、システム全体が手動またはTyphoonなどのDIフレームワークを使用して組み立てられます。

仕事のいくつかの特徴：

• モニターはCSSearchableIndexデリゲートメソッドを処理して、オブジェクトのインデックスを再作成する必要があります。 iOSには、インデックス付きオブジェクトの数に制限があることも知っておく必要があります。これらは、10,000個のオブジェクトと、合計インデックスサイズの約130 MBです。
  
• インデックス作成は、1つのスレッドでのみ同時に行う必要があります 。 そのため、 操作キューを使用します 。
  
• 識別子にスペースを使用しないでください。
  
• 検索結果の関連性を高めるには、NSUserActivityを実装し、CoreSpotlight実装と同じ識別子と同じ属性を使用する必要があります。 これには、すでに準備されたインデクサーを使用できます。
  
• 5〜10個のキーワードをお勧めします。
  

この記事で紹介したシステムはまもなくGitHubで公開され 、Twitter Rambler.iOSで報告し、この記事へのリンクも追加します。

検索結果を開く処理については、次のパートで説明します。 さらに、アプリケーションを起動するためのさまざまなオプションのロジックの多様性（プッシュ通知、検索結果から、通常の起動）、開くときの入力パラメーターの処理（通知からのuserInfo、NSUserActivity）、目的の画面に移動する方法などのトピックをカバーします（例：複数のストーリーボードを含むナビゲーションスタックを手動で取得する）。

便利なリンク：

ドキュメント：
iOS Search APIのベストプラクティスとFAQ
アプリ検索プログラミングガイド
NSUserActivityクラスリファレンス
コアスポットライトフレームワークリファレンス

WWDC 2015のビデオ：
WWDC 2015の検索APIの紹介
アプリへのシームレスなリンク

コード例：
WWDC 2015：AndrésIbañezによる検索APIの紹介
iOS 9：Davis Allieによる検索APIの紹介