问题标签 [nsfilewrapper]

我使用 AudioToolBox 框架中的 ExtAudioFileCreateWithURL 和 ExtAudioFileWrite 将我的样本保存到文件中。但现在我需要将它保存到 NSFileWrapper，因为我现在使用的是 NSDocument：

有什么方法可以将 ExtAudioFileXXX 函数与 NSMutableData 对象一起使用，以便我可以使用 NSFileWrapperinitRegularFileWithContents:(NSData*)contents方法？

剥离代码以保存到文件（有效）：

假设我有一个NSFileWrapper目录。该目录由多级目录和文件组成。有些文件很大。所有这些文件都加载到内存中，还是延迟加载？

如果它们被加载到内存中，是否有NSFileWrapper类似功能的替代方法不会将文件加载到内存中？我可以挂钩的东西UIDocument？

这适用于基于文档的应用程序，它使用UIDocument与 iCloud 同步的 's。文档中可以嵌入图像和视频。每个图像/视频都有一个预览图像（缩略图），显示在 HTML 文档中。不应将完整尺寸的图像或视频加载到内存中，而应按需加载。

我还需要一种方法来添加资源而不将其加载到内存中。像“initWithAsset:(ALAsset *)”这样的东西是理想的。

如果不使用 iCloud，NSFileWrapper在 iOS 应用程序中使用样式包有什么好处吗？

似乎唯一的好处NSFileWrapper是您可以在Finder中双击该包以将其打开。但是，在 iOS 上，Finder 不存在。所以NSFileWrapper看起来有点矫枉过正，并且给代码增加了不必要的复杂性。我错过了什么吗？

我尝试将 AutoSave 支持添加到Core Data File Wrapper 示例

现在，如果我有一个writeSafelyToURL使用 NSAutosaveElsewhereOperation 类型调用的新/无标题文档。

不好的是，我在两个典型用例中都得到了这种类型 - 新文件：它通过创建文件包装器和持久存储文件来存储一个完整的新文档 - 保存差异：文件包装器已经存在并且只需要更新.

其他人是否已经处理过这个主题或者是否有人已经迁移了这个？

原始示例使用originalStoreURL来区分这两个用例，哪种解决方案最适合您？

谢谢

我在这里有一个基于文档的应用程序，我需要从 NSFileWrappers 中可用的视频生成缩略图。问题是我无法从文件包装器中获取文件 URL，而且我似乎无法创建没有 URL 的 AVURLAsset。

有人对这样做的替代方法有任何建议吗？与 AVAssetImageGenerator 创建视频缩略图的方式不同，还是从文件包装器中的数据创建 AVAsset 的某种方式？

我有一个存档，我正在尝试将其内容复制到 Documents 目录中。它在模拟器中运行良好，但在设备上出现错误时中止。

我在控制台中得到以下输出：

我在将 NSFileWrapper 文档与 iCloud 同步时遇到问题。我能够创建我的包装器并将其保存到我无处不在的容器中。

当我尝试从创建它的设备中读取它时，它可以工作。当我尝试从另一个从 iCloud 获取它的设备上读取时，它崩溃了。

一些代码：

这个函数添加一个带有 NSString 的包装容器

}

然后是我如何解码它：

解码部分适用于一台设备，而不适用于其他设备（当 NSKeyedUnarchiver 尝试从 NSData 取消存档时，EXC_BAD_ACCESS。NSData 看起来不错，它具有适当的长度和所有内容，但是当我尝试记录其数据时，例如它崩溃）。

我的猜测是 NSFileWrapper 不下载它的全部内容，只下载它的结构，我必须做一些事情才能使它可用。但我不知道是什么。

有任何想法吗？

========

编辑：

NSURLUbiquitousItemIsDownloadedKey 说文件已下载，但如果我尝试将其复制到沙箱，则会失败并出现以下错误：“操作无法完成。文件描述符错误”

所以文件要么没有正确上传到 iCloud，要么没有正确下载......

我有一个奇怪的问题，我似乎无法自己解决。任何帮助或想法表示赞赏。

问题：

• NSMetadataQuery 找到普通文件（如 test.txt）但没有文件包装器包（myWrapperDocument.pro）
• 但是，NSFileManager 会在我的 ubiquity 容器中找到所有文件——所以这些文件都在那里，但 NSMetadataQuery 没有找到它们！

事实：

• 使用 NSFileWrappers 的基于 UIDocument 的应用程序
• Shared Ubiquity Container（适用于 iOS 和桌面应用程序）
• 在 Mac OS 上完美运行
• 在我的 iPad Mini 和我的 iPhone 4S 和 iPhone 3GS 上完美运行（运行 iOS6 和 iOS5）
• 不适用于我的 iPad1，也不适用于我的大多数 beta 测试设备（运行 iOS5 或 6 的 iPad 1、2 和 3）

到目前为止我做了什么：

• 学习了 WWDC12 UIDocument 和 iCloud 示例 (CloudNotes.xcodeproj)
• 在 Apple 的开发论坛和这里学习了几个小时，不幸的是没有任何运气
• 测试了许多不同的谓词，检查了权利和文档设置（因此系统知道它不是文件夹，而是文档包）
• 清除和重置 Ubiquity 容器

相关代码：

权利应该是正确的；Info.plist 文档设置（我认为文档类型已正确注册）

ubiquity 容器和 iCloud 文档 url 都很好，这就是我设置查询的方式：

真正奇怪的是，查询只返回一个文件“test.txt”，而其他文件仍未被发现。但是从日志中可以看到，容器有 84 个 .pro 文件（都称为“something.pro”），但查询只找到了一个“test.txt”。

不幸的是，使用 NSFileManager 访问这些文件不是一种选择，因为我似乎无权阅读这些文件。我认为我的容器没有损坏，因为这个问题也发生在我的 beta 测试设备的全新安装上？

我认为这是谓词，但是：

我真的不知道该怎么办了。最奇怪的是，它可以在某些设备上工作，而在其他设备上根本不工作。

我将非常感谢有关此问题的任何提示。非常感谢！

我有一个UIDocument基于 s 的应用程序NSFileWrapper来存储数据。“主”文件包装器包含许多附加的目录文件包装器，每一个都代表文档的不同页面。

当保存一个只修改了一小部分页面的大型文档UIDocument时，会在后台花费很长时间来编写更改（在 中writeContents:andAttributes:safelyToURL:forSaveOperation:error:）。当然，它应该只写出对文件包装器的这一小改动……什么花了这么长时间？

我的contentsForType:error:覆盖返回一个新的目录文件包装器，其中包含主文件包装器的内容（à la WWDC 2012 Session 218 - Using iCloud with UIDocument）：

这是来自 Time Profiler 的堆栈跟踪的可爱图片：

顺便说一句，它说要在该工作线程中保存约 1.6 秒 - 在实际运行时间中，这相当于大约 8 秒。

编辑：

有什么方法可以检查文件包装器是否需要写入磁盘？只是这样我可以确认我没有做一些奇怪的事情，比如当我做一个小改动时更新每个子文件包装器（尽管我确定我不是......）。

编辑：

我进一步玩了 CloudNotes 示例应用程序，似乎NSFileWrapper 确实实现了增量保存，至少在这种情况下是这样！我通过初始化一个包含 100 个注释的文档来测试它，每个注释包含大约 5MB 的数据。我在这里和那里做了一个小编辑（文本视图的单个字符更改将文档标记为需要保存），并大致记录了每次保存所用的时间。测试比较粗糙（在模拟器上运行），但结果是这样的：

• 第一次写入：~8000ms
• 第二次写入：~4000ms
• 第三次写入：~300ms
• 所有后续写入：~40ms

显然有很多因素会影响它所花费的时间，特别是因为它在后台线程中使用文件协调来节省，但总的来说，趋势似乎总是这种指数衰减，直到所有写入都变得非常快。

但我仍在试图弄清楚为什么这不会在我的应用程序中发生。对于一个大的多页文档（很大，但仍然比我上面执行的 CloudNotes 测试的文档小很多倍），用户可能要等待很多秒才能关闭文档。我不想为应该几乎是即时的事情设置一个微调器。

我有一个UIDocument基于 s 的应用程序NSFileWrapper来存储数据。“主”文件包装器包含许多附加的目录文件包装器，每一个都代表文档的不同页面。

UIDocument每当我在保存（在）时对文档进行更改时writeContents:andAttributes:safelyToURL:forSaveOperation:error:，应用程序就会崩溃。这是堆栈跟踪：

很明显，我正在修改UIDocument在后台枚举的文件包装器的同一实例。实际上，我检查了在返回数据模型的快照时contentsForType:error:，返回的子文件包装器指向与数据模型中当前驻留（和正在编辑）的对象相同的对象，而不是副本。

这是实施此方法的认可方法（根据WWDC 2012 Session 218 - Using iCloud with UIDocument）。

所以我想问题是：这种方法如何是线程安全的？

当主文件包装器fileWrappers本身是目录文件包装器时，情况是否有所不同？如果制裁的方法是错误的，应该怎么做？