Persistent Storage Cocoa/MacOSX

Question

When writing an application for MacOSX, using Cocoa/Objective-C, I'd like to be able to store the data entered by the users. There will only be one user per installation at the moment; however, I'd like to get an idea of how storage methods change if it were multiple users per installation.

In the case of 1 user per installation, should I stick to SQLLite for persistent storage, or what's the recommendation?

If I were to allow for multiple users per installation, what persistent storage method would be prefered?

Hershel

Answer 1

You can use Core Data and create a persistent store per user (in ~/Library/Application Data/My App/)

Humoral

I would almost always develop a new application with Core Data, unless I could come up with a pretty good reason not to. Data stored in the cloud comes to mind, but even then I think I'd probably use Core Data as a local cache. Also, Core Data is fast. – Masque

If you were sharing the data between different users, that might complicate things. But there is always Document-based Core Data... – Masque

Ok. And how I can do this? – Romo

Answer 2

You could also consider using an NSDictionary as your internal storage mechanism and then write them out to property list files using [NSDictionary writeToFile:atomically:]. A friend of mine likes to refer to dictionaries as God's data structure (tongue in cheek).

If your data size is modest there are several advantages to this: human readable, human writable, changeable.

Impolicy

Using NSDictionaries as model objects will lead to pain when you go to implement AppleScript support. Better to have each object be capable of generating a dictionary representing itself, and of initing itself anew from a dictionary so generated. – Cusec

Answer 3

What kind of data do you want so save? Of course you can still use sqlite to store data for multiple users (e.g. Firefox does this).

But depending on your data you might want to save it into normal files/documents? Take a look at the NSCoding protocol and the abstract NSCoder class. Or check out the document architecture (NSDocumentController, NSDocument, and NSWindowController).

Washroom

Answer 4

There will only be one user per installation at the moment; however, I'd like to get an idea of how storage methods change if it were multiple users per installation.

Format is irrelevant as long as you only save data within the user's Home directory by default.

Your options include property lists, Core Data (more an architectural decision—you either base your app on Core Data or don't use it), SQLite, NSKeyedArchiver, and your own custom format.

Cusec

Answer 5

i would start storing data onto the cloud rather than store locally. Now that ipad is coming out, what if your app is used on the iphone and ipad as well. If you store the data on the cloud, both the iphone app and the ipad can use the same data. If you store locally, obviously, iphone app and ipad app cannot use the same data.

Thought

Mac OS X apps can't run on the iPhone/iPod Touch/iPad anyway. Cocoa app != iPhone app. ;) – Distorted

mipadi: Joo Park might be suggesting this in consideration of the possibility that the questioner may someday start an iPhone and/or iPad version of the app. I wouldn't suggest storing data entirely in the cloud, though; clouds have a way of evaporating. Using the Mac version as a sync hub (at least as an optional alternative to The Cloud) would be better. – Cusec