Parmanoir

Forwarding invocations

When calling an unknown method, Cocoa will try to forward the call using forward invocation. It gives you a chance to handle the unknown method yourself and do whatever you want with it : call a proxy object, change the method name and its params, or just discard the call.

First, decide in methodSignatureForSelector: whether to handle the call or not. If so, you'll need to return a signature describing arguments and return type of the method you'll call in place of the unknown one. To discard the call, just return nil. The signature itself is made up of type encodings, but you don't have to deal with those directly as you can use methodSignatureForSelector: to return the signature of the method you'll actually call.

Then, handle the call in forwardInvocation:. The NSInvocation given as parameter gives you the original selector and its arguments. As a Cocoa method is actually a C function taking instance and selector as its first arguments, the unknown method's arguments actually start from the third argument.

Sample code time ! Here's a standard mutable dictionary ...

id dict = [NSMutableDictionary dictionaryWithObjectsAndKeys:
			@"John", @"name", 
			[NSNumber numberWithInt:47], @"age", 
			nil];

... that you can get and set on with valueForKey: and setValue:forKey:. As it's a bit verbose, let's use forward invocation to masquerade accessors :

// Call non existent getter - (id)age
NSLog(@"age=%@", [dict age]);
// Set a new age using a non existent setter - (void)setAge:(id)newAge
[dict setAge:[NSNumber numberWithInt:48]];

To accomplish this, we'll add forward invocation to NSDictionary to redirect zero parameter calls to call valueForKey: and one parameter calls (starting with set) to setValue:forKey:.

@implementation NSDictionary (ForwardInvocation)

// Determine if we can handle the unknown selector sel
- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel
{
	id	stringSelector = NSStringFromSelector(sel);
	int	parameterCount = [[stringSelector componentsSeparatedByString:@":"] count]-1;

	// Zero argument, forward to valueForKey:
	if (parameterCount == 0)
		return [super methodSignatureForSelector:@selector(valueForKey:)];

	// One argument starting with set, forward to setValue:forKey:
	if (parameterCount == 1 && [stringSelector hasPrefix:@"set"])
		return [super methodSignatureForSelector:@selector(setValue:forKey:)];

	// Discard the call
	return nil;
}

// Call valueForKey: and setValue:forKey: 
- (void)forwardInvocation:(NSInvocation *)invocation
{
	id	stringSelector = NSStringFromSelector([invocation selector]);
	int	parameterCount = [[stringSelector componentsSeparatedByString:@":"] count]-1;

	// Forwarding to valueForKey:
	if (parameterCount == 0)
	{
		id value = [self valueForKey:NSStringFromSelector([invocation selector])];
		[invocation setReturnValue:&value];
	}
	// Forwarding to setValue:forKey:
	if (parameterCount == 1)
	{
		id value;
		// The first parameter to an ObjC method is the third argument
		// ObjC methods are C functions taking instance and selector as their first two arguments
		[invocation getArgument:&value atIndex:2];

		// Get key name by converting setMyValue: to myValue
		id key = [NSString stringWithFormat:@"%@%@", 
				[[stringSelector substringWithRange:NSMakeRange(3, 1)] lowercaseString],
				[stringSelector substringWithRange:NSMakeRange(4, [stringSelector length]-5)]];

		// Set 
		[self setValue:value forKey:key];
	}
}

@end
The downside of this sample is that XCode will complain about unknown methods. Nonetheless, it's nice to see that you can do it.

Scott
2010 05 12

For the problem about Xcode complaining about non existant methods, just create a interface for a category on the class declaring the methods but don't implement category. Xcode will see the declarations

On a separate issue do you have any experience with performance. How much overhead does this create. Eg. Time to make 10000 accesses on this as opposed to just using objectForKey: and setObject:forKey:

I have done something similiar in creating acccessors at runtime by adding methods to a class that all route their implementation to a single c function that parses the selector to handle the actual data accesses. Being written in c I have sense is that it is only a minor overhead. I'll post this later as I have time. (btw. A good deal of credit for this technique goes to Jeff Lamarche.)

Patrick Geiller
2010 05 12

A quick bench shows the get accessor 3% slower than valueForKey: and a set/get couple being 20 times slower.


Follow me on Twitter
Planet Cocoa
Cocoa.fr

2011 02 22Distance field
2010 07 202Binding through NSApp
2010 05 122Forwarding invocations
2010 02 272Core Image black fringes
2010 02 21Quickest Way to Shell
2010 02 08Who's calling ?
2009 09 2138 ways to use Blocks in Snow Leopard
2009 08 182Bracket Mess
2009 08 124Taming JavascriptCore within and without WebView
2009 04 15Debugging with Activity Monitor
2009 03 25How Core Image Color Tracking works
2009 03 1510Custom NSThemeFrame
2009 03 10Which framework is running ?
2009 03 074CoreUI can paint pretty big
2009 02 18Localization with functions
2009 01 30Did you forget to nest alloc and init?
2009 01 16JSCocoa on the iPhone
2009 01 11Mixing WebView and JavascriptCore
2009 01 09Badge overflow
2009 01 09Find your Garbage Collection leaks with Instruments

Powered by MediaWiki