I'm Not Sure NSCoding,NSCoder,and NSKeyedArchive are Good

Cocoa Programming for OS X (5th Edition) 12. Archiving
1

I tried out implementing archiving as was taught in the book. I’m not sure that this is a good way because I tried it on a project. I did get an XML file from archiving, but when I looked at the XML file, it seemed to me that this whole method of archiving and unarchiving is fragile. What happens if I change a module name, or a class name. Wouldn’t this break my file formats?

Instead of using NSCoding, NSCoder, and NSKeyed archiver, I’m implementing XML parsing using NSXMLParser. So far, it seems better to me since the files are easier to understand, which is one thing that’s good about XML over older formats, such as binary. An XML file should be able to be opened up in a text editor and be understood by a human. My files are also shorter which isn’t the most important thing, but shorter files are better with other things being equal.

But the most important thing to me is that the file format doesn’t break when my code changes. What do you all think? Is NSCoding, NSCoder, and NSKeyed useful?

2

Keep in mind that there is more to archiving than what is covered in the book. For instance, NSKeyedUnarchiver provides a way to deal with class/module names changing:

class func setClass(_ cls: AnyClass?, forClassName codedName: String)

We say a few words about this toward the end of the Core Data chapter, but none of these persistence technologies are silver bullets. Each have their pros and cons. Writing your own has some strong advantages, such as control and portability, but then you also have to write and debug it. :slight_smile:

I don’t say this to convince you to use Archiving/NSCoding, but more to say that it is a useful technology for a certain class of persistence problems. In some projects I have used archiving, in others, Core Data, in others I created my own binary format, and in others I generated plist data structures and serialized them with JSON or MessagePack.