Overhead of NSNotifications
I recently started using NSNotification
s:开发者_StackOverflow社区
[[NSNotificationCenter defaultCenter] postNotificationName: selector: object:]; ....
I find it to be an awesome concept for communicating between view controllers. It almost seems a little too easy to use NSNotification
s for all the communications in the app.
In the event that I use NSNotification
s for most of the work in my app, what do you think would be the overhead for too many of them?
One of things you need to remember about NSNotification
s are that they are a blocking mechanism. So while the object posting the notification need not know who is receiving it, if there are too many receivers, it will have to process all of them before the postNotification
call can return. That is something that you will have to take into consideration.
As such, like @slev said, delegates are a better approach. Use notifications only when you can't use the delegate approach.
I seem to recall reading that NSNotification is pretty overhead consuming, so using a lot of them probably wouldn't be the best idea. Instead, I'd look into adopting delegate
protocols. You can easily create your own to tell your files what to do and when.
This site gives an example fairly similar to the one I used to learn how to create delegates and might be worth looking into. I used to use NSNotifications all the time until I learned about delegates and have since switched all my notifications over to delegate methods instead
精彩评论