在iOS 8中将应用无处不在的容器暴露给iCloud Drive [英] Exposing an app's ubiquitous container to iCloud Drive in iOS 8

问题描述

我正在开发一个支持iCloud的应用程序，用户可以通过iCloud Drive导入和导出文件。浏览iCloud Drive时，使用 UIDocumentPickerViewController （iOS 8）或Finder（OS X Yosemite），我可以看到其他支持iCloud-Drive的应用程序创建/拥有的目录，例如，Automator，Keynote或TextEdit。

I'm developing an iCloud-enabled app where users will be able to import and export files via iCloud Drive. When browsing iCloud Drive, either using the UIDocumentPickerViewController (iOS 8) or the Finder (OS X Yosemite), I can see directories created/owned by other iCloud-Drive-enabled apps, such as, Automator, Keynote, or TextEdit.

我希望我们的应用程序也能在iCloud Drive中公开其无处不在的文档目录，但是无法想象它还没出来。在上述某些应用程序的 Info.plist 文件中，我发现了这个密钥：

I want our app to expose its ubiquitous documents directory in iCloud Drive, too, but haven't been able to figure it out yet. Within some of the aforementioned apps' Info.plist files, I've discovered this key:

<key>NSUbiquitousContainers</key>
<dict>
    <key>com.apple.TextEdit</key>
    <dict>
        <key>NSUbiquitousContainerIsDocumentScopePublic</key>
        <true/>
        <key>NSUbiquitousContainerSupportedFolderLevels</key>
        <string>Any</string>
    </dict>
</dict>

这些密钥也记录在案在哪里，但我还没有找到更广泛的其他文档学科。 编辑/注意：虽然它不包含我的问题的答案，但文档选择器编程指南是一个有用的资源。

These keys are also documented here, but I haven't found any other documentation on the broader subject. Edit/Note: Although it does not contain the answer to my questions, the Document Picker Programming Guide is a helpful resource.

我已经尝试将上述键/值添加到我们的应用程序，但没有看到任何影响。我注意到/尝试过的事情：

I've tried adding the above-mentioned keys/values to our app but didn't see any effect. Things I've noticed/tried:

• 对于第三方应用程序，iCloud容器以这种方式构建：的iCloud $（CFBundleIdentifier）。我不确定为什么TextEdit只使用纯包标识符，但对于我们的标识符，我尝试了两种方法，即使用和不使用 iCloud。前缀。我还认识到你需要对包标识符进行硬编码（即，不要使用 iCloud。$（CFBundleIdentifier）），因为只有PLIST的值似乎是在构建时解决，但不是密钥。

• For 3rd party apps, iCloud containers are constructed this way: iCloud.$(CFBundleIdentifier). I'm not sure why TextEdit only uses the pure bundle identifier, but for our identifier, I've tried both approaches, i.e., with and without the iCloud. prefix. I've also recognised that you need to hard-code the bundle identifier (i.e., don't use iCloud.$(CFBundleIdentifier)) as only the PLIST's values seem to be resolved at build time, but not the keys.

我已经以编程方式添加了一个子目录（到< containerPath> /文件）所以容器不是空的。但是，这并不重要，因为所有其他应用程序的目录最初都是空的。

I've added a sub-directory programmatically (to <containerPath>/Documents) so the container is not empty. However, this shouldn't matter as all the other apps' directories were initially empty, too.

出现在iCloud Drive中的一些Apple应用程序没有这些 Info.plist 中的条目，例如，数字和页面。

Some Apple apps that appear in iCloud Drive do not have these entries in their Info.plist, e.g., Numbers and Pages.

iCloud设置正确且我可以使用 [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier：nil]; 返回的URL以编程方式查看ubiquity容器。

iCloud is set up correctly and I can programmatically look into the ubiquity container using the URL returned by [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil];.

我已登录到启用了iCloud Drive的iCloud帐户。我可以在 UIDocumentPickerViewController 中看到我的iCloud Drive内容。

I am logged into an iCloud account where iCloud Drive is enabled. I can see my iCloud Drive content in the UIDocumentPickerViewController.

我使用iOS 8 beta 5模拟器（以及Yosemite beta 5查看Mac上的iCloud Drive目录）（编辑/注释：这同样适用于测试版6）

I use the iOS 8 beta 5 simulator (and Yosemite beta 5 to view the iCloud Drive directory on the Mac) (Edit/Note: This equally applies to beta 6)

这是我的Entitlements文件的样子（仅限相关部分）

This is how my Entitlements file looks like (relevant parts only)

<key>com.apple.developer.icloud-container-identifiers</key>
<array>
    <string>iCloud.$(CFBundleIdentifier)</string>
</array>
<key>com.apple.developer.icloud-services</key>
<array>
    <string>CloudDocuments</string>
</array>
<key>com.apple.developer.ubiquity-container-identifiers</key>
<array/>

我已在功能部分使用Xcode的UI进行设置。我不明白为什么最后一个键没有条目，但添加< string> iCloud。$（CFBundleIdentifier）< / string> 没有帮助。相反，它使Xcode在Capabilities UI中抱怨，所以我删除了它。 编辑/注意：在Xcode beta 6中，这已经修复，即需要设置无处不在的容器标识符，Xcode可以为您解决这个问题。

I've set this up using Xcode's UI in the Capabilities section. I don't get why the last key doesn't have an entry, but adding <string>iCloud.$(CFBundleIdentifier)</string> doesn't help. Instead, it makes Xcode complain in the Capabilities UI, so I've removed it. Edit/Note: In Xcode beta 6, this has been fixed, i.e., the ubiquity container identifier needs to be set and Xcode can fix that for you.

原始问题：所以......这是一个错误吗？它不起作用吗？我做错了吗？我在发行说明中找不到已知问题。

Original Questions: So... is it a bug? Does it not work yet? Am I doing it wrong? I couldn't find a known issue in the release notes.

修改：

我尝试了两件事：

• 添加（可选） NSUbiquitousContainerName 特定于容器的字典的键（+值），如Erikmitk所建议。

• Adding the (optional) NSUbiquitousContainerName key (+ value) to the container-specific dictionary, as suggested by Erikmitk.

仅添加 NSUbiquitousContainerIsDocumentScopePublic PLIST根词典的键/值而不是容器特定的词典，因为它是在 WWDC示例应用（寻找NewBox）。

Adding only the NSUbiquitousContainerIsDocumentScopePublic key/value to the PLIST root dictionary rather than the container-specific dictionary, as it's done in one of the WWDC sample apps (look for NewBox).

推荐答案

问题是调用 [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier：nil]; （或另一个容器标识符，如果它不是默认容器标识符）至少调用一次（不是每次启动，但可能是每个版本，或者当更改其中一个相应的PLIST条目时）初始化目录。我认为这一步需要与捆绑版本号的增加相结合，如roop的回答所示。

The catch is to call [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil]; (or with another container identifier if it's not the default one) at least once (not per launch, but presumably per version, or when changing one of the respective PLIST entries) in order to initialize the directory. I reckon this step needs to be combined with an increase of the bundle version number, as suggested in roop's answer.

我注意到我的问题可能在这方面令人困惑，正如我所提到的那样，能够使用相关API以编程方式查看文档目录。但是，我稍后从应用程序中删除了该代码，可能在正确设置其余部分之前。我不会直接写入文档目录，只能通过文档选择器。因此，没有必要获取URL。

I notice my question may have been confusing in that respect, as I mentioned being able to look into the documents directory* programmatically using the API in question. However, I removed that code from the app later, maybe before getting the rest of the setup right. I'm not going to write into the documents directory directly, only through the Document Picker. Therefore, there hasn't been any need to get the URL.

如果您只需要一个文档选择器来读取/存储iCloud Drive或其他应用程序中的文件文档目录，无需调用 URLForUbiquityContainerIdentifier：。只有当您希望您的应用程序拥有自己的普遍容器（并可能在iCloud Drive和文档选择器中公开）时，原始帖子中提到的步骤以及对 URLForUbiquityContainerIdentifier的调用：是必要的。

If you just need a Document Picker to read/store files from/in iCloud Drive or other apps' document directories, there's no need to call URLForUbiquityContainerIdentifier:. Only if you want your app to have its own ubiquity container (and potentially expose it in iCloud Drive and the Document Picker), the steps mentioned in the original post and the call to URLForUbiquityContainerIdentifier: are necessary.

*当提到文件目录时，我总是指的是普遍容器中的那个，而不是本地容器。

*When mentioning the documents directory, I'm always referring to the one in the ubiquity container, not the local one.

这篇关于在iOS 8中将应用无处不在的容器暴露给iCloud Drive的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！