mikeash.com pyblog/friday-qa-2010-08-12-implementing-nscoding.html comments

mikeash - 2010-08-16 03:05:27

Mon, 16 Aug 2010 03:05:27 GMT

Good point on possibly overwriting instance variables. I suppose if you use [self init] or similar, you shouldn't be replacing instance variables directly.

For implementing NSCoding, I think the best approach is to decode the values you need, then call through to the "real" initializer.

Incidentally, I think NSView's approach of having two separate designated initializers is painful and really shouldn't have been built that way. If initWithCoder: would call through to initWithFrame:, it would avoid a decent bit of hassle involved in subclassing Cocoa views. Too late to change it now, I imagine.

While it works to have multiple designated initializers (so long as only one ever runs), I think it's best to try to only ever have one.

Ken Ferry - 2010-08-16 02:28:24

Mon, 16 Aug 2010 02:28:24 GMT

The call to [self init] from -initWithCoder: could probably use some more discussion - I would have written [super init] there.

Done as you have here, -initWithCoder: is not a designated initializer of the class. -initWithCoder: is a designated initializer of say, NSView, so this is a pitfall. If the -init method of this class or any subclass writes to any of the ivars, code in -initWithCoder: method of this class or one of its subclasses is likely to overwrite the ivars and leak.

I thought you had a post on designated initializers, but maybe not. In any case, the goal is to make this rule true: One and only one of each class's designated initializes runs during the bringup of an object. Each _class_, not object, has a set of designated initializers. The sets of designated initializers of a class and of its superclass are not necessarily related.

YT - 2010-08-14 16:14:55

Sat, 14 Aug 2010 16:14:55 GMT

Thank you for your answer! As always, it's a great article.

mikeash - 2010-08-14 15:34:32

Sat, 14 Aug 2010 15:34:32 GMT

Well, int is 32-bit even on 64-bit Mac OS X, so the only problem there is endianness. NSCoder knows about endianness and will take care of any byte flipping.

For a type of inconsistent size, such as NSInteger, it will also take care of adjusting the size. However, if you use such a size, you must ensure that you never store a value on the 64-bit machine that can't be represented on the 32-bit machine, otherwise you'll get an exception when decoding.

YT - 2010-08-14 06:02:18

Sat, 14 Aug 2010 06:02:18 GMT

What happens if you encodeInt:forKey: on a 64 bit ppc machine, and then decodeInt:forKey: the resulting archive on a 32 bit intel machine, say?

jt - 2010-08-14 01:32:57

Sat, 14 Aug 2010 01:32:57 GMT

Thanks once again, Mike, for taking the time to bring us another terrific instalment.

mikeash - 2010-08-13 22:57:26

Fri, 13 Aug 2010 22:57:26 GMT

I'd really wonder at any code that had to serialize and deserialize a view controller. Typically you should only be serializing model objects. (Nibs are obviously a big exception to this, but of course that's already done for you.) What was your use case for this?

Anyway, that's the sort of advice which isn't completely universal, but by the time you need to violate it you'll know enough to do so, so it isn't necessary to spell out all of the caveats.

Farcaller - 2010-08-13 20:49:18

Fri, 13 Aug 2010 20:49:18 GMT

> You must call the superclass versions if the superclass implements NSCoding

Actually no. A sample is iOS'es UIViewContoller that implements its view serialization as a part of encodeWithCoder:. I had a case when I need to serialize the UIViewController subclass that creates its view in runtime, so I had to override encodeWithCoder: with own version that does not call the superclass. This way it would be deserealized with view==nil and could re-create the view according to new UI conditions.

Peter - 2010-08-13 18:55:41

Fri, 13 Aug 2010 18:55:41 GMT

Just a heads-up: I've noticed that specifying a different name for a class causes a crash in iOS 3.2.

mikeash - 2010-08-13 17:14:44

Fri, 13 Aug 2010 17:14:44 GMT

You must call the superclass versions if the superclass implements NSCoding, but not if it doesn't. That's the case if you subclass NSObject, but also any one of the numerous other classes that don't implement it.

Jose Vazquez - 2010-08-13 17:05:07

Fri, 13 Aug 2010 17:05:07 GMT

Thanks for the post. This article would have saved me some headaches a few weeks ago.

I do have one more related question. From what I understood in the Hillegass book, you should call encodeWithEncoder: and initWithEncoder: on super if you are subclassing something other than NSObject. You didn't mention that in your article, so I wonder if you disagree or simply forgot to mention it.

Thanks again for the article.