Message forwarding does not work on particular messages - ios

Question

I've found out that some Obj-C messages do no get properly forwaded when an object does not explicity handle them.
Here's an example:
Create a new UITableView like:
UITableView *v ? [[UITableView alloc] initWithFrame:CGRectMake(0, 0, 0, 0) style:UITableViewStylePlain];
Then create an instance of an NSObject with the following methods:
(A) - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
NSLog(#"tableView:numberOfRowsInSection:");
return 1;
}
(B) - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
NSLog(#"tableView:cellForRowAtIndexPath:");
return nil;
}
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector {
NSLog(#"methodSignatureForSelector: %#", NSStringFromSelector(aSelector));
return [NSMethodSignature signatureWithObjCTypes:"##:#"];
}
- (void)forwardInvocation:(NSInvocation *)anInvocation {
NSLog(#"forwardInvocation: %#", NSStringFromSelector(anInvocation.selector));
}
Let's call this object ds and set it as the dataSource for the table view:
v.dataSource = ds;
And when you run your code you should see that both methods (A) and (B) get called by the table view in the expected order:
LOG: tableView:numberOfRowsInSection:
LOG: tableView:cellForRowAtIndexPath:
Now it will get interesting, try removing (or just change the name of) method (A), and you should get:
LOG: methodSignatureForSelector: tableView:numberOfRowsInSection:
LOG: forwardInvocation: tableView:numberOfRowsInSection:
Which is fine because the table view tries to call the tableView:numberOfRowsInSection: and since the method is not there, the message gets forwarded to forwardInvocation:
Apparently, this is the default behavior for all messages that reference a method that is not defined at an object.
However try restoring the (A) method and removing (B), and you should get:
LOG: tableView:numberOfRowsInSection:
... and an error telling you that tableView:cellForRowAtIndexPath: was called but didn't return a cell.
For some reason tableView:cellForRowAtIndexPath: gets called (or not) but without following the expected forwardInvocation: pathway.
Is this a bug?
Am I doing something wrong?
Are there some messages that explicitly do not get forwarded?
Even though respondsToSelector: should return FALSE to both functions, somewhere in the implementation sends the message for cellForRowAtIndexPath: to some other object and breaks the default expected behavior...
What I've learned is basically:
If you are planning to respond to a message in your object, even through some implementation of forwardInvocation:, you should ALWAYS overload the respondsToSelector: method and return TRUE for all messages you plan to implement in your object.

Answer 1

The following is my hypothesis based on some experimentation:
The difference is that the table view doesn't attempt to call cellForRowAtIndexPath if it isn't defined, whereas it does attempt to call numberOfRowsInSection. Therefore, you only see the forwarding mechanism with numberOfRowsInSection. The error telling you a cell wasn't returned is just poorly worded and slightly misleading.
I came to this conclusion by observing that, if the data source doesn't define cellForRowAtIndexPath, the implementation on UITableViewController gets called instead. So, the table view is clearly checking for existence. Therefore, it stands to reason that what happens is something like this:
Call on dataSource if defined
Otherwise, call on UITableViewController if defined
Otherwise, don't call anything
If (3) is reached, then somewhere downstream an error is thrown because the table view's internal cell variable is nil.

Answer 2

The runtime system forwards messages only if it's unable to find a match for the given selector in the target class or any of its ancestors. However if the runtime system's search for the selector succeeds, it then invokes the method's implementation directly -- no need for forwarding.
By the way, if the lookup fails, the runtime system calls forwardingTargetForSelector: first; it then calls forwardInvocation: only if forwardingTargetForSelector: returns either nil or self.