I am designing a class that will "fire events" whenever something occurs. These events tend to be non-UI related. I'm wondering what the best method for doing so is. I've been exploring either:
Delegates
I'll define a delegate class, accept a delegate in the init function, and call the methods on the delegate class when an event occurs.
C-style blocks
I'll define a function pointer, and accept a function in the init function. I'll call it when an event occurs.
In both cases, I may need to handle multiple "sources" so I'll need an array of delegates or blocks.
I've noticed that in iOS programming, delegates tend to be preferred especially for UI frameworks. But I come from a functional programming background where I definitely am comfortable with accepting function points and passing lambdas at the call site, and I like that the compiler handles hoisting variables for you, and you generally need less class-state. But I see that a lot of iOS developers are using delegates.
What is the generally preferred mechanism in iOS for doing this?
For your use case
NSNotification
seems to be the best choice. Objects that need those events then can register for those notifications.Each has its use.
Delegates should be used when there are multiple "events" to tell the delegate about and/or when the class needs to get data from the delegate. A good example is with
UITableView
.A block is best used when there is only one (or maybe two) event. A completion block (and maybe a failure block) are a good example of this. A good example is with
NSURLConnection sendAsynchronousRequest:queue:completionHandler:
.A 3rd option is notifications. This is best used when there are possibly multiple (and unknown) interested parties in the event(s). The other two are only useful when there is one (and known) interested party.
Using delegates means more tightly coupling in terms of architecture than using simple callback blocks. And for non-complex cases delegates can be an overkill.
Storing blocks in some container is just ok, but you should think ahead about possibility of removing them at some point later (this will require some work), I mean an additional interface for removing of an already added handler.