使用[NSFileManager URLForUbiquityContainerIdentifier：]和[NSFileManager ubiquityIdentityToken]的主要区别是什么？

Question

我正在尝试为我的应用程序添加iCloud支持，并遵循苹果的 iCloud设计指南。该指南表示，我应该通过调用 [NSFileManager ubiquityIdentityToken] 来检查用户凭据。它还说，我应该检查 [NSFileManager URLForUbiquityContainerIdentifier:] 以使应用程序的普及容器可用。

我遇到的问题是，ubiquityIdentityToken 返回 nil，而 URLForUbiquityContainerIdentifier: 不是这样。因为后者返回正确的URL，所以我假设我的配置文件和权限设置正确。我还双重检查了运行应用程序的设备是否启用了iCloud，并且已经登录并启用了文档和数据。

为什么一个方法会暗示没有iCloud连接，而另一个则不是呢？

更新： 我注意到，如果我调用ubiquityIdentityToken，它会在调用URLForUbiquityContainerIdentifier:之后返回一个值。然而，如果我的应用程序使用键值存储而不是普遍容器，ubiquityIdentityToken将如何工作？

- circuitlego

Answer 1

ubiquityIdentityToken是苹果引入的新功能，允许应用程序检查用户是否已登录iCloud。这是一种极快的方式，可以在应用程序激活之间/用户实际上是否已登录等情况下找出同一用户是否已登录。

它可以在主线程上运行，并且非常快速。这将使您能够对应用逻辑做出决策。

需要注意的关键点是它可以在主线程上运行，并且非常快速。

通常情况下，您会获取此令牌，将其存储在应用程序中，然后在应用程序从后台返回时再次进行比较。

这样，您就可以确保它是相同的用户等等。

如果返回nil，则表示用户未登录iCloud。

以前要检查用户是否已登录，需要使用单独的调用，但必须异步地在另一个线程上运行。我想他们看到了这样的情况：用户已登录iCloud，暂停其应用程序，登录另一个帐户，然后回到您的应用程序。这将使您能够非常高效和轻松地检查这些事情。令牌不包含任何用户可识别信息。

- Srikanth

---

问题是我已经登录了iCloud，但该方法仍然返回nil。除非我首先调用URLForUbiquityContainerIdentifier:。这对我来说毫无意义，特别是因为我实际上不希望我的应用程序使用普及容器；它将完全依赖于NSUbiquitousKeyValueStore。 - circuitlego

好的，所以...不知怎么地，它在没有任何代码更改的情况下开始工作了 -_-。我使用不同的帐户登录和退出了iOS，然后它就可以工作了。感谢您的解释。 - circuitlego

我遇到了相同的问题，即使我正确设置了 iCloud文档 并登录了iCloud，但从 NSFileManager.defaultManager（）。ubiquityIdentityToken 返回了一个 nil，这很奇怪。 - János

请参考Weischel在stackoverflow上的回答：“与移动文档相反，应始终将键值存储库视为有效可用。” 因此，如果您仅使用iCloud的NSUbiquitousKeyValueStore，则不适用ubiquityIdentityToken。 - ObjectiveTC