Shoebox / Library applications with Auto-Save & Versions in OS X Lion

Question

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:

1. “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.
2. 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?

Ponytail

What is a "shoebox-style application"? – Flatways

A shoebox or library application is an application that holds all of your data inside one window instead of using multiple documents. Good examples for shoebox-style applications are iPhoto, iTunes; good examples for document-based applications are Pages or Keynote. Although iTunes and iPhoto are shoebox applications they still work with a „library“ that itself is a document and you can switch between different libraries. – Ponytail

Answer 1

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 NSDocument to get anything out of versions. I think you also have to add your App's Window in a NSWindowController to 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...

Armandinaarmando

+1 Versioning only makes sense in the context of documents were the same content evolves overtime. It doesn't make sense to have different "versions" of a all-in-one database store because you usually want to capture only the current state of the data. In a database, a new "version" is almost always actually treated as new data. If you need something like versioning in a database, you design it into the data model itself because it is rarely as simple as just having data entered at different times as is the case with document versioning. – Flatways

@Max: You can also use NSFileVersion and create your own UI for versions, but you won’t get the fancy Time Machine UI all people are used to. I don’t think that it’s a benefit for users from an UX perspective if every app would have its own custom versions UI. There is also the problem that NSPersistentDocument supports record-based saves for SQLite-based Core Data models. For me it looks like the implementation isn’t finished, because the natural evolution would be that versions also supports record-based (instead of file-based) modifications. Splitting up the model wouldn’t work (Shoebox). – Ponytail

@TechZen: Yes, you’re basically right. But then what’s a document? You can have Core Data based documents inside a NSFileWrapper that still hold a complete model with auxiliary files. If we take a book example, where do you draw the line? Is every document a book with chapters inside or is a document a library that holds different books and you have distinct libraries like research, fun, comic books? Core Data isn’t a database and the APIs don’t let you interact with your models like with classic databases. Furthermore NSPersistentDocument and iCloud already have record-based support for CD. – Ponytail

@Rafael -- It has nothing to do with file format. The dividing line here is granularity at which changes are saved. A database app will save very fine changes e.g. changing a single name out thousands in the database. A document based app will save only in large chunks e.g. saving thousands of words added to a word processing document. The fine granularity of a DB app makes versioning then entire store file rather silly because to be useful you would have to make a new version each time you changed a couple of bytes. – Flatways

I support TechZen's opinion: You can still split the model into separate chunks that are each separately stored using the efficient core data saving mechanism. BTW: With CoreData and SQLLite, I bet that most writes actually overwrite the whole file anyways, even if just a single record changes... – Armandinaarmando