具有核心数据托管对象的 URL 方案 (iOS)答案

【问题标题】：URL scheme with core data managed object (iOS)具有核心数据托管对象的 URL 方案 (iOS)
【发布时间】：2013-06-05 10:41:22
【问题描述】：

我想将 URL 方案添加到我的 iOS 应用程序，但是 URL 需要能够从 Core Data 指向某个 NSManagedObject。我很高兴我的应用必须生成供用户使用的 URL，但在 URL 中使用整个 NSManagedObject URI 似乎并不正确。

当我检索托管对象的 URI 时，是这样的：

x-coredata://633EAF37-A03D-4954-976D-B3B0C32F8033/MyObject/p7

我猜我可以删除 x-coredata:// 部分，我可以将其放回我的 application:openURL 方法中，但这仍然给我留下这样的 URL：

myurlscheme://event_to_perform?object=633EAF37-A03D-4954-976D-B3B0C32F8033/MyObject/p7

我还能做些什么来缩短它吗？ 633EAF37-A03D-4954-976D-B3B0C32F8033 的 has 部分怎么样？这在安装应用程序的每台设备上都是一样的，还是独一无二的？如果跨设备相同，那么我只需要使用最终的p7 作为我可以添加回字符串的所有其他内容。

任何建议表示赞赏。

谢谢

【问题讨论】：

【解决方案1】：

也许先看看Permanent NSManagedObjectID not so permanent?，了解传递NSManagedObjectID 的脆弱性。 Marcus S. Zarra 声称 objectID 可以在对象的生命周期内改变。

话虽如此，永久托管对象 ID 的 URI 似乎总是这样构建：

x-coredata://<UUID>/<EntityName>/p<Key>

在哪里

但请注意，这只是我观察到的。格式没有记录，可能随时更改。

<UUID> 是在创建商店文件时生成的，因此在安装应用程序的每台设备上它都不相同。

所以如果上面的分析是正确的并且以后URI方案没有变化，那么您确实可以从最终组件 p<Key> 重建托管对象 URI 一个人。

【讨论】：

【解决方案2】：

这感觉就像暴露了你的实现太多了。我强烈建议您在实体中维护自己的唯一 id 属性，并在获取 URL 查找时使用它从 CoreData 获取正确的实体。

这证明了你是否应该开始同步到基于 Web 的应用版本或其他非 CoreData 的数据存储。

【讨论】：