ios - 如何确定 iCloud 文件夹中是否存在文件？

Question

我有一个 iOS 应用程序可以将文件存储在 iCloud 中。当我启动应用程序时，我想确定以前的设备是否已经上传了任何文件。我启动第一台设备并将文件添加到 iCloud(我可以在我的 Mac 上的移动文档文件夹中看到它们)。然后我在第二台设备上启动该应用程序并尝试使用以下 NSMetadataQuery 来查看是否已上传任何文件，但它返回 0 个结果。如果我继续运行该查询，大约 8-10 秒后它会返回结果。

iCloudQuery = [[NSMetadataQuery alloc] init];

iCloudQuery.searchScopes = @[NSMetadataQueryUbiquitousDataScope];

NSString *filePattern = [NSString stringWithFormat:@"*.%@", @"txt"];

iCloudQuery.predicate = [NSPredicate predicateWithFormat:@"%K LIKE %@", NSMetadataItemFSNameKey, filePattern];

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(iCloudQueryDidFinishGathering:) name:NSMetadataQueryDidFinishGatheringNotification object:iCloudQuery];

[iCloudQuery startQuery];

当我收到通知时，查询的结果计数为 0

- (void)iCloudQueryDidFinishGathering:(NSNotification *)notification
{    
    NSMetadataQuery *query = [notification object];
    [query disableUpdates];
    [query stopQuery];

    NSLog(@"Found %d results from metadata query", query.resultCount);
}

如果文件存在于 iCloud 中，即使尚未下载，NSMetadataQuery 不应该返回 resultCount 吗？除了尝试结束并在 15-30 秒后超时之外，是否有任何方法可以测试文件是否存在？

Answer 1

查询从 iCloud 检索元数据可能需要一些时间。 didFinishGathering 最初可能只保存设备已经知道的结果，而不是它没有机会从 iCloud 获悉的更改。

与其停止和启动您的 NSMetadataQuery，不如设置一个并通过同时注册来继续收听它:

[[NSNotificationCenter defaultCenter] addObserver:self
                                         selector:@selector(iCloudQueryDidUpdate:)
                                             name:NSMetadataQueryDidUpdateNotification
                                           object:iCloudQuery];

...并在更新进入时检索更新。因此您还需要更改 finishGathering 方法，而不是停止查询，并在最后启用更新。

您必须稍微重新考虑您的方法，以考虑到第一组结果不一定知道所有内容这一事实。更正常的情况是，NSMetadataQuery 用于监视 iCloud，期望其他设备生成的更改可以随时出现 - 而不仅仅是在应用程序启动时。

如果您需要确保拥有 iCloud 的最新元数据，我发现唯一可靠的方法(在 iOS 5 和 iOS 6 上)是注入(inject)一个小的文件到 iCloud(通常使用不同形式的名称，并使用 UUID 命名，因此保证唯一)，然后在 iCloudQueryDidUpdate: 方法中，不考虑查询结果完整直到该文件均由查询返回，并且它的元数据报告它也已上传到 iCloud。取回此信息后，您可以相当确定您已从 iCloud 收到最新的元数据。

在 iCloudQueryDidUpdate 中检查上传:使用:

int resultCount = [iCloudQuery resultCount];

for (int i = 0; i < resultCount; i++) {
  NSMetadataItem *item = [iCloudQuery resultAtIndex:i];

  BOOL isUploaded = [[item valueForAttribute:NSMetadataUbiquitousItemIsUploadedKey] boolValue];
  BOOL isDownloaded = [[item valueForAttribute:NSMetadataUbiquitousItemIsDownloadedKey] boolValue];
  NSURL *url = [item valueForAttribute:NSMetadataItemURLKey];
  BOOL documentExists = [[NSFileManager defaultManager] fileExistsAtPath:[url path]];

  // You'll need to check isUploaded against the URL of the file you injected, rather than against any other files your query returns
}

不要忘记在完成后删除注入(inject)的文件 - 否则这些文件将在您的应用程序每次启动时加载。

编辑:

我实现这些检查的方式有一个内置的延迟，一旦我把它拿出来，我发现上面的方法并不完全可靠。

我已经删除了元数据项目(在当前运行之前使用设置/iCloud/存储和备份/管理存储删除)被报告为上传和下载并存在于磁盘上，然后完整的元数据返回我的注入(inject)文件。然而，一旦注入(inject)的文件被报告为已上传、下载并存在于本地磁盘上，这些已删除的文件之一仍然在元数据中列为已上传和下载——但不存在于磁盘上。

所以看起来一直在发生的事情是 iCloud 守护程序听说了旧数据的待删除，并在您的应用程序看到的元数据更新以反射(reflect)这一点之前实际执行删除。疯了吧？因此，我必须更新我上面的建议，仅当项目被报告为已下载、已上传并且使用 [NSFileManager fileExistsAtPath:] 存在于本地文件夹中时才考虑查询结果。 方法。上面的代码经过编辑以反射(reflect)这一点。

在此之后，您所能做的就是在对查询结果采取行动之前延迟 1 秒，以绝对确保所有元数据都有时间接收 - 尽管这是我讨厌必须做的事情.在代码中加入虚假的时间延迟以使其工作对我来说感觉有点太接近黑魔法了。并且表明您并不真正了解正在发生的事情 - 尽管没有更多的钩子(Hook)进入 iCloud 背后的处理，我们还能做什么？