Nscoding VS Core Data

NSCoding VS Core data

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.

iCloud - NSCoding or Core Data

iCloud support may work well with CoreData by now. However, it was so broken for so long that I (and others) completely stopped using it. I wasted so much time trying to get it to work, that I refuse to spend one more second trying to ever use it again.

After writing my own proprietary CoreData syncing solution, I finally tried Ensembles and I've never looked back.

However, if your application does not currently require CoreData, why not use the standard iCloud support? It seems to work fine for normal file syncing, which is what you seem to have if you are just saving objects to file.

No need to add the complexities of CoreData if your app is working just fine without it.

iOS (Swift): Core data transformable attributes

The suggestion in the comments of the question by @IraniyaNaynesh is a red herring.

The answer turns out to be quite simple. Change decodeObject to decodeInteger in the init?(coder aDecoder: NSCoder) method and the data restores the BLOBS, which are not nil and have been saved successfully, from the SQLite database.

Should I use Core Data or NSCoding to preserve a table view controller's data?

I'd use Core Data and a fetched results controller. If you start off with a master detail template for this then the code is all generated for you. The main benefit is that the saving is transparent for you and memory management is also transparent (you just set the fetch request page size to a suitable value).

A solution using NSCoding will work, and for 30 results may well be faster. If you know you'll never have more than 30 then it could be attractive. But you need to code (and save) and decode yourself and you still have basically the same table data source code.

UserDefaults or Core Data?]

NSUserDefaults as the name suggests (vaguely) should be used for storing preferences and app settings only. You should not be storing critical data and or user data into them.

CoreData is a full fledged persistent framework which supports large data transactions. CoreData allows you to build relational entity–attribute model for storing user data.

Please note that CoreData is a framework and can use SQLite, binary formats to store data (the default templates always use SQLite).

Example:

App preferences like show notifications, toggle switch settings, UISegmentedControl settings all go into NSUserDefaults. Whereas any data you might fetch using a web service like a list of all cities in a country, list of todos for a user go into CoreData.

PS: I don't recommend wiki for technical write-ups but to get quick understanding on CoreData, please refer here!

Pros of NSUserDefaults:

• Easy to store and retrieve data.
• Useful for storing default values with minimum fuzz.

Cons of NSUserDefaults:

• Not suitable for large data sets

• Performance hit when you try to store and load large amount of data
  All or nothing approach

Pros of CoreData:

• Reliable framework to interact and query against data

• Can be extremely fast when setup correctly (with relationships)

• Powerful capabilities

Cons of CoreData

• Takes time to master and learn the core concept

• Needs proper app architecture design to be efficient

• You cannot have a learn and implement in a day approach with CoreData

• As you improve your app, you need to improve your data architecture
  as well

• Migrating to new versions can be a pain if you are not careful.

Reference From HERE.

Swift - Core Data & NSCoding : Failed to call designated initializer

Looks like over-engineering and way too much code to me.

Why not just store the eventId and retrieve the object from Core Data? To also archive it sees really messy and redundant.

// store
NSUserDefaults.standardUserDefaults().setObject(event.eventId forKey:"mainEventID")

// retrieve
let eventId = NSUserDefaults.standardUserDefaults().stringForKey("mainEventId")!
let request = NSFetchRequest(entityName: "Event")
request.predicate = NSPredicate(format: "eventId = %@", eventId)
let event = (context.executeFetchRequest(request, error:nil) as [Event]).first!

You will have to do some more error and nil checking but you get the idea.

Can we store NSURLRequest directly into Core Data?

Core Data entities correspond to instances of NSManagedObject or a subclass of NSManagedObject, so you can't just save URL requests directly. What you could do is create an entity called something like SavedRequest that has a property representing the URL request-- and maybe some other details about the request (whatever other info you might need-- date, maybe?).

Since NSURLRequest conforms to NSCoding, you would create this property using the Core Data "transformable" type. Core Data would use NSCoding to automatically convert to/from NSData as needed. You would assign an NSURLRequest to the property and read them back, and Core Data would save them as NSData.

Given your description though, Core Data might not make sense. It sounds like you just want to save a list of URL requests and later read it back, and don't need the extra features Core Data would provide. It would be simpler to put your NSURLRequest objects in an array and then save that array to a file or to user defaults. You would convert to/from NSData yourself, but since you can use NSCoding that's easy.

To save the array you'd do something like this, assuming an array called myArray containing URL requests and a path in filePath:

BOOL success = [NSKeyedArchiver archiveRootObject:myArray toFile:filePath];

You'd get the array back using

NSArray *savedRequests = [NSKeyedUnarchiver unarchiveObjectWithFile:filePath];

---

Related Topics