在iOS应用中管理Documents/Inbox文件夹的好方法 [英] Good way to manage the Documents/Inbox folder in an iOS app

问题描述

当文档交互系统将文件传递到iOS应用程序时，该文件的副本存储在应用程序捆绑包的Documents/Inbox文件夹中.应用程序处理完文件后，显然需要从Documents/Inbox中删除文件，否则文件夹将继续增长并浪费设备上的存储空间.

When a file is passed into an iOS application by the document interaction system, a copy of the file is stored in the application bundle's Documents/Inbox folder. After the application has processed the file, it obviously needs to remove the file from Documents/Inbox, otherwise the folder will continue to grow and waste storage on the device.

但是，我对这个简单的解决方案(A)感到不满意，因为我的应用需要与用户进行交互才能完成处理和删除文件的操作.如果用户在此交互期间暂停了该应用程序，并且随后在后台运行该应用程序，则该应用程序被杀死，下次该应用程序启动时，过时的文件将不会被删除.当然，我可以改进我的应用程序以适应这种情况，但是我怀疑总会有其他情况使我的文件夹"Documents/Inbox不干净".

I am uncomfortable with this simple solution (A), however, because my app needs to interact with the user before it can finish processing and removing the file. If the user suspends the app during this interaction period, and the app then gets killed while it is in the background, the stale file will not be removed when the app starts up the next time. Of course I can improve my app to cover this scenario, but I suspect that there will always be another border case that will leave me with an "unclean" Documents/Inbox folder.

因此，一个更好的解决方案(B)是在适当的时间(例如，当应用正常启动时，即不通过文档交互)删除Documents/Inbox文件夹.我对此仍然感到不舒服，因为我将访问一个文件系统路径，该路径的位置未在任何地方得到正式记录.例如，如果在将来的iOS版本中文档交互系统不再将文件放置在中，则我的应用程序将崩溃.

A preferrable solution (B) therefore would be to remove the Documents/Inbox folder at an appropriate time (e.g. when the app launches normally, i.e. not via document interaction). I am still uncomfortable with this because I would be accessing a filesystem path whose location is not officially documented anywhere. For instance, my app would break if in a future version of iOS the document interaction system no longer places files in Document/Inbox.

所以我的问题是:

1. 您会推荐解决方案A还是B?
2. 您使用其他方法吗?您能否概述应用程序如何管理Document/Inbox?
3. 最后但并非最不重要:您是否知道涵盖该主题且我忽略了的Apple官方文档?

推荐答案

自从我问了这个问题以来，我已经实现了以下解决方案:

Since I have asked this question, I have implemented the following solution:

• 我已经重新设计了我的应用程序，以便它现在可以立即处理通过文档交互传递给它的文件，而无需用户参与.除非应用程序在处理文件的过程中崩溃或被挂起并杀死，否则应该始终为我提供一个干净的Documents/Inbox.
• 为了解决崩溃或暂停/死机的罕见情况，我的应用在正常启动时会删除Documents/Inbox文件夹(即，无需文档交互的目的).为此，必须对Documents/Inbox文件夹路径进行硬编码.

• I have redesigned my app so that it now immediately processes a file handed over to it via documentation interaction, without involving the user at all. Unless the app crashes, or is suspended and killed, in the middle of processing the file, this should always leave me with a clean Documents/Inbox.
• To cover the (rare) case of a crash or suspend/kill, my app removes the Documents/Inbox folder when it is launched normallly (i.e. without the purpose of document interaction). To achieve this the Documents/Inbox folder path is necessarily hardcoded.

以下是解决方案的想法:

Here are the thoughts that went into the solution:

• 重新设计应用程序
  • 最初，向用户提供选择她希望如何处理文件的想法似乎是一个好主意-毕竟，提供选择将使应用程序更加灵活，并为用户提供更多的自由，对吗?
  • 然后我意识到我正在尝试将决定如何处理文档交互的责任转移给用户.因此，我忍无可忍，做出了艰难的决定，然后高兴地继续在我的应用程序中实现了一个简单而直接的文档交互系统.
  • 事实证明，没有用户交互也意味着该应用程序更易于使用，因此对于我(作为开发人员)和我的应用程序用户来说，这都是双赢的情况.
  • Redesigning the app
    • Initially it seemed like a good idea to offer the user a choice how she wanted a file to be processed - after all, offering a choice would make the app more flexible and provide the user with more freedom, right?
    • I then realized that I was trying to shift the responsibility for deciding how document interaction should be handled to the user. So I bit the bullet, made the hard decisions up-front, and then went happily on to implement a simple and straightforward document interaction system in my app.
    • As it turns out, no user interaction also means that the app is easier to use, so here's a win-win situation, both for me as a developer and for the users of my app.
    • 在应用启动过程中删除Documents/Inbox文件夹只是事后的想法，而不是我的应用处理文档交互方式的必不可少的部分
    • 因此，我非常乐意冒险在将来的某个时候Apple可能更改收件箱文件夹的文件系统路径.可能发生的最糟糕的事情是，我的应用程序将开始累积一些崩溃或暂停/杀死情况下遗留下来的文件.
    • Removing the Documents/Inbox folder during app launch is just an afterthought, not an essential part of how my app handles document interaction
    • Therefore I am quite willing to take the risk that Apple might change the filesystem path of the inbox folder at some point in the future. The worst thing that can happen is that my app will start to accumulate a few files that are leftovers from crash or suspend/kill scenarios.

    最后，有一些进一步发展的想法:

    And finally, a few thoughts for further development:

    • 如果事实证明真的应该有多种方法可以处理应用程序与文档的交互，那么我将添加用户首选项，以便用户必须事先做出决定，并且该应用无需停止处理即可要求用户选择.
    • 如果事实证明在文档交互处理过程中绝对无法避免用户交互，我会考虑以下方法:1)在允许用户交互之前，将文件从Documents/Inbox移至某个位置某种暂存"文件夹； 2)让用户进行互动； 3)以用户选择的任何方式处理"staging"文件夹中的文件.这里重要的是，"staging"文件夹位于已知位置，并且完全由应用程序管理.如果用户在用户交互步骤的中间暂停并终止了该应用程序，则下次启动该应用程序时只需采取适当的措施即可.
    • If it ever turns out that there really should be more than one way how the app can handle document interaction, I would add a user preference so that the user has to make a decision up-front, and the app does not need to stop its processing to ask the user for a choice.
    • If it ever turns out that user interaction is absolutely unavoidable in the middle of the document interaction handling process, I would look at this approach: 1) Before the user is allowed to interact, move the file from Documents/Inbox to some sort of "staging" folder; 2) Let user interaction take place; 3) Process the file in the "staging" folder, in whatever way the user chose. The important thing here is that the "staging" folder is in a known location and is completely managed by the app. Should the user suspend and then kill the app in the middle of the user interaction step, an appropriate action can simply be taken when the app is launched for the next time.

    编辑

    在iOS 7中，一旦创建Documents/Inbox，便不再可能删除它. NSFileManager方法removeItemAtPath:error:返回可可错误513，该错误解决为NSFileWriteNoPermissionError(请参阅

    In iOS 7 it is no longer possible to remove Documents/Inbox once it has been created. The NSFileManager method removeItemAtPath:error: returns Cocoa error 513 which resolves to NSFileWriteNoPermissionError (cf. this list of Foundation constants). The error does not seem to be related to POSIX permissions, however, it rather looks as if the system itself interferes with the attempt at deletion (possibly protection of the app bundle structure?).

    还值得注意的是，如今，Apple在UIApplicationDelegate方法application:openURL:sourceApplication:annotation:的文档中明确命名了Documents/Inbox.他们还说

    Also noteworthy is that nowadays Apple explicitly names Documents/Inbox in the documentation of the UIApplicationDelegate method application:openURL:sourceApplication:annotation:. They also say that

    [...]您的应用有权读取和删除此目录中的文件，但无权对其进行写入.如果要修改文件，则必须先将其移动到其他目录.

    [...] Your app has permission to read and delete files in this directory but does not have permission to write to them. If you want to modify a file, you must move it to a different directory first.

    文档中还有更多关于文件可能加密的内容，但您应该自己阅读.

    There is more stuff about possible encryption of the files in the docs, but you should read up on that yourself.

    这篇关于在iOS应用中管理Documents/Inbox文件夹的好方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！