問題タブ [nsfilewrapper]

サンプルをファイルに保存するために、AudioToolBox フレームワークの ExtAudioFileCreateWithURL と ExtAudioFileWrite を使用しました。しかし、NSDocument を使用しているため、NSFileWrapper に保存する必要があります。

NSFileWrapperinitRegularFileWithContents:(NSData*)contentsメソッドを使用できるように、NSMutableData オブジェクトで ExtAudioFileXXX 関数を使用する方法はありますか?

ファイルに保存するためのコードを削除しました (動作します):

NSFileWrapperディレクトリがあるとしましょう。このディレクトリは、いくつかのレベルのディレクトリとファイルで構成されています。一部のファイルはサイズが大きくなります。これらのファイルはすべてメモリにロードされていますか、それとも遅延ロードされていますか?

それらがメモリにロードされている場合、NSFileWrapperファイルをメモリにロードしない同様の機能を備えた代替手段はありますか? フックできるものはありUIDocumentますか？

これは、UIDocumentiCloud と同期される を使用するドキュメント ベースのアプリケーション用です。ドキュメントには、画像やビデオを埋め込むことができます。各画像/ビデオには、HTML ドキュメントに表示されるプレビュー画像 (サムネイル) があります。フルサイズの画像や動画はメモリにロードするのではなく、オンデマンドでロードする必要があります。

また、メモリにロードせずにリソースを追加する方法も必要です。「initWithAsset:(ALAsset *)」のようなものが理想的です。

iCloudを使用していない場合NSFileWrapper、iOSアプリケーションでスタイルパッケージを使用することに何か利点はありますか？

唯一の利点NSFileWrapperは、Finderでパッケージをダブルクリックして開くことができることです。ただし、iOSでは、Finderは存在しません。したがってNSFileWrapper、やり過ぎのようであり、コードに不要な複雑さを追加します。私は何かが足りないのですか？

Core Data File Wrapperの例に AutoSave サポートを追加しようとしています

新しい/無題のドキュメントwriteSafelyToURLがある場合、NSAutosaveElsewhereOperation タイプで呼び出されます。

悪いことに、私は両方の典型的なユースケースでこのタイプを取得します-新しいファイル：ファイルラッパーと永続ストアファイルを作成して完全な新しいドキュメントを保存します-差分を保存：ファイルラッパーが既に存在し、更新のみが必要な場合.

他の誰かがこのトピックを既に扱っていますか、または誰かが既にこれを移行しましたか?

元のサンプルでは を使用しoriginalStoreURLてこれら 2 つのユース ケースを区別していますが、どのソリューションが最適でしたか?

ありがとう

ここには、NSFileWrappers で利用できるビデオからサムネイルを生成する必要があるドキュメント ベースのアプリがあります。問題は、filewrapper からファイルの URL を取得できず、URL なしで AVURLAsset を作成できないことです。

これを行う別の方法について誰か提案がありますか? ビデオのサムネイルを作成する AVAssetImageGenerator とは異なる方法か、ファイルラッパーのデータから AVAsset を作成する方法のいずれかですか?

コンテンツを Documents ディレクトリにコピーしようとしているアーカイブがあります。シミュレーターでは正常に動作しますが、デバイスでエラーが発生して中止されます。

コンソールに次の出力が表示されます。

NSFileWrapper ドキュメントを iCloud と同期する際に問題があります。ラッパーを作成して、どこにでもあるコンテナに保存できます。

それを作成したデバイスから読み取ろうとすると、機能します。iCloud から取得した別のデバイスから読み取ろうとすると、クラッシュします。

いくつかのコード:

NSString を使用してラッパー コンテナーを追加するこの関数

}

そして、これをデコードする方法は次のとおりです。

デコード部分は 1 つのデバイスで動作し、他のデバイスでは動作しません (NSKeyedUnarchiver が NSData からアーカイブを解除しようとすると EXC_BAD_ACCESS になります。NSData は適切な長さとすべてを備えているようですが、データをログに記録しようとするとクラッシュします)。

私の推測では、NSFileWrapper はコンテンツ全体をダウンロードするのではなく、構造のみをダウンロードし、それを利用できるようにするために何かをしなければならないと思います。しかし、私は何を知りません。

何か案は？

========

編集：

NSURLUbiquitousItemIsDownloadedKey は、ファイルがダウンロードされたと言いますが、サンドボックスにコピーしようとすると、「操作を完了できませんでした。ファイル記述子が正しくありません」というエラーで失敗します。

そのため、ファイルがiCloudに正しくアップロードされていないか、正しくダウンロードされていません...

自分では解決できないような奇妙な問題があります。どんな助けや考えも大歓迎です。

問題：

• NSMetadataQueryは通常のファイル（test.txtなど）を検出しますが、ファイルラッパーバンドル（myWrapperDocument.pro）は検出しません
• ただし、NSFileManagerは、ユビキタスコンテナ内のすべてのファイルを検出します。したがって、ファイルは存在しますが、NSMetadataQueryはそれらを検出しません。

事実：

• NSFileWrappersを使用したUIDocumentベースのアプリ
• 共有ユビキタスコンテナ（iOSおよびデスクトップアプリ用）
• MacOSで完璧に動作します
• iPadMiniとiPhone4SおよびiPhone3GS（iOS6およびiOS5を実行）で完璧に動作します
• iPad1でもほとんどのベータテスターのデバイス（iOS5または6を実行しているiPad 1、2、3）でも動作しません

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

• WWDC12 UIDocumentとiCloudの例を学習しました（CloudNotes.xcodeproj）
• Appleの開発フォーラムとここで何時間も勉強しましたが、残念ながら運がありませんでした
• 多くの異なる述語をテストし、資格とドキュメントの設定を確認しました（したがって、システムは、それがフォルダーではなく、ドキュメントバンドルであることを認識します）
• ユビキタスコンテナのクリアとリセット

関連するコード：

資格は正しいはずです。Info.plistドキュメントの設定（ドキュメントタイプは正しく登録されていると思います）

ユビキタスコンテナとiCloudドキュメントのURLはすべて問題ありません。これが、クエリを設定する方法です。

本当に奇妙なことは、クエリが1つのファイル「test.txt」だけで返されるのに、他のファイルは検出されないままであるということです。ただし、ログからわかるように、コンテナには84個の.proファイル（すべて「something.pro」と呼ばれます）がありますが、クエリでは1つの「test.txt」しか見つかりません。

残念ながら、NSFileManagerを使用してこれらのファイルにアクセスすることはできません。これは、これらのファイルを読み取る権限がないように思われるためです。この問題はベータテスターのデバイスの新規インストールでも発生するため、コンテナーが破損しているとは思いませんか？

私はそれが述語だと思います、しかし：

もうどうしたらいいのかわからない。最も奇妙なことは、他のデバイスではまったく機能しないのに、一部のデバイスでは機能することです。

この問題に関するヒントをいただければ幸いです。どうもありがとう！

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