iphone - iCloud:我可以忽略那些禁用 iCloud 的人吗？

Question

我对 iCloud 的想法有点纠结，并发布了一个更一般的问题 here .我最大的问题是决定是否应该停止将用户数据放在应用程序沙箱中的旧文档文件夹中。为了说明我的问题:

docs据我所知，不要给出答案。假设我有一个处理不同 txt 文件的应用程序。启动我的应用程序后，我只需像这样检查云中是否有任何 txt 文件:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    NSLog(@"AppDelegate: app did finish launching");
    self.window = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease];

    self.window.rootViewController = self.viewController;
    [self.window makeKeyAndVisible];

    // (1) iCloud: init

    NSURL *ubiq = [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil];
    if (ubiq) {
        NSLog(@"User has iCloud enabled! Let's get the txt files from the cloud.");
        [self loadDocument];
    } else {
        NSLog(@"User doesn't have iCloud enabled. App is thus worthless.");
    }


    return YES;
}

然后我有一个方法来检查云中是否有任何 txt 文件，如果有，则加载它们。如果没有，我只需在云中创建新的 txt 文件。

这意味着该应用程序不会在文档文件夹中存储任何数据。据我所知，一切都在我设备的本地 iCloud 存储中(如果用户离线也可以访问)或在云中。所以文本文件存在于两个地方:在我的设备上和云端。

所以根本不需要在我的本地文档文件夹中存储第三份副本，对吧？还是出于某种我忽略的原因，这是必不可少的？换句话说，如果我向用户提供 iCloud，我应该使用本地文档文件夹做什么？ (我可以忽略那些不会注册 iCloud 的人吗？)

---

编辑:澄清一下，当我谈论应用程序沙盒中的标准文档文件夹时，我指的是这个:

NSArray *paths =NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
    NSString *documentsDirectory = [paths objectAtIndex:0];

Answer 1

也许我有点慢，通过第 4 次或第 5 次重新阅读文档，我发现了这一点，这表明您应该始终在沙盒中创建文件，然后将它们移动到云端。所以在某种程度上，Apple 建议始终拥有同一文件的 3 个版本:

Apps use the same technologies to manage files and directories in iCloud that they do for local files and directories. Files and directories in iCloud are still just files and directories. You can open them, create them, move them, copy them, read and write from them, delete them, or any of the other operations you might want to do. The only differences between local files and directories and iCloud files and directories is the URL you use to access them. Instead of URLs being relative to your app’s sandbox, URLs for iCloud files and directories are relative to the corresponding iCloud container directory.

To move a file or directory to iCloud:

Create the file or directory locally in your app sandbox. While in use, the file or directory must be managed by a file presenter, such as a UIDocument object.

Use the URLForUbiquityContainerIdentifier: method to retrieve a URL for the iCloud container directory in which you want to store the item. Use the container directory URL to build a new URL that specifies the item’s location in iCloud. Call the setUbiquitous:itemAtURL:destinationURL:error: method of NSFileManager to move the item to iCloud. Never call this method from your app’s main thread; doing so could block your main thread for an extended period of time or cause a deadlock with one of your app’s own file presenters. When you move a file or directory to iCloud, the system copies that item out of your app sandbox and into a private local directory so that it can be monitored by the iCloud daemon. Even though the file is no longer in your sandbox, your app still has full access to it. Although a copy of the file remains local to the current device, the file is also sent to iCloud so that it can be distributed to other devices. The iCloud daemon handles all of the work of making sure that the local copies are the same. So from the perspective of your app, the file just is in iCloud.

All changes you make to a file or directory in iCloud must be made using a file coordinator object. These changes include moving, deleting, copying, or renaming the item. The file coordinator ensures that the iCloud daemon does not change the file or directory at the same time and ensures that other interested parties are notified of the changes you make.

See here.