テーブルビューを備えたナビゲーションビューがあります。行がクリックされると、行のindexPathが次のビューに渡されます。
詳細ビューviewDidLoadで、CoreDataからデータをフェッチしています。アプリケーションデリゲートからのフェッチを使用します
[appDelegate loadItem:i];
ご覧のとおり、行番号を含む1つの整数のみを渡しています。
問題は次のとおりです。別のスレッドでこの呼び出しプロセスを実行するにはどうすればよいですか。（バックグラウンドで）フェッチの結果が大きすぎる場合があるため、これが必要です。そのため、処理に3秒かかり、詳細ビューのプッシュが遅れます。
アクティビティインジケーターを3秒間表示する必要があるため、フェッチの処理中にインジケーターのUIを使用できるようにするには、フェッチを別のスレッドに配置する必要があります。
私は初心者なので、最も簡単な方法が必要です。いくつかのコードを投稿するのは素晴らしいことです。またはリンク:)
マルチスレッドとコアデータの混合は簡単な作業ではありません。Core Dataプログラミングガイドの「CoreDataを使用したマルチスレッド」セクションでは、注意が必要なすべての事項を含め、複数のスレッドでCoreDataを操作する方法について説明しています。
基本的に、スレッドごとに個別の管理対象オブジェクトコンテキストを作成する必要があります。これらのコンテキストは、1つの管理対象オブジェクトモデルと永続ストアへのアクセスを共有できます。あなたの場合、彼らは次のことを提案します：
1つの永続ストアコーディネーターに関連付けられた2つの管理対象オブジェクトコンテキストを使用します。バックグラウンドスレッドで1つの管理対象オブジェクトコンテキストをフェッチし、フェッチされたオブジェクトのオブジェクトIDを別のスレッドに渡します。2番目のスレッド（通常はアプリケーションのメインスレッドで、結果を表示できるようにするため）では、2番目のコンテキストを使用してそれらのオブジェクトIDを持つオブジェクトに障害を発生させます（objectWithID：を使用してオブジェクトをインスタンス化します）。
BackgroundFetchingサンプルアプリケーションがこれを行う方法を示しているように聞こえますが、私のシステムにはありません。
ただし、フェッチリクエストのマルチスレッド化に取り掛かる前に、ロードに時間がかかる理由を詳しく調べます。まず、NSFetchRequestで-setFetchBatchSize：を使用して、フェッチを介してメモリに読み込まれるオブジェクトの数を制限することをお勧めします（これにより、多くのメモリも節約できます）。次に、-setPropertiesToFetch：を使用して、フェッチされるプロパティを、すぐに使用するプロパティのみに制限します。