NSCoding VS Core data

Question

I've been searching for an article that explains NSCoding (NSKeyedArchiver...) advantages and disadvantages over use of CoreData (SQLite....).

There's a lot of options, I can implement my own custom binary reader/writer, or use plists/xml/json... or use SQLite or NSCoding.

I'm kind of lost right now. Can any body explain what's the difference between the MAIN features?

Hoosegow

Possible Duplicates: stackoverflow.com/questions/4989609 stackoverflow.com/questions/840634 – Rathe

the thing is sqlite is considered inside coredata. And the first link you suggested, talks about specifically sqlite3 vs nscoding; with not much answers. I'm asking a more general questions. Why there's so many options to deal with data. – Hoosegow

As a side-note. Core Data can automatically invoke NSCoding methods on Transformable attributes which have adopted NSCoding and convert the attribute to a binary blob which can be saved in Core Data. For more see Do all attributes with a custom type in core-data have to be a relationship? – Divest

Answer 1

It depends which kind of data you want to save and whether you will use it only internally or you have to exchange the data with an external service.

NSCoding is generally speaking a data serializer. A lot of built-in objects implements the NSCoder protocol that allows you to save them as a binary stream (file, in a BLOB of an sqlite, etc.) The NSKeyedArchiver gives you the plus of searching in such streams based on a string label, a bit like a dictionary but you can use only strings as keys. This approach is good if you occasionally have to persist some objects of different classes.

However if you have many objects of the same class, you'll better go for a database-approach, SQLite or CoreData. CoreData is practically a wrapper around SQLite that eases a lot designing your data model, and does the queries to the DB behind the curtains, without the need of writing SQL statements. In CoreData you define your classes, and each instance of the class can be persisted i.e. you can get back the values of the members of the object without having them always in the memory. This is a very convenient way to store a lot of structured data. For example if you'd write a web browser, you could store the bookmarks of the user with the name, URL, and maybe last visited time.

For XML and JSON there're no particular advantage if you use the data only locally to the device. If you have to communicate with some external service, you might consider to cache/save the XML / JSON objects as they are for later use. Other approach would be to regenerate this data from your internal data structures (see above) every time you need it.

If you design your data model yourself, I see even less point to use plists, but maybe somebody will correct me.

EDIT: I add here a short link reference for tutorials on how to use NSCoding, Core Data, and as a bonus, SQLite.

UPDATE 12.01.2016: If you are looking for persistence solutions I suggest you to also check out Realm.

Thurmond

if the blob files of an sqlite are serialized, that could mean that serialization is the best in order to obtain the smallest chunks of binary data. As well you can use NSCoding for conditionalObjectEncodings, which removes the duplication of in-memory alive object instances. The reason i'm asking this question, is because everybody talks and suggests Coredata-SQLite, but i'm not seeing THAT advantage Unless building against a huge datasource, and you can't put all that in memory. Am i right? – Hoosegow

There is always a balance between memory and performance optimization. With NSCoding, or your custom binary representation you have much more control over the bits being written to the storage or being stored in the memory, but for this you have to pay the price of coding more thus the efficiency of the code will depend on your abilities. With CoreData/SQLite a lot of useful things are implemented for you in an efficient way (searching, querying, indexing, joins, etc). Note: CoreData objects are loaded into the memory only when needed, otherwise they stay in the db. – Thurmond

Excellent. So if i'm using "ApplicationDocument" template of applications, and if i need to save and open documents, i wouldn't really need the benefits of CoreData, since i need to load everything in memory, and don't need to query and... database functionalities. The major difference is the development cost. Which in my case is not a setback. Thanks a lot. I'll wait a bit, to attract more answers and more discussions, before accepting an answer – Hoosegow

Yes, developing your own (binary) document format is a typical case to go for the more low level, serialization type tools like the NSCoder framework. – Thurmond

I know this is an older thread, but I thought I would add some insight. Honestly, I would throw in simplicity and security as keypoints as well. – Jehol

Really helpful answer :) – Toga

Answer 2

Mattt Thompson provides a digestible breakdown of various differences among NSCoding, Core Data, and NSKeyedArchiver on NSHipster: http://nshipster.com/nscoding/

Roentgen

Answer 3

There's always an impedance between objects and relational structures. I always prefer objects since data access is typically a fraction of functionality in your app. With NSCoding, you get simplicity, ease of debugging, and control with very little code to write anyways. You also have the flexibility to incorporate NSCoding into your database structures.

NSCoding is a persistence mechanism for saving objects. If you add indexes to your relational structures for search optimization and maintain object structures, then I think you get the best of all worlds at a very low cost and ease of maintenance.

Jehol

Answer 4

To add to already great answers, NSCoding along with NSKeyedArchiver is a great way to store data which is too big (or incompatible data type) for for NSUserDefaults but too small and non-numerous for CoreData.

Tachymetry