1

Can I fix this with adding a category of <NSCoding> methods ?

JoseK
  • 31,141
  • 14
  • 104
  • 131
Kristof
  • 557
  • 6
  • 14

2 Answers2

2

While Joshua's answer is correct, there is a meta-answer.

You really don't want to archive an NSInvocation. An NSInvocation may contain an arbitrary target, may have been invoked and have an arbitrary return value, and might have any number of arbitrary arguments. Generic archiving is pretty much entirely out of the question.

You are far better off architecting our app such that you archive exactly the set of state you need to recreate an appropriately configured invocation upon unarchival.

bbum
  • 162,346
  • 23
  • 271
  • 359
1

Have you tried the documentation? It says:

Note: NSInvocation conforms to the NSCoding protocol, but only supports coding by an NSPortCoder. NSInvocation does not support archiving.

Joshua Nozzi
  • 60,946
  • 14
  • 140
  • 135
  • ... yes ... but you can't have it. The documentation states it only supports coding by an NSPortCoder and that it does not support archiving. – Joshua Nozzi Mar 29 '11 at 14:10
  • What a pitty, and i can't fix it with a category on NSInvocation ? – Kristof Mar 29 '11 at 14:23
  • No. Like subclasses, categories can override methods; unlike subclasses, categories can't call the super implementation of a method implemented in that same class. Since NSInvocation is a direct sub of NSObject (which doesn't have its important parts), there is nothing to call when overridden. **NSInvocation DOES NOT SUPPORT ARCHIVING.** – Joshua Nozzi Mar 29 '11 at 14:37
  • 1
    It might be possible to do this with categories and a technique called 'method swizzling', but *just don't*. It would be quite difficult and it's unlikely that you could do it in a way that the target would be correct after unarchiving (generally.) AND you might screw up whatever expectation is associated with the NSPortCoder implementation. If you have a specific subset of NSInvocations that you can meaningfully encode, make a surrogate class that you init from an NSInvocation and which can vend an equivalent NSInvocation after being coded and decoded. This is likely the best approach. – ipmcc Mar 29 '11 at 15:30
  • The implementation details aren't likely to change often in practice but they could in theory, which would *theoretically* lead to some very bad behavior. This is why I didn't even mention it. This is not the kind of class you want to fudge. **Archiving is not supported.** – Joshua Nozzi Mar 29 '11 at 16:10