iCloud - 重命名另一台设备上打开的文档有时会失败
问题:我正在设备 A(例如 iPod Touch)上处理 iCloud 文档。然后我更改设备 B 上的文档名称,例如我的 Mac(通过 Finder)。更改会上传到云端,暂停后设备 A 就会听到它。
然后:有时
- 一切都很好 - 我通过更改的
fileURL
属性来更改名称,并可以相应地更新我的界面 - 文档的行为继续与 - 某些此时,文档的 fileURL 返回如下所示:
file://localhost/var/mobile/Library/Mobile%20Documents/.ubd/peer-43A0AEB6-84CE-283E-CA39-FCC4EF3BC8F8-v23/ftr/purg-012fdcfbe3b3bbce6e603fdfd2f000b2cb28649e95
毫不奇怪,这个文件获胜't 节省。
谁能解释一下发生了什么以及如何解决它?
背景
NSMetadataQuery
可以很好地识别名称更改。例如,我可以重命名未打开的文档,并且我的所有 iCloud 功能都可以正常工作。该问题似乎仅在打开文档时发生。其他 iCloud 功能运行良好,例如,我可以更改一台设备(例如我的 Mac)上的内容,并检测并更新另一台设备(例如我的 iPod Touch)上打开了相关 iCloud 文档的界面。
当我向 UIDocument 子类添加
presentedItemDidMoveToURL:
的重写时,我第一次发现了这一点。覆盖可以可靠地获取在云中进行的名称更改,例如在另一台设备上重命名文档。然后有时 newURL 是重命名文档的最终预期 URL,即我可以使用“lastPathComponent”从中提取新名称、更新我的界面等的合理内容。在其他情况下,newURL 是某些中的文档最后一个路径组件以“purg-”开头的其他目录,例如purg-012fdcfbe3b3bbce6e603fdfd2f000b2cb28649e95。- (void)presentedItemDidMoveToURL:(NSURL *)newURL; { [超级presentedItemDidMoveToURL:newURL]; if ([(id)[self delegate] respondsToSelector:@selector(documentNameChanged:)]) { [[self delegate] documentNameChanged: self]; } }
presentedItemDidMoveToURL:
方法似乎不是问题的根本原因。例如,如果我根本不重写该方法,而是定期检查正在查看打开文档的 viewController,则重命名后fileURL
将返回有时新名称,有时它会返回“purg-.....”。因此,问题似乎与重命名的处理方式有关。
更新
正如 al_lea 指出的,这里的问题与 accommodatePresentedItemDeletionWithCompletionHandler: 有关。扩展 al_lea 的答案,我将下面的代码添加到我的 UIDocument 子类中。这解决了这个问题。
- (void) accommodatePresentedItemDeletionWithCompletionHandler: (void (^) (NSError *errorOrNil)) completionHandler
{
PresentedDocument* presentedDocument = [self retain];
[presentedDocument closeWithCompletionHandler: ^(BOOL success) {
NSError* error = nil;
if (!success)
{
NSDictionary* userInfo = [NSDictionary dictionaryWithObjectsAndKeys:
@"Could not close document that is being deleted on another device",
NSLocalizedDescriptionKey, nil];
error = [NSError errorWithDomain: @"some_suitable_domain"
code: 101
userInfo: userInfo];
}
completionHandler(error); // run the passed in completion handler (required)
dispatch_async(dispatch_get_main_queue(), ^
{
[[NSNotificationCenter defaultCenter] postNotificationName: NOTIFY_presentedDocumentDeletedOnAnotherDevice
object: presentedDocument
userInfo: nil];
[presentedDocument tidyUpAfterDelete]; // app specific tidy up
[presentedDocument release];
});
}];
}
有了此代码,就不会有虚假和令人困惑的presentedItemDidMoveToURL: 调用,此外,相关对象可以侦听其他设备上的删除通知。
The issue: I'm working on an iCloud document on device A, e.g. iPod Touch. Then I change the name of the document on device B, e.g. my Mac (via the Finder). The change goes up to the cloud and after a pause device A gets to hear about it.
And then:
- some of the time all is just fine - I pick up the change of name via a changed
fileURL
property and can update my interface accordingly - the document continues to behave just as it should - some of the time, the document's fileURL is returned as something such as:
file://localhost/var/mobile/Library/Mobile%20Documents/.ubd/peer-43A0AEB6-84CE-283E-CA39-FCC4EF3BC8F8-v23/ftr/purg-012fdcfbe3b3bbce6e603fdfd2f000b2cb28649e95
Not surprisingly this file won't save.
Can anyone explain what is going on and how to work around it?
Background
The name change is picked up fine by by
NSMetadataQuery
. So, for e.g., I can rename documents that are not open and all my iCloud functionality works fine. The issue only seems to occur with open documents.Other iCloud features are working fine, e.g. I can change content on one device, e.g. my Mac, and detect and then update my interface on another device, e.g. my iPod Touch, that has the relevant iCloud document open.
I first spotted this when I added an override for
presentedItemDidMoveToURL:
to my UIDocument subclass. The override reliably picks up name changes made in the cloud, e.g. renaming the document on another device. Then sometimes newURL is the final expected URL for the renamed document, i.e. something sensible from which I can extract the new name use `lastPathComponent', update my interface etc. On other occasions newURL is a document in some other directory with a last path component beginning 'purg-', e.g. purg-012fdcfbe3b3bbce6e603fdfd2f000b2cb28649e95.- (void) presentedItemDidMoveToURL:(NSURL *) newURL; { [super presentedItemDidMoveToURL: newURL]; if ([(id)[self delegate] respondsToSelector:@selector(documentNameChanged:)]) { [[self delegate] documentNameChanged: self]; } }
The
presentedItemDidMoveToURL:
method does not seem to be the root cause of the problem. For example, if I don't override that method at all, but periodically check in the viewController that is looking after the open document, then sometimes after a renamefileURL
will return the new name and sometimes it will return `purg-.....'. So the issue appears to be to do with how renaming is handled.
Update
As al_lea pointed out, the issue here was related to accommodatePresentedItemDeletionWithCompletionHandler:
. Expanding on al_lea's answer, I added the code below to my UIDocument subclass. This fixed the issue.
- (void) accommodatePresentedItemDeletionWithCompletionHandler: (void (^) (NSError *errorOrNil)) completionHandler
{
PresentedDocument* presentedDocument = [self retain];
[presentedDocument closeWithCompletionHandler: ^(BOOL success) {
NSError* error = nil;
if (!success)
{
NSDictionary* userInfo = [NSDictionary dictionaryWithObjectsAndKeys:
@"Could not close document that is being deleted on another device",
NSLocalizedDescriptionKey, nil];
error = [NSError errorWithDomain: @"some_suitable_domain"
code: 101
userInfo: userInfo];
}
completionHandler(error); // run the passed in completion handler (required)
dispatch_async(dispatch_get_main_queue(), ^
{
[[NSNotificationCenter defaultCenter] postNotificationName: NOTIFY_presentedDocumentDeletedOnAnotherDevice
object: presentedDocument
userInfo: nil];
[presentedDocument tidyUpAfterDelete]; // app specific tidy up
[presentedDocument release];
});
}];
}
With this code in place, there are no spurious and confusing presentedItemDidMoveToURL: calls made and, in addition, the relevant object can listen for notifications of deletions on other devices.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
当 UIDocument 在本地打开并从远程设备中删除时,会出现这种类型的 URL:
file://localhost/var/mobile/Library/Mobile%20Documents/.ubd/peer-43A0AEB6-84CE-283E- CA39-FCC4EF3BC8F8-v23/ftr/purg-
您需要在删除文档之前先关闭文档 - 在中检测到这一点NSFilePresenter 的accommodatePresentedItemDeletionWithCompletionHandler:
This type of URL appears when a UIDocument is opened on local and get deleted from a remote device:
file://localhost/var/mobile/Library/Mobile%20Documents/.ubd/peer-43A0AEB6-84CE-283E-CA39-FCC4EF3BC8F8-v23/ftr/purg-
You need to close the document first before it get deleted - detect this in NSFilePresenter's
accommodatePresentedItemDeletionWithCompletionHandler: