How to perform Callbacks in Objective-C

For completeness, since StackOverflow RSS just randomly resurrected the question for me, the other (newer) option is to use blocks:

@interface MyClass: NSObject{    void (^_completionHandler)(int someParameter);}- (void) doSomethingWithCompletionHandler:(void(^)(int))handler;@end@implementation MyClass- (void) doSomethingWithCompletionHandler:(void(^)(int))handler{    // NOTE: copying is very important if you'll call the callback asynchronously,    // even with garbage collection!    _completionHandler = [handler copy];    // Do stuff, possibly asynchronously...    int result = 5 + 3;    // Call completion handler.    _completionHandler(result);    // Clean up.    [_completionHandler release];    _completionHandler = nil;}@end...MyClass *foo = [[MyClass alloc] init];int x = 2;[foo doSomethingWithCompletionHandler:^(int result){    // Prints 10    NSLog(@"%i", x + result);}];

Normally, callbacks in objective C are done with delegates. Here's an example of a custom delegate implementation;

Header File:

@interface MyClass : NSObject {    id delegate;}- (void)setDelegate:(id)delegate;- (void)doSomething;@end@interface NSObject(MyDelegateMethods)- (void)myClassWillDoSomething:(MyClass *)myClass;- (void)myClassDidDoSomething:(MyClass *)myClass;@end

Implementation (.m) File

@implementation MyClass- (void)setDelegate:(id)aDelegate {    delegate = aDelegate; /// Not retained}- (void)doSomething {    [delegate myClassWillDoSomething:self];    /* DO SOMETHING */    [delegate myClassDidDoSomething:self];}@end

That illustrates the general approach. You make a category on NSObject that declares the names of your callback methods. NSObject doesn't actually implement these methods. This type of category is called an informal protocol, you're just saying that many objects might implement these methods. They're a way to forward declare the type signature of the selector.

Next you have some object be the delegate of "MyClass" and MyClass calls the delegate methods on the delegate as appropriate. If your delegate callbacks are optional, you'll typically guard them at the dispatch site with something like "if ([delegate respondsToSelector:@selector(myClassWillDoSomething:)) {". In my example, the delegate is required to implement both methods.

Instead of an informal protocol, you can also use a formal protocol defined with @protocol. If you do that, you'd change the type of the delegate setter, and instance variable to be "id <MyClassDelegate>" instead of just "id".

Also, you'll notice the delegate is not retained. This is typically done because the object that "owns" instances of "MyClass" is typically also the delegate. If MyClass retained its delegate, then there would be a retain cycle. It's a good idea in the dealloc method of a class that that has a MyClass instance and is its delegate to clear that delegate reference since it's a weak back pointer. Otherwise if something is keeping the MyClass instance alive, you'll have a dangling pointer.

Here's an example that keeps the concepts of delegates out, and just does a raw call back.

@interface Foo : NSObject {}- (void)doSomethingAndNotifyObject:(id)object withSelector:(SEL)selector;@end@interface Bar : NSObject {}@end@implementation Foo- (void)doSomethingAndNotifyObject:(id)object withSelector:(SEL)selector {    /* do lots of stuff */    [object performSelector:selector withObject:self];}@end@implementation Bar- (void)aMethod {    Foo *foo = [[[Foo alloc] init] autorelease];    [foo doSomethingAndNotifyObject:self withSelector:@selector(fooIsDone:)];}- (void)fooIsDone:(id)sender {    NSLog(@"Foo Is Done!");}@end

Typically the method -[Foo doSomethingAndNotifyObject:withSelector:] would be asynchronous which would make the callback more useful than it is here.