15

ファイルがドキュメント インタラクション システムによって iOS アプリケーションに渡されると、ファイルのコピーがアプリケーション バンドルのDocuments/Inboxフォルダに保存されます。アプリケーションがファイルを処理した後、明らかにファイルを から削除する必要があります。削除しDocuments/Inboxないと、フォルダが拡大し続け、デバイスのストレージが無駄になります。

ただし、この単純な解決策 (A) には満足できません。ファイルの処理と削除を完了する前に、アプリがユーザーとやり取りする必要があるからです。ユーザーがこの対話期間中にアプリを一時停止し、アプリがバックグラウンドにある間に強制終了された場合、次回アプリが起動したときに古いファイルは削除されません。もちろん、このシナリオをカバーするようにアプリを改善することはできますが、「汚れた」Documents/Inboxフォルダーが残る別の境界ケースが常にあると思います。

したがって、推奨される解決策 (B) はDocuments/Inbox、適切な時点でフォルダーを削除することです (たとえば、アプリが正常に起動したとき、つまりドキュメントの操作を介していないとき)。場所が公式にどこにも文書化されていないファイルシステムパスにアクセスすることになるため、これにはまだ不快です。たとえば、iOS の将来のバージョンで、ドキュメント インタラクション システムがファイルを に配置しなくなった場合、私のアプリは壊れますDocument/Inbox。

だから私の質問は：

  1. ソリューション A または B のどちらをお勧めしますか?
  2. 別のアプローチを使用していますか?アプリの管理方法の概要を教えていただけますDocument/Inboxか?
  3. 最後になりましたが、このトピックを扱っていて、私が見落としていた Apple の公式ドキュメントをご存知ですか?
4

3 に答える 3

15

この質問をしたので、次の解決策を実装しました。

  • ユーザーをまったく関与させずに、ドキュメントのやり取りを介して渡されたファイルをすぐに処理するように、アプリを再設計しました。ファイルの処理中にアプリがクラッシュしたり、一時停止して強制終了されたりしない限り、これは常にクリーンなままにする必要がありますDocuments/Inbox。
  • クラッシュまたはサスペンド/キルの (まれな) ケースをカバーするために、私のアプリはDocuments/Inbox通常の起動時にフォルダーを削除します (つまり、ドキュメントの操作を目的とせずに)。これを実現するには、Documents/Inboxフォルダー パスをハードコードする必要があります。

解決策に至った考えは次のとおりです。

  • アプリの再設計
    • 最初は、ユーザーがファイルを処理する方法を選択できるようにするのは良い考えのように思えました。結局、選択を提供すると、アプリがより柔軟になり、ユーザーにより多くの自由が与えられるのではないでしょうか?
    • その後、ドキュメントのやり取りをどのように処理するかを決定する責任をユーザーに転嫁しようとしていることに気付きました。それで、私は弾丸をかみ砕き、前もって難しい決定を下し、それから喜んでアプリにシンプルでわかりやすいドキュメント インタラクション システムを実装しました。
    • 結局のところ、ユーザー インタラクションがないということは、アプリが使いやすくなることも意味するため、開発者としての私とアプリのユーザーの両方にとって、これは win-win の状況です。
  • Documents/Inboxアプリの起動中にフォルダーを 削除する
    • アプリの起動中にフォルダーを削除することは、アプリがドキュメントのやり取りを処理する方法の本質的なDocuments/Inbox部分ではなく、単なる後付けです。
    • したがって、Apple が将来のある時点で inbox フォルダのファイルシステム パスを変更する可能性があるというリスクを冒しても構わないと思っています。起こり得る最悪の事態は、私のアプリが、クラッシュまたはサスペンド/キル シナリオからの残り物であるいくつかのファイルを蓄積し始めることです。

そして最後に、さらなる開発のためのいくつかの考え:

  • アプリがドキュメントのやり取りを処理する方法が本当に複数あることが判明した場合は、ユーザー設定を追加して、ユーザーが事前に決定を下す必要があり、アプリがその操作を停止する必要がないようにします。ユーザーに選択を求める処理。
  • ドキュメント インタラクション処理プロセスの途中でユーザー インタラクションが絶対に避けられないことが判明した場合は、次のアプローチを検討します。1) ユーザーがインタラクションを許可される前に、ファイルDocuments/Inboxを何らかの「ステージング」フォルダに移動します。 ; 2) ユーザーとのやり取りをさせます。3) ユーザーが選択した方法で、「staging」フォルダー内のファイルを処理します。ここで重要なことは、「ステージング」フォルダーが既知の場所にあり、アプリによって完全に管理されていることです。ユーザーがユーザー インタラクション ステップの途中でアプリを一時停止して強制終了した場合、次にアプリを起動するときに適切なアクションを簡単に実行できます。

編集

Documents/InboxiOS 7 では、一度作成すると削除できなくなりました。このNSFileManagerメソッドは、 removeItemAtPath:error:Cocoa エラー 513 を返します。このエラーは解決されます(この Foundation 定数のリストをNSFileWriteNoPermissionError参照)。このエラーは POSIX パーミッションに関連しているようには見えませんが、システム自体が削除の試みを妨害しているように見えます (おそらくアプリ バンドル構造の保護?)。

また注目に値するのは、最近では AppleがメソッドDocuments/Inboxのドキュメントで明示的に名前を付けていることです。彼らはまた言いますUIApplicationDelegateapplication:openURL:sourceApplication:annotation:

[...] あなたのアプリには、このディレクトリ内のファイルを読み取り、削除する権限がありますが、それらに書き込む権限がありません。ファイルを変更する場合は、最初に別のディレクトリに移動する必要があります。

docsには、ファイルの暗号化の可能性に関する詳細が記載されていますが、それについては自分で読む必要があります。

于 2013-06-29T17:37:53.610 に答える