さっきcoredataの説明を見つけて、3部分けましたが、まだよくわかりません.

iPhoneのすべてのデータ格納方法では、Core Dataは重要なデータ格納に最適です.アプリケーションのメモリオーバーヘッドを低減し、応答速度を向上させ、煩雑なコードから解放することができます.
しかし、Core Dataを学ぶ道は非常に長い.しかし、これもこの一連のチュートリアルの由来です.Core Dataの基礎知識を迅速に身につけることができます.
このシリーズのチュートリアルの第1部として、オブジェクトの可視化データモデルを構築します.有効性を保証するために、高速汚いテスト(dirty testでその頑丈性と有効性を検証)を行い、テーブルビュー(table view)にチェックマークを付けます.これにより、この列のオブジェクトが表示されます.
シリーズチュートリアルの第2部では、Core Dataにデータを事前にロードする方法について説明します.これにより、アプリケーションが開始されると初期化されます.
最後のセクションでは、NSFetchedResultsControllerを使用してアプリケーションを最適化し、メモリのオーバーヘッドを低減し、応答時間を改善する方法について説明します.
このチュートリアルが始まる前に、以前書いたSQLite for iPhone Developersチュートリアルをめくることをお勧めします.これは理解しやすくなります.また、2つのチュートリアルで作ったアプリ(app)は同じですが、今回はCore Dataを使っています!
Core Dataプロジェクトの作成
では始めましょう!新しいWindow-based Applicationを作成し、「UseCore Data for storage」にチェックマークを付け、プロジェクトを「FailedBanksCD.」と命名します.
始める前に、建設された工事をすばやく見てみましょう.まずResourcesを展開し、FailedBanksCDをダブルクリックします.xcdatamodelでは、ビジュアル化エディタがポップアップされます.これが、次に使用するモデルオブジェクトの図です.まず閉じましょう
そしてFailedBanksCDAppDelegateを見てみましょうm.ここでは、Core Dataスタックを構築するために実装された新しい関数が表示されます.」managed object context、managed object model、persistent store coordinatorが追加されました.あ??
心配しないで.名前は変に聞こえ始めますが、「任督二脈」を通じると、彼らが何なのか分かりやすいです.

Managed Object Model:データベース計画図と見なすことができます.これは、データベースに格納されている他のオブジェクト(Entitiesとも呼ばれる)定義を含むクラスです.通常、データベースのオブジェクト、プロパティ(attributes)がどのように関連付けられているかを設定するには、狙ったばかりのビジュアル化エディタが使用されます.しかし、コードで実現することもできます.

Persistent Store Coordinator:データベースへの接続と見なすことができます.ここでは、オブジェクトを格納するためのデータベースの実際の名前と場所、および必要に応じて保存するための管理オブジェクトコンテキスト(managed object context)を設定します.

Managed Object Context:データベースからオブジェクトを取り出す「一時保存」と見なすことができます.私たちにとってそれもこの3つの中で最も重要です.私たちの多くは上で働いているからです.基本的に、オブジェクトを取得したり、オブジェクトを挿入したり、削除したりする必要がある場合は、管理オブジェクトコンテキスト(managed object context)のメソッド(またはほとんどの時間!)を呼び出します.

 
これはシリーズチュートリアルの第2部で、基本的なCore Dataの内容を把握するのに役立ちます.
一連のチュートリアルでは、オブジェクトの可視化データモデルを構築し、高速汚いテストを実行し、テーブルビュー(table view)にチェックマークして表示します.このチュートリアルでは、既存のデータをCore Dataにインポートまたは事前にロードする方法について説明します.これにより、アプリケーションの開始時に良いデフォルトデータが得られます.
チュートリアルの最後のセクションでは、NSFetchedResultsControllerを使用してアプリケーションを最適化し、メモリのオーバーヘッドを削減し、応答時間を向上させる方法について説明します.
Preloading/Importing Existing Data
既存データのプリロード/インポート
Core Dataにデータを事前にロードするにはどうすればいいですか?ポピュラーなソリューションは2つあります.

起動時に外部ソースからCore Dataを入力します.これに対して、データベースがインポートされていないことに注意してください.アプリケーションは、起動時に外部ソース(SQLiteデータベースやXMLファイルなど)からデータを読み出すことができます.

は、SQLiteデータベースに予め埋め込まれている.これにより、Core Dataはモデルに基づいてデータベース構造を構築し、ツールを使用してデータベースに埋め込むことができます.このようなツールは、Core Data APIベースのMacまたはiPhoneアプリケーション、またはSQLiteデータベースに直接入力するプログラムであってもよい.データベースが記入されると、既存のデータベースが存在しない場合は、アプリケーションにデフォルトのデータベースとして含めるだけです.

私たちは2つ目の方法を採用します.それはもっと簡単で効果的だからです.データベースを埋め込むには、既存のPythonスクリプトを少し拡張するだけです.
Core Data APIベースのツールではなくPythonスクリプトを使用してデータをインポートする理由に気づきました.なぜなら、私たちは今少し最下位の姿をしているので、将来壊れやすいかもしれません.しかし、このチュートリアルでは、第一に、SQLiteに触れたばかりなので、学習の経験が強固になり、仕事の進展がより明確になったからです.第二に、もっと簡単です!
では、エンジニアリングで生成されたsqliteデータベースのコピーを取り出しましょう.関連ファイルを見つける最も簡単な方法は、プログラム依頼(application delegate)のpersistentStoreCoordinator関数のstoreUrl行の下にブレークポイントを設定することです.storeUrl変数の内容を検出することで、sqliteデータベースのバックアップファイルの完全なパスを取得できます.それを見つけてPythonスクリプトディレクトリにコピーします.
データベースを見つけたら、sqlite 3を使用してデータベースの様子を簡単に見てみましょう.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 sqlite3 FailedBanksCD.sqlite   sqlite3> . schema CREATE   TABLE   ZFAILEDBANKDETAILS ( Z_PK  INTEGER   PRIMARY   KEY , Z_ENT  INTEGER ,      Z_OPT  INTEGER , ZZIP  INTEGER , ZINFO  INTEGER , ZUPDATEDDATE  TIMESTAMP ,      ZCLOSEDATE  TIMESTAMP   ); CREATE   TABLE   ZFAILEDBANKINFO ( Z_PK  INTEGER   PRIMARY   KEY , Z_ENT  INTEGER ,      Z_OPT  INTEGER , ZDETAILS  INTEGER , ZNAME  VARCHAR , ZSTATE  VARCHAR ,      ZCITY  VARCHAR   ); CREATE   TABLE   Z_METADATA (Z_VERSION  INTEGER   PRIMARY   KEY ,      Z_UUID  VARCHAR (255), Z_PLIST BLOB); CREATE   TABLE   Z_PRIMARYKEY (Z_ENT  INTEGER   PRIMARY   KEY , Z_NAME  VARCHAR ,      Z_SUPER  INTEGER , Z_MAX  INTEGER ); CREATE   INDEX   ZFAILEDBANKDETAILS_ZINFO_INDEX  ON   ZFAILEDBANKDETAILS (ZINFO); CREATE   INDEX   ZFAILEDBANKINFO_ZDETAILS_INDEX  ON   ZFAILEDBANKINFO (ZDETAILS);   sqlite>  select   *  from   ZFAILEDBANKINFO; 1|2|1|1|Test Bank|Testland|Testville 2|2|1|2|Test Bank|Testland|Testville 3|2|1|3|Test Bank|Testland|Testville   sqlite>  select   *  from   ZFAILEDBANKDETAILS; 1|1|1|12345|1|292794835.855615|292794835.679693 2|1|1|12345|2|292794875.943392|292794875.768675 3|1|1|12345|3|292795809.375025|292795809.215297   sqlite>  select   *  from   Z_PRIMARYKEY; 1|FailedBankDetails|0|3 2|FailedBankInfo|0|3
ここには簡単な説明があります.Z_METADATAには、Core Dataの実装に必要なモデル情報がいくつか含まれています.Z_PRIMARYK EYには、各エンティティで使用される最大キーが含まれています.
ZFAILEDBANKINFOとZFAILEDBANKDETAILSについては、これらが主なデータテーブルです.Z_PKは各テーブルの唯一のid、Z_ENTは彼らのエンティティid(Z_PRIMARYKEYテーブルにリストされているのと同じ)であり、最後にそれらは私たちの一般的なフィールドです.
 
 
今まで、私たちの今の立場はSQLite 3を使っていたときと同じです.しかし、これほど多くのコードを書く必要はありません(FailedBankDatabaseクラスで欠落している元のSQL文コードに注意してください).挿入/削除などの操作を追加するのも簡単です.
NSFetchedResultsControllerを使用すると、Core Dataで表現できる顕著な利便性があります.
理想的な状態は、ユーザが現在見ているtable viewに行の一部をロードすることである.幸いなことに、アップルは私たちにこの便利さを生み出し、素晴らしいツールクラスを提供しました:NSFetchedResultsController.
そこで、FailedBanksListView Controlを開く.h,古いNSArray failedBankInfosを除去し,新しいNSFetchedResultsControllerに置き換える:
@interface FailedBanksListViewController : UITableViewController  { NSFetchedResultsController *_fetchedResultsController; NSManagedObjectContext *_context;}@property (nonatomic, retain) NSFetchedResultsController *fetchedResultsController;@property (nonatomic, retain) NSManagedObjectContext *context;@end
synthesizeセグメントで古いfailedBankInfosコードを除去し、次のように追加します.
@synthesize fetchedResultsController = _fetchedResultsController;
忘れないようにdeallocメソッドでfetchedResultsControllerをnilに設定
self.fetchedResultsController = nil;
もう一つの素晴らしい点は、viewDidUnloadでNSFetchedResultsControlをnilに設定できることです.これは、低メモリの場合、メモリのすべてのデータが解放されることを意味します(ビューが視線から離れた場合).viewDidUnloadで空にするだけです(viewDidLaodで再初期化することを保証します)
- (void)viewDidUnload { self.fetchedResultsController = nil;}