Home/ Questions/Q 8082401
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-05T17:04:51+00:00

Question We’re developing a custom EventEmitter inspired message system in Objective-C. For listeners to

  • 0

Question

We’re developing a custom EventEmitter inspired message system in Objective-C. For listeners to provide callbacks, should we require blocks or selectors and why?

Which would you rather use, as a developer consuming a third party library? Which seems most in line with Apple’s trajectory, guidelines and practices?

Background

We’re developing a brand new iOS SDK in Objective-C which other third parties will use to embed functionality into their app. A big part of our SDK will require the communication of events to listeners.

There are five patterns I know of for doing callbacks in Objective-C, three of which don’t fit:

  • NSNotificationCenter – can’t use because it doesn’t guarantee the order observers will be notified and because there’s no way for observers to prevent other observers from receiving the event (like stopPropagation() would in JavaScript).
  • Key-Value Observing – doesn’t seem like a good architectural fit since what we really have is message passing, not always “state” bound.
  • Delegates and Data Sources – in our case, there usually will be many listeners, not a single one which could rightly be called the delegate.

And two of which that are contenders:

  • Selectors – under this model, callers provide a selector and a target which are collectively invoked to handle an event.
  • Blocks – introduced in iOS 4, blocks allow functionality to be passed around without being bound to an object like the observer/selector pattern.

This may seem like an esoteric opinion question, but I feel there is an objective “right” answer that I am simply too inexperienced in Objective-C to determine. If there’s a better StackExchange site for this question, please help me by moving it there.

UPDATE #1 — April 2013

We chose blocks as the means of specifying callbacks for our event handlers. We’re largely happy with this choice and don’t plan to remove block-based listener support. It did have two notable drawbacks: memory management and design impedance.

Memory Management

Blocks are most easily used on the stack. Creating long-lived blocks by copying them onto the heap introduces interesting memory management issues.

Blocks which make calls to methods on the containing object implicitly boost self‘s reference count. Suppose you have a setter for the name property of your class, if you call name = @"foo" inside a block, the compiler treats this as [self setName:@"foo"] and retains self so that it won’t be deallocated while the block is still around.

Implementing an EventEmitter means having long-lived blocks. To prevent the implicit retain, the user of the emitter needs to create a __block reference to self outside of the block, ex:

__block *YourClass this = self;
[emitter on:@"eventName" callBlock:...
   [this setName:@"foo"];...
}];

The only problem with this approach is that this may be deallocated before the handler is invoked. So users must unregister their listeners when being deallocated.

Design Impedance

Experienced Objective-C developers expect to interact with libraries using familiar patterns. Delegates are a tremendously familiar pattern, and so canonical developers expect to use it.

Fortunately, the delegate pattern and block-based listeners are not mutually exclusive. Although our emitter must be able to be handle listeners from many places (having a single delegate won’t work) we could still expose an interface which would allow developers to interact with the emitter as though their class was the delegate.

We haven’t implemented this yet, but we probably will based on requests from users.

UPDATE #2 — October 2013

I’m no longer working on the project that spawned this question, having quite happily returned to my native land of JavaScript.

The smart developers who took over this project decided correctly to retire our custom block-based EventEmitter entirely.
The upcoming release has switched to ReactiveCocoa.

This gives them a higher level signaling pattern than our EventEmitter library previously afforded, and allows them to encapsulate state inside of signal handlers better than our block-based event handlers or class-level methods did.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Personally, I hate using delegates. Because of how objective-C is structured, It really clutters code up If I have to create a separate object / add a protocol just to be notified of one of your events, and I have to implement 5/6. For this reason, I prefer blocks.

    While they (blocks) do have their disadvantages (e.x. memory management can be tricky). They are easily extendable, simple to implement, and just make sense in most situations.

    While apple’s design structures may use the sender-delegate method, this is only for backwards compatibility. More recent Apple APIs have been using blocks (e.x. CoreData), because they are the future of objective-c. While they can clutter code when used overboard, it also allows for simpler ‘anonymous delegates’, which is not possible in objective C.

    In the end though, it really boils down to this:
    Are you willing to abandon some older, more dated platforms in exchange for using blocks vs. a delegate? One major advantage of a delegate is that it is guaranteed to work in any version of the objc-runtime, whereas blocks are a more recent addition to the language.

    As far as NSNotificationCenter/KVO is concerned, they are both useful, and have their purposes, but as a delegate, they are not intended to be used. Neither can send a result back to the sender, and for some situations, that is vital (-webView:shouldLoadRequest: for example).

    • 0