In this post, I’ll enumerate four major types of callback mechanisms in Objective-C, and mention some comparisons to help choose the best one for whichever class you’re designing.<\/p>\n
Intuitively, a callback is a method that you think of as being called from outside your code.<\/p>\n
More formally, a callback is a method that can be called by other classes which may be created after, or independently of, your class. \u00c2\u00a0These methods are named callbacks because we have to explicitly provide a pointer to the caller so they can “call us back” later. \u00c2\u00a0Two classic examples: an asynchronous NSURLConnection needs a way to report back when it’s done loading a page, and a UIButton needs a way to report that a user pressed the button.<\/p>\n
Delegation is one of the most common callback mechanisms in current Objective-C code. \u00c2\u00a0The use of formal protocols (or just “protocols” in the language spec) is almost\u00c2\u00a0synonymous\u00c2\u00a0with delegates, so I’ll group them together here; although you can use protocols for non-delegate purposes, too.<\/p>\n
To use this method, you declare a set of methods in a @protocol block, and require the class getting called back to be set as your delegate object \u00e2\u20ac\u201c generally this is a weak reference (not retained) to an id<MyClassDelegate> type. \u00c2\u00a0When you want to call the callback, you can simple execute a [delegate doMyCallbackWithObject:x] statement on required methods. \u00c2\u00a0For optional methods, first check that they’re implemented, and either call them or execute your default behavior.<\/p>\n
UITableViewDelegate is a good example protocol for this callback mechanism.<\/p>\n
UIControl and therefore its subclasses \u00e2\u20ac\u201c including UIButton, UISwitch, and UISlider, to name a few \u00e2\u20ac\u201c all use a target\/action pair method to handle callbacks.<\/p>\n
To use this method, the class getting called back must specify both a selector (the action<\/em>) and an object pointer (the target<\/em>) that you can call at any time. \u00c2\u00a0It is up to the target to make sure the signature (i.e. the set of input and output parameters) of the action is something useful to your class. \u00c2\u00a0Notice that each selector has to be registered separately, as opposed to the delegate method which registers all the callbacks in one set.<\/p>\n Objective-C didn’t always have the @optional keyword for @protocols, which makes delegation very practical. \u00c2\u00a0Before @optional, it was common to add a category to NSObject which implemented the callbacks you needed \u00e2\u20ac\u201c this is an informal protocol. \u00c2\u00a0This is similar to a formal callback in that all the names and signatures of the methods are fixed and available in a header file, but it differs in that all objects necessarily have a default implementation (no required or optional distinction) and a class can’t officially declare that it overrides these methods (but we can still find out at runtime of course).<\/p>\n Apple is phasing out informal protocols in favor of formal ones, although they can still be useful in situations where you’d prefer all objects to have easy access to default implementation of the protocol.<\/p>\n NSURLConnection is an example of an informal protocol callback mechanism.<\/p>\n Notifications are ideal for broadcasting messages (one-caller-to-many-callback-receivers) or for some decoupling of the caller and receiver.<\/p>\n To use this method, the caller simply posts an NSNotification object to an NSNotificationCenter; any classes that are interested in being called from this must have previously registered themselves as an observer of that notification. \u00c2\u00a0Notifications are identified by strings, and there is no formal way to declare which notifications your code produces \u00e2\u20ac\u201c this communication must happen in comments\/documentation (or by hand-parsing the code if you have to).<\/p>\n UIKeyboardWillShowNotification is an example notification name (it’s a string) that is posted when the keyboard is about to show up. \u00c2\u00a0This gives UI elements a chance to react by moving important views so they’re not obstructed by the keyboard.<\/p>\n Each approach has pros and cons. \u00c2\u00a0To help see this, consider the use cases for UITableViewDelegate (delegation), UIButton (target\/action), NSURLConnection (informal protocol), and UIKeyboardWillShowNotification (notification).<\/p>\n Delegation<\/strong> Pros: One object pointer connects all the methods, signatures and names of methods are clearly documented, required and optional method distinction. \u00c2\u00a0Cons: Impractical to be a delegate for multiple objects, subclassing the called back class is challenging.<\/p>\n Target\/Action<\/strong> Pros: Easy to work with multiple objects giving callbacks, flexible signatures, only one method at a time is required. \u00c2\u00a0Cons: Practical only for small sets of methods, signatures are not formally declared, receiver must unregister itself before it’s gone.<\/p>\n Informal Protocol<\/strong> Pros: Default implementation always available, possible to avoid specifying a target. \u00c2\u00a0Cons: No compile-time declaration of following an informal protocol, fills up the method namespace, no required\/optional distinction.<\/p>\n Notification<\/strong> Pros: There can easily be many targets, caller doesn’t need any pointers to targets, receiver and target can be created in any order. \u00c2\u00a0Cons: Input parameters must be packaged in a userInfo dictionary, notification names are not formally declared, receiver must unregister itself before it’s gone, slightly longer calling time due to indirection.<\/p>\n How to choose?<\/p>\n If you might have many callers for the same target (such as a custom UI control), then target\/action is probably good.<\/p>\n If you might have many targets for a single caller, then a notification is probably good, although you could also handle this with target\/action if tighter coupling is preferred.<\/p>\n If you expect a one-to-one pairing between caller and target, then a delegate is probably the way to go.<\/p>\n Are there still times to use informal protocols? \u00c2\u00a0Some folks might say no, but I’ll argue against that.<\/p>\n A case for informal protocols<\/strong><\/p>\n When would you like to use informal protocols? \u00c2\u00a0I suggest using them when you want to implement a simple asynchronous interface with optional callbacks for a universally usable piece of functionality.<\/p>\n For example, suppose you’re writing a serialization method that uses Objective-C’s reflection to convert any class into a string (your own version of NSCoding, basically). \u00c2\u00a0You’d like to allow any object to be able to call:<\/p>\n [self writeToURL:myURL];<\/p>\n And have this work out. \u00c2\u00a0In this case, a category on NSObject is perfect. \u00c2\u00a0Now, suppose you want to give users a chance to react to an error asynchronously, but only if they want to. \u00c2\u00a0Then you could implement your own version of [NSObject writeToURLFailedWithError:(NSError *)error], which simply NSLogs the error, and allow users to override this method. \u00c2\u00a0This is nice because the user’s class never has to specify itself as a delegate or a target\/action \u00e2\u20ac\u201c you’re aware of both the target (since you have access to self in writeToURL:) and the action (since you name the selector in your category). \u00c2\u00a0In other words, we’ve just made using this functionality a little easier by using an informal protocol.<\/p>\n In this post, I’ll enumerate four major types of callback mechanisms in Objective-C, and mention some comparisons to help choose the best one for whichever class you’re designing. Intuitively, a callback is a method that you think of as being called from outside your code. More formally, a callback is a method that can be […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_mi_skip_tracking":false},"categories":[7,6],"tags":[30,29,37,36],"_links":{"self":[{"href":"http:\/\/bynomial.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/13"}],"collection":[{"href":"http:\/\/bynomial.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/bynomial.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/bynomial.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/bynomial.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=13"}],"version-history":[{"count":0,"href":"http:\/\/bynomial.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/13\/revisions"}],"wp:attachment":[{"href":"http:\/\/bynomial.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=13"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/bynomial.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=13"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/bynomial.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=13"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Informal Protocols or Category Callbacks<\/h2>\n
Notifications<\/h2>\n
Choosing a type of callback<\/h1>\n
Resources<\/h1>\n
\n