問題タブ [uimanageddocument]

UIManagedDocument を使用して Core Data にアクセスしています。知りたいのは、managedDocument をインスタンス化すると (作成または開く前に)、後で使用するために managedObjectContext がセットアップ/初期化されているように見えることです。私が尋ねる理由は、起動時に managedObjectContext をコントローラーに渡し、managedDocument/database が作成または使用のために開かれている間、そこで待機したいからです。

アプリケーション全体（2つのエンティティを含む）に単一の管理対象ドキュメントがあり、ユーザーは2つの異なるViewControllerから更新できます。各ビューコントローラーには、変更を中継するための独自のNSFetchedResultsControllerプロパティがあります。一方のビューコントローラーのUICollectionViewと、もう一方のUITableViewです。ルートビューコントローラーのUICollectionViewにはチームが表示され、セグエビューコントローラーのUITableViewにはそのチームのプレーヤーが表示されます。

最初のViewControllerにいるときは、チームのインスタンスを追加できます。インスタンスをドキュメントに保存してからUICollectionViewに追加すると、正常に機能します。2番目のViewControllerにいるときに、CoreDataにPlayerを挿入して、次のように呼び出します。

これにより、NSFetchedResultsControllerDelegateメソッドが正しく呼び出されます。-（void）controller：didChangeObject：atIndexPath：forChangeType：newIndexPath：

このデリゲートメソッドでは、次のように呼び出します。

ただし、テーブルビューでこの行挿入メソッドを呼び出すと、次のCoreDataエラーが発生します。

"CoreData：エラー：重大なアプリケーションエラー。コアデータの変更処理中に例外がキャッチされました。これは通常、NSManagedObjectContextObjectsDidChangeNotificationのオブザーバー内のバグです。 * -[__ NSPlaceholderArray initWithObjects：count：]：オブジェクト[0]からnilオブジェクトを挿入しようとしていますuserInfo（null） "

私のfetchedResultsControllerは確かにNSManagedObjectContextObjectsDidChangeNotificationのオブザーバーですが、このエラーは管理対象オブジェクトのコンテキストが変更される前に発生しています。したがって、基本的に、管理対象オブジェクトコンテキストがnulluserInfoを取得している時点を特定できません。

（もう1つ発生するのは、UICollectionViewを持つルートビューコントローラーからのNSFetchedResultsControllerが、UITableViewを持つ次のビューコントローラーのNSFetchedResultsControllerが独自の機能を起動する直前にデリゲートメソッドを起動することです。これは正しい機能だと思います。チームとプレーヤーの両方がCoreDataで更新を取得しているため）。

UITableView行の挿入がこのエラーを引き起こしている理由、または単一の管理対象ドキュメントにこれを引き起こす可能性のある不整合がどのように発生する可能性があるかについての考えはありますか？

UIManagedDocument を作成していますが、次のようなエラーが表示される理由がわかりません。

私のコードで唯一のものは、 this の作成ですUIManagedDocument。この関数はviewDidLoad:

NSLog を介してクラスを印刷して[[UIManagedDocument alloc] initWithFileURL:url]、オブジェクト型であるかどうかを確認しようとしUIManagedDocumentましたが、NSLog コード行に EXC_BAD_ACCESS が再び表示されました。

次の詳細が問題に関連しているかどうかはわかりません。iOS 5.1 シミュレーターで Xcode 4.3.3 を使用しています。これを iOS 5.0 Simulator で実行しようとしましたが、同じエラーが表示されました。私の Mac OS X のバージョンは 10.7.4 です。

なぜこのエラーが発生していると思いますか?

過去 2 日間解決しようとしていた非常に奇妙な問題があります... 5.1 SDK を使用して、Xcode 4.4 および iOS 5.1 シミュレーターで完全に正常に動作するコードがありました。Xcode 4.5 と 6.0 SDK に更新した後、私のコードは iOS 5.1 シミュレーターで動作しなくなりました... iOS 6.0 シミュレーターでは完全に動作しますが。私が気付いていない変化はありましたか？

これはコードです：

何らかの理由で、saveToURL と openWithCompletionHandler が 5.1 シミュレーターで返されません。誰でも理由を知っていますか？

UIManagedDocumentAppDelegate で を作成または開いています。完了ハンドラ ブロックを使用して、ドキュメントの使用準備が整ったときに通知します。

私の質問はNSFetchedResultsController、ViewController に をセットアップしたいのですが、現在、(AppDelegate からの) ドキュメントが作成または開かれる前に、コントローラー ビューが読み込まれます。ドキュメントが開いて使用できるようになったことをコントローラーに通知する方法に興味があります。を使用すると思いますがNSNotification、間違った方法で行っていないことを確認したかっただけです。

デッドロックまたは同期の問題と思われるものを次のように「解決」しました。

IPODライブラリからのMPMediaItem（音楽/画像）プロパティ参照をオブジェクトインスタンスにアタッチするアプリで、これらのオブジェクトはCoreDataを介してバックストアされます。ここでの私の関心は、何が起こっているのか、そしてこの状況でのベストプラクティスは何かを正確に理解することです。ここに行きます：

これを毎回複製するレシピは次のとおりです。

1. ユーザーが新しいプロジェクトを作成します。

   /li>

2. その後、managedObjectContextを使用して、オブジェクトインスタンスを関連付け、CoreDataモデルをハイドレイトします。

   /li>

3. ユーザーは後で「CustomAction」オブジェクトを作成し、それに「ChElement」を追加して、「MusicElement」をChElementに関連付けます。（これらはCoreDataモデルオブジェクトの仮名です）。MusicElementは、IPODライブラリを介して追加されます。

   /li>

4. ユーザーはこのプロジェクトを保存してから、ChElementとMusicElementを使用して1つのCustomActionオブジェクトがすでに作成されている既存のプロジェクトに切り替えます。

5. ユーザーは、tableViewからそのChElementを選択し、detailViewに移動します。ChElementTVC（Appleドキュメントにあるものと同様のCoreData TableViewControllerクラスのサブクラス）から移動する場合は、次のことが必要です。

   /li>

6. 詳細ビューで、ユーザーはChElementオブジェクトの属性を変更し、プロジェクトを保存します。detailViewは、そのデリゲート（ChElementTVC）を呼び出して保存を行います。保存は、NSManagedObjectを保持するUIManagedDocumentインスタンスに行われます。

   /li>

7. デリゲート（ChElementTVC）がナビゲーションスタックからdetailViewをポップしたため、そのviewWillAppearが呼び出され、fetchedResultsController.delegateが復元されます。

   /li>

アプリがないと[NSThread sleepForTimeInterval:0.1];ハングします。Xcodeを介してSIGINTを送信すると、デバッガーが取得され、次のことがわかります。

（lldb）bt

（lldb）フレーム選択5

（lldb）逆アセンブル-f

別の回避策が可能です。fetchedResultsController.delegate復元をコーディングする-[ChElementTVC viewDidAppear:]と、メインキューでのこの設定も効果的に遅延します。

追加の回避策は、プロジェクトの保存が完了した後、完了ブロックでnavpopを実行することです。

保存操作はメインキューでのデリゲートの復元と同時にバックグラウンドで実行されると思いますが、その理論を検証/証明/反証する方法がわかりません。

それで、誰かが何が起こっているのか、そしてこの状況でのベストプラクティスは何であるかを説明できますか？また、研究のための参考文献をいただければ幸いです。

私のアプリは、UIManagedDocument 内に含まれるコア データ データベースを使用します。iCloud 経由で同期しようとすると、データが更新されることはめったにありません。次の app 引数をスキームに追加して、ユビキタス ログをオンにしました。

引数のログ出力は、送信元デバイスで変更が行われた直後に宛先デバイスが変更を認識することを示していますが、NSPersistentStoreDidImportUbiquitousContentChangesNotification通知はトリガーされません。場合によっては、更新が表示されてからかなりの時間が経過してから通知がトリガーされることがありますが、通常はそうではありません。

ただし、アプリを再起動すると (ログに変更に関するテキストが出力された後はいつでも)、 NSPersistentStoreDidImportUbiquitousContentChangesNotification通知がすぐにトリガーされ、データが更新されます。

注: 通知を購読しました。

次のように、iCloud をサポートする新しい UIManagedDocument を作成しています。

1. ローカル サンドボックス URL を割り当てて初期化する
2. iCloud をサポートする永続ストア オプションを設定します: ubiquitousContentNameKey および ubiquitousContentURL。私が一意に生成している名前で、URL は私の ubiquityContainer / CoreData を指しています。
3. UIManagedDocument の saveToURL メソッドを使用してサンドボックスにローカルに保存します。
4. 完了ハンドラーでは、FileManager の setUbiquitous メソッドで iCloud に移動します。

これまでのところ、このダンスは機能します。（まあ、ちょっと）。setUbiquitous を呼び出した後、成功しなかったというエラーが表示されますが、ドキュメントはクラウドに移動します。完了すると、クラウドに新しいドキュメントが作成されます。他の人のコードで再現できたので、これはバグのようです。

このドキュメントは、クラウド内のすべてのドキュメントを一覧表示する「Documents View Controller」で実際に生成しています。したがって、この新しいドキュメントの最終的な完了ハンドラが完了すると、NSMetadataQuery のおかげでテーブル ビューに表示されます。これまでのところ、かなり標準的な使い方だと思います。

ドキュメントを編集するには、ユーザーはタップして「Single View Document View Controller」に移動します。

このView Controllerでは、ユーザーが編集できるように、選択したドキュメントを「再度開く」必要があります。

したがって、一連の手順をもう一度実行します。

1. fileURL を使用して UIManagedDocument を割り当て/初期化します。今回は、URL はクラウドからのものです。
2. 上記の手順 2 と同じ設定で、永続ストア オプションを設定します。

ここで、ディスクからドキュメントを開くステップ 3 を試みましたが、失敗しました。ドキュメントは「Closed | SavingError」の状態にあり、開こうとすると失敗します。

ドキュメントの作成はOKで、クラウドへの移動はOKなのに、その後すぐに開くことができない理由を知っている人はいますか? (実際には、アプリのその起動内での試み - 以下を参照してください)。具体的には、UIManagedDocument インスタンスを作成するが、閉じた、開くことができない状態にするのは何ですか?

興味深いことに、アプリを終了して再度起動すると、ドキュメントをタップして再読み込みし、編集することができます。

そして、非常にまれに、作成してから開き、非常に簡単に編集することができます。たとえば、1 つの管理対象オブジェクトを挿入すると、このクローズ | エラー状態を保存しています。

エラー情報:

私は UIManagedDocument をサブクラス化し、 -handleError: メソッドをオーバーライドして、より多くの情報を取得しようとしました。これが私が得たものです (私が入れた他のデバッグ ログと共に):

2012-10-05 14:57:06.000 Foundations[23687:907] 単一ドキュメント ビュー コントローラー ビューが読み込まれました。ドキュメント: fileURL: file://localhost/private/var/mobile/Library/Mobile%20Documents/7PB5426XF4~com~howlin~MyApp/Documents/New%20Document%2034/ documentState: [Closed]

2012-10-05 14:57:06.052 MyApp[23687:907] ドキュメントの状態が変更されました。現在の状態: 5 fileURL: file://localhost/private/var/mobile/Library/Mobile%20Documents/7PB5426XF4~com~howlin~MyApp/Documents/New%20Document%2034/ documentState: [Closed | 保存エラー]

2012-10-05 14:57:06.057 Foundations[23687:5303] UIManagedDocument エラー: ストア名: 新しいドキュメント 34 は既に使用されています。ストア URL: file://localhost/private/var/mobile/Library/Mobile%20Documents/7PB5426XF4~com~howlin~MyApp/Documents/New%20Document%2034/StoreContent.nosync/persistentStore 使用中ストア URL: file:/ /localhost/var/mobile/Applications/D423F5FF-4B8E-4C3E-B908-11824D70FD34/Documents/New%20Document%2034/StoreContent.nosync/persistentStore

2012-10-05 14:57:06.059 MyApp[23687:5303] { NSLocalizedDescription = "ストア名: 新しいドキュメント 34 は既に使用されています。\n\tストア URL: file://localhost/private/var/mobile/ Library/Mobile%20Documents/7PB5426XF4~com~howlin~MyApp/Documents/New%20Document%2034/StoreContent.nosync/persistentStore\n\t使用中のストア URL: file://localhost/var/mobile/Applications/D423F5FF-4B8E -4C3E-B908-11824D70FD34/Documents/New%20Document%2034/StoreContent.nosync/persistentStore\n"; NSPersistentStoreUbiquitousContentNameKey = "新しいドキュメント 34"; }

エラーは、その後のオープン時に既に存在するストアを作成していると思われるようです。2 回目のオープン時に永続ストアでこれらの iCloud オプションを設定することになっていますか? 私はそのアプローチを試みましたが、うまくいきませんでした。

UIManagedDocument に関するスタンフォード大学の講義を研究しましたが、何が間違っているのかわかりません。

ドキュメントを作成してクラウドに移行する方法は次のとおりです。

ここで、persistentStore で iCloud のオプションを設定します。

そして、ここで私はそれを再開しようとしています：