具有自动保存和自动保存功能的鞋盒/库应用程序OS X Lion 中的版本
我们有一个鞋盒式的应用程序，我们希望使其成为 Lion 中的一等公民。这意味着集成自动保存和自动保存功能。版本等等。目前我们没有以文档为中心的模型，我们只使用普通的核心数据堆栈。
UIPersistentDocument 提供了一种非常简单的方法来集成自动保存和自动保存。版本，我看到我们可以选择与新 API 集成的两个选项：
- “滥用”NSPersistentDocument 用于我们的鞋盒式应用程序。从技术上讲，它将是一个基于文档的应用程序，但用户界面仍然是相同的类似 iPhoto 的库。这在概念上没有多大意义，但我们可以免费获得很多功能。
- 保留当前的普通核心数据堆栈并实现自动保存和自动保存。手动版本。
我听到苹果代表对我们应该采取的方法提出了相互矛盾的意见，在我们开始实施之前澄清一些事情会很好。虽然我认为 1. 不应该被使用，但它也非常诱人，因为我们可以免费获得很多东西。我什至找不到足够的文档来手动实现自动保存和自动保存。核心数据应用程序中的版本。
我确实倾向于使用 1. 但我看到了一些问题：
- 我担心使用版本和仅一个数据库文件时会出现文件系统级冲突。我找不到有关此主题的任何文档。
- 我担心浏览“空间”时版本中的性能问题。
- 我们不能强制只打开一个数据库实例，因为版本必须打开多个实例。我担心副作用和并发问题。 从概念上讲，它看起来像黑客，但我不喜欢黑客。
如果我们只想集成 iCloud 同步，我绝对不会考虑为我们的应用程序使用以文档为中心的模型，因为 Core Data 直接支持它。我最担心的是，如果我们坚持当前的非基于文档的范式，我们将面临开发人员的开销。
您对如何将鞋盒应用程序集成到新的 Lion 世界有什么建议或想法吗？
We have a shoebox-style application that we want to make a first-class citizen in Lion. This means integrating Auto-Save & Versions among other things. Currently we don’t have a document-centric model and we just use a plain Core Data stack.
UIPersistentDocument provides a really easy way to integrate both Auto-Save & Versions and I see two options we could choose from to integrate with the new APIs:
- “Abuse” NSPersistentDocument for our shoebox-style application. Technically it would be a document-based application, but the user interface would still be the same iPhoto-like library. This makes conceptually not a lot of sense, but we would get a lot of functionality for free.
- Keep the current plain Core Data stack and implement Auto-Save & Versions manually.
I heard contradicting opinions from Apple representatives about the approach we should take and it would be great to clarify things before we start our implementation. While I think that 1. shouldn’t be used it’s also very tempting, because we get a lot for free. I couldn’t even find sufficient documentation on manually implementing Auto-Save & Versions in a Core Data application.
I would really tend to use 1. but I see some problems:
- I’m worried about file-system-level conflicts when using versions and only one database-file. I couldn’t find any documentation regarding this topic.
- I’m worried about performance issues in Versions when browsing through “space”.
- We can’t enforce only one instance of the open database, since Versions has to open several instances. I’m worried about side-effects and concurrency issues.
Conceptually it looks like a hack and I don’t like hacks.
If we would only want to integrate iCloud sync I definitely wouldn’t think about using a document-centric model for our application, because Core Data supports it directly. I’m mostly worried about the developer overhead we would have if we would stick to our current non-document based paradigm.
Do you have any advice or ideas how shoebox applications should be integrated in the new Lion world?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
恐怕您被迫使用第一个选项。版本是在 NSDocumentController *sic* 内部实现的，因此您必须使用某种
NSDocument来从版本中获取任何内容。我认为您还必须将 NSWindowController 中的应用程序窗口添加到该文档中，以便在顶部获得漂亮的小弹出菜单。问题在于版本或多或少是一个完全不透明的功能...但是您必须自己回答一个问题：您希望将应用程序的哪些部分放入版本中？在恢复数据时，将所有内容都放在一个文件中真的有意义吗？版本恢复（复制和粘贴除外）发生在文件系统级别。因此，总是立即恢复所有内容真的有意义吗？如果您的答案是否定的，您甚至可能必须将模型分割成多个较小的文件......
在下一个主要版本之前不要指望这里会有改进。这是我从工程师的评论中猜测的......
I'm afraid you're forced into using the first option. Versions is implemented inside NSDocumentController *sic* and so you will have to use some kind of
NSDocumentto get anything out of versions. I think you also have to add your App's Window in aNSWindowControllerto that document in order to get the nice little popup menu at the top. The problem is that versions is more or less a completely opaque feature...But there's a question you gotta answer yourself: What portions of your app would you want to put into version? Does it really make sense to have everything in a single file when it comes to restoring data? Version restore (other than copy&paste) happens on the file-system level. And thus, does it really make sense to always have everything restored at once? If your answer is no, you probably even have to slit up you model into multiple smaller files...
Don't expect improvement here until the next major release. That's what I guessed from the engineers comments...