問題タブ [uidocument]

ユーザーがアプリで iCloud を有効にすると、すべてのローカル ファイルを iCloud に移動する必要があります。ここでは、setUbiquitous:itemAtURL:destinationURL:error:各ファイルを移動するために使用します。問題は、(任意のローカル ファイルに対して) 同じファイル URL が iCloud に既に存在する場合、この方法は失敗することです。

私の質問は、iCloud バージョンを上書きするか、各ファイルのローカル バージョンを破棄できるように、どのファイルが新しいか (ローカルと iCloud) を判断するにはどうすればよいですか? または、どうにかして iOS にアップロードを強制し、iCloud でファイルの状態を競合状態に設定して、競合解決メソッドがこれを引き継いで処理できるようにすることはできますか?

I was under the impression that iCloud only worked with UIDocument files. How about other types?

Also if my user's files get uploaded into the cloud, can he use those files with all his devices if my app is universal?

次のメソッドを持つシングルトンクラス（DTTSingleton）があります。

そして、私のUITableViewControllerには、viewDidLoadメソッドに次のコードがあります。

実行すると、次のエラーが発生します。

キャッチされなかった例外'NSInternalInconsistencyException'が原因でアプリを終了しました、理由：'すでに開いているか、元に戻す操作が実行中のドキュメントを開こうとしたか、元に戻しました

このエラーが発生する理由を理解しています。これは、別の開くプロセスがすでに実行されているときにドキュメントを開こうとしているためです。だから私の質問は...

1）openWithCompletionHandlerが1回だけ呼び出されるようにするにはどうすればよいですか？

2）ドキュメントが開いたら、2番目のブロックが確実に実行されるようにするにはどうすればよいですか？

助けてくれてありがとう！

s を使用してデータを保存するUIDocumentベースのアプリがあります。NSFileWrapper「マスター」ファイル ラッパーには、多くの追加のディレクトリ ファイル ラッパーが含まれており、それぞれがドキュメントの異なるページを表します。

1 ページのごく一部しか変更されていない大きなドキュメントを保存する場合、UIDocumentはバックグラウンドで変更を書き込むのに長い時間を費やします ( をwriteContents:andAttributes:safelyToURL:forSaveOperation:error:参照)。確かに、ファイル ラッパーへのこの 1 つの小さな変更を書き出すだけのはずです...何がそんなに時間がかかっているのでしょうか?

私のcontentsForType:error:オーバーライドは、マスター ファイル ラッパーの内容を含む新しいディレクトリ ファイル ラッパーを返します ( WWDC 2012 セッション 218 - Using iCloud with UIDocument ):

Time Profiler からのスタック トレースの素敵な写真を次に示します。

ちなみに、そのワーカースレッドで保存するのに〜1.6秒と表示されています-実際の実行時間では、これは約8秒に相当します。

編集：

ファイルラッパーがディスクへの書き込みを必要とするかどうかを確認する方法はありますか? 小さな変更を加えたときにすべてのサブファイルラッパーを更新するなど、何らかの奇妙なことをしていないことを確認できるようにします（そうではないと確信していますが...）。

編集：

CloudNotes サンプル アプリをさらに試してみたところ、少なくともその場合は増分保存NSFileWrapper が実装されているようです! それぞれ約 5MB のデータを含む 100 のメモを含むドキュメントを初期化してテストしました。あちこちで小さな編集を行い (テキスト ビューに 1 文字変更すると、文書に保存が必要であるというフラグが付けられます)、各保存にかかった時間を大まかに記録しました。テストは比較的粗雑です (シミュレーターで実行します) が、結果は次のようになりました。

• 最初の書き込み: ~8000ms
• 2 回目の書き込み: ~4000ms
• 3 回目の書き込み: ~300ms
• 後続のすべての書き込み: ~40ms

特にバックグラウンド スレッドでファイル調整を使用して保存しているため、所要時間に影響を与える多くの要因があることは明らかですが、一般的には、すべての書き込みが非常に高速になるまで、この種の指数関数的な減衰が常に見られます。

しかし、なぜこれが私のアプリで起こらないのかを理解しようとしています。大きな複数ページのドキュメント (大きいが、上記で実行した CloudNotes テストのドキュメントよりも何倍も小さい) の場合、ユーザーはドキュメントが閉じるまで何秒も待つことができます。実質的に瞬間的なもののためにスピナーを設置する必要はありません。

s を使用してデータを保存するUIDocumentベースのアプリがあります。NSFileWrapper「マスター」ファイル ラッパーには、多くの追加のディレクトリ ファイル ラッパーが含まれており、それぞれがドキュメントの異なるページを表します。

UIDocumentの保存中に ( で) ドキュメントに変更を加えるたびにwriteContents:andAttributes:safelyToURL:forSaveOperation:error:、アプリがクラッシュします。スタック トレースは次のとおりです。

UIDocumentバックグラウンドで列挙しているファイルラッパーの同じインスタンスを変更していることは明らかです。実際、私は、データ モデルのスナップショットを返すときにcontentsForType:error:、返されたサブ ファイル ラッパーが、コピーではなく、データ モデルに現在存在する (および編集されている) オブジェクトと同じオブジェクトを指していることを確認しました。

これは、このメソッドを実装するための認可されたアプローチです ( WWDC 2012 Session 218 - Using iCloud with UIDocument によると)。

だから私は質問だと思います:このアプローチはどのようにしてスレッドセーフになることができますか?

マスター ファイル ラッパーfileWrappers自体がディレクトリ ファイル ラッパーである場合、状況は多少異なりますか? 認可されたアプローチが間違っている場合、それはどのように行われるべきですか?

私の iCloud ベースのアプリで、UIDocument が開いている (そしてまだ閉じられていない) 間にクラッシュが発生した場合、ドキュメントのステータスが になりUIDocumentStateSavingError、二度と正常に開かないことに気付きました。

この後に実行すると、ドキュメントが開かれず、と 5 (および) が[UIDocument openWithCompletionHandler:]返さNOれます。successUIDocumentStateClosedUIDocumentStateSavingErrordocumentState

iOS 5 ではNSMetadataQueryDidUpdateNotification、ファイルが削除されてアプリが再起動されるまで、常に (毎秒) 呼び出されていることも確認しました。これにより、アプリでさらにユーザビリティの問題が発生します。

もう 1 つ、developer.icloud.com で、競合する 2 つ目のバージョンが存在することをファイルが示していることに気付きました。ただし、アプリを再起動または再インストールしても、この競合はどのデバイスでも見つかりません。

UIDocument を正常に開くにはどうすればよいですか?

これが私がこれまでに試したことです：

• を使用して競合をチェック[NSFileVersion unresolvedConflictVersionsOfItemAtURL:]し、古いバージョンをすべて削除してい[NSFileVersion removeOtherVersionsOfItemAtURL:]ます。

• ファイルをデバイスに再ダウンロードするために呼び出す[[NSFileManager defaultManager] evictUbiquitousItemAtURL:]前に呼び出します。[UIDocument openWithCompletionHandler:]

• developer.icloud.com からメイン バージョンと競合するバージョンをダウンロードして、破損したファイルや部分的なファイルがないかどうかを確認します。どちらも問題なく開きます。

• 机に頭をぶつけます。暫定結果は不合格です。

複数のデバイスで iCloud で UIDocument を集中的に使用すると、大量のトランザクション ログが iCloud に保存されます。これにより、長期間使用するとiCloudの空き容量が減少します。

データを失わずにこれらのログを消去する方法があるのだろうか、つまり、デバイスは現在のデータ状態を復元できるはずですか? ログのある種の統合？

などの変更をアプリに通知する UIDocument のメソッドはpresentedItemDidChange、アプリがフォアグラウンドで実行されている場合にのみ呼び出されることに気付きました。

私が疑問に思っているのは、ユーザーがアプリを切り替えたり、アプリをバックグラウンドに送信したりした場合、ユーザーが最後にアプリをフォアグラウンドに移動したときに UIDocument が最後に表示されてから変更されたかどうかを知るにはどうすればよいですか?

または、UIDocument が更新された場合に備えて、アプリがフォアグラウンドに戻るたびにすべてを更新する必要がありますか?

iCloudでのUIDocumentsとの競合解決に関するドキュメントを読みました： ドキュメントバージョンの競合の解決

「ドキュメントバージョンの競合が解決されたことをiOSに伝える方法」の章の最後のポイントには、次のように書かれています。

ドキュメントの解決されたバージョンを削除します。不要になったバージョンについては、NSFileVersionのremoveAndReturnError：メソッドを呼び出して、ファイルのストレージを再利用します。ドキュメントのリビジョンは、削除するまでサーバーに残ります。

ただし、コードサンプル「リスト6-3」には、removeAndReturnError：メソッドが呼び出されていません。このメソッドは必要ありませんか、それともどこで呼び出す必要がありますか？

助けてくれてありがとう

リナード