2

さて、私が野鳥観察アプリを作っているとしましょう。

「公式の」鳥のデータベースがあります。これは 1 つに格納されUIManagedDocumentます。UITableViewすべての鳥と、それぞれの写真とデータを少し詳細に表示するために使用されます。このデータベースは、将来、より多くの鳥種でアップグレードされる予定です。

その後、ユーザーは田舎に出かけて鳥の写真を撮ることができます。彼はそれらを「日記」と呼ばれるアプリの別のセクションに追加し、鳥を特定すると、それを1つの「公式」鳥にリンクします。この情報 (ユーザーが収集したすべてのデータ) は、iCloud でバックアップする必要があります。また、ダイアリーUITableViewと詳細ビューの入力にも使用されます。

日記の詳細ビューから、「公式」鳥の詳細ビューに移動できます。そして、そのビューから、ユーザーの日記にあるその鳥のすべての記録を含むリストに移動できます。

問題はUIManagedDocument、ユーザーのエントリごとに 1 つ使用する必要があるかどうかです。UITableViewサムネイル付きでそれはどのように機能しますか?

4

3 に答える 3

3

AUIDocumentは、物理ファイル ラッパーの管理クラスです。AUIManagedDocumentは、CoreData スタックを提供するクラスのサブクラスです。

File Wrapperは、フォルダーまたはファイルの抽象化にすぎません。そのUIManagedDocumentフォルダーには、CoreData スタックが接続する SQLite データベースが含まれています。

文章の各段落に個別の Word ドキュメントを使用するのと同じように、日記エントリに個別のドキュメントを使用することはありません。

あなたのアプリは、Apple が「Shoebox アプリ」と呼んでいるものに似ているため、1 人のユーザーがデータの山を 1 つ持っており、それらを追加したり削除したりします。ドキュメント アーキテクチャを使用する必要はありません。ただし、これUIManagedDocumentにより無料のスタックが提供されるため、役立つ場合があります。

このアプリを作成するのが私だったら、このアプローチを取るかもしれません。

  1. 公式鳥類の読み取り専用データベース。このデータベースは、初回起動時および更新が必要なときにダウンロードされます。かなり大きくなるので、これをバンドルに入れないでください。どの時点でもバックアップされません。

  2. 日記のエントリを保持する読み書き可能なデータベース。このデータベースは iCloud にバックアップされており、Bird データベースをアップグレードしても変更されません。

  3. CoreData リレーションシップではなく GUID を使用して、2 つのデータベースを疎結合します。

ここに画像の説明を入力

たとえば、マガモの GUID はDUCK1234. その GUID を日記エントリの属性 (例: birdGUID ) として書き込みます。マガモのダイアリー エントリをすべて見つけるには、ダイアリー データベースで "birdGUID == 'DUCK1234'" に対してクエリを実行します。

これを行う理由は、ユーザー データの損傷を心配することなく、公式の鳥データベースをアップグレードできるためです。より良い/安価なデータベース、または鳥の鳴き声を持つ別のデータベースを購入すると、それに対処するためにスキーマを調整できます。

編集

1 つのアプローチ (簡単なアプローチ) は、2 つのスタックでスタックを構築することです。NSPersistentStores 

NSPersistentStoreCoordinator *myPersistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[NSManagedObjectModel mergedModelFromBundles:nil]];

NSDictionary *readonly_options = @{NSReadOnlyPersistentStoreOption:@YES};

[myPersistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:officialBirdStoreURL options:readonly_options error:&error];

NSDictionary *readwrite_opts = @{NSMigratePersistentStoresAutomaticallyOption:@YES,
  NSInferMappingModelAutomaticallyOption:@YES};

[myPersistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:diaryStoreURL options:readwrite_opts error:&error];

NSManagedObjectContext *workingContext = [[NSManagedObjectContext alloc] initWithConcurrencyType: NSMainQueueConcurrencyType];

workingContext.persistentStoreCoordinator = myPersistentStoreCoordinator;

多くの優れた Core Data チュートリアルがあるため、これを完全に説明するつもりはありませんがNSReadOnlyPersistentStoreOption、Bird データベースの設定に注意してください。

UIManagedDocumentスタックを十分に制御できないため、これには使用は含まれません。

要約すると、下から上へのスタック。

  • UIManagedDocument- モデルコントローラー。File Wrapper のメカニズムを処理し、フリー スタックを提供します。必要ありません。マルチドキュメントアプリを簡単にするかもしれません（またはしないかもしれません）.
  • NSManagedObjectModel- Model 、コア データ モデルのスキーマ。
  • NSPersistentStore- Model 、ディスク上の単一の SQLite データベースを表します。
  • NSPersistentStoreCoordinator- 任意の数のコントローラーNSPersistentStore
  • NSManagedObjectContext- メモ用紙のようなモデルワークスペース。使用して保存するか、使用して破棄します。

この段階では、 に縛られないでくださいUIManagedDocument。その上に CoreData スタックを持つファイル システムのコントローラーです。箱から出してやりたいことはしません。

両方のデータベースをロードし、それらのデータを使用して UI を駆動する方法という実際の問題について心配してください。

後で本当に重要な場合は、UIManagedDocument ベースのアーキテクチャを移動できます。これが私のアプリなら、私は気にしません。

于 2013-09-13T14:58:52.297 に答える
0

UIManagedDocument私の github リポジトリhttps://github.com/dtrotzjr/APManagedDocumentを参照してください。役に立つかもしれませんが、そうでないかもしれません。;-)

于 2013-09-13T23:23:10.443 に答える
0

UIManagedDocumentアプリの提案に、ユーザー エントリごとに 1つ、ましてや 1 つを使用するかどうかさえわかりません。アプリの設計が地域に基づいて鳥の複数の「本」を持つことを意図していた場合 (例として)、UIManagedDocument「本」ごとに は理にかなっていますが、鳥の単一のデータベースを作成しているように思えます。時間の経過とともに構築されたものに加えて、ユーザーの全体をリストする「日記」があります (ただし、メインの鳥データベースの一部です)。

あなたのアプリは、単純な Core Data ベースのアプリの候補のように思えます。モデル設計には、鳥の記録に加えて、鳥の記録の「フィールド内ユーザー エントリ」を相互参照する「日記」を表すレコードが含まれます。複数の「日記」を持っていたとしても、UIManagedDocumentsやり過ぎのように見え、「単純な」Core Data 実装に固執する方がよいでしょう。

簡単にするためにNSFetchedResultsController、Core Data とユーザーの間のやり取りを管理するために を使用します。UITableView

私の意見では、複数をマージするUIManagedDocumentsと、設計がかなり複雑になります。

于 2013-09-12T14:07:24.260 に答える