Question

I was using method swizzling to wrap all method invocations in a class with some extra functionality. Specifically I was:

  • Checking if the required object for this method call was in the cache
  • If the cache had that object return it.
  • If not, dispatch to the original implementation, populate the cache and return that.

For each method, I would reroute to an advised method. And implement the new method using + (BOOL)resolveInstanceMethod:(SEL)sel and IMP_implementationWithBlock.

It worked fine, but the code didn't read nicely. It seems NSProxy will provide a neater way to implement this functionality.

But still another alternative, would be to simply have an NSObject subclass stand-in and intercept method calls around my target object's methods. By overriding forwardInvocation and methodSignatureForSelector, I can get the required outcome.

So what does NSProxy give me? Why should I use this instead?

Was it helpful?

Solution

The point of NSProxy is that it doesn't implement most methods. That's necessary to be sure that the Objective-C forwarding machinery gets invoked to begin with. If you start with NSObject, there are a lot of methods which will just be directly dispatched without you having an opportunity to forward them.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top