views:

3368

answers:

3

I am a beginner programmer in Objective-C. Can anyone please tell me how to perform call back functions in Objective-C.

I would just like to see some completed examples and I should understand it.

Thanks a lot

+19  A: 

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


/// Message (.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.

Jon Hess
+1 Good thorough answer. Icing on the cake would be a link to more in-depth Apple documentation on delegates. :-)
Quinn Taylor
ReachConnection
"Message .m" just meant, in you're .m file.You'd have a separate class, let's call it "Foo". Foo would have a "MyClass *myClass" variable, and at some point Foo would say "[myClass setDelegate:self]". At any point after that, if anyone including foo invoked the doSomethingMethod on that instance of MyClass, foo would have its myClassWillDoSomething, and myClassDidDoSomething methods invoked.I'll actually also just post a second different example that doesn't use delegates.
Jon Hess
I don't think the .m stands for "message".
Chuck
Interesting, I'd always thought of it as message, but on the web it looks like people are either saying it's "Method" or "implementation".
Jon Hess
http://stackoverflow.com/questions/652186/why-do-objective-c-files-use-the-m-extension
ptomli
+4  A: 

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.

Jon Hess
Thanks a lot John. I understand your first callback implementation after your comments. As well, your 2nd callback implementation is more straightforward. Both are very good.
ReachConnection
Thanks for posting this Jon, it was very helpful. I had to change [object performSelectorwithObject:self]; to [object performSelector:selector withObject:self]; in order to get it to work correctly.
Banjer
+1  A: 

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);
}];
Ahruman