Use of custom delegate vs NSNotification vs NSUserDefaults state

Question

In my app I'm using NSUserDefaults to give a state then performing operations based on that state. In other places I'm using NSNotification-s to fire methods in other classes. I feel like for one example specifically it would be better to use a custom delegate.

What are the benefits and drawbacks to using NSNotification vs a custom delegate vs what I'm doing now with NSUserDefaults?

My question specifically intends to address any performance or potential issues between using NSUserDefaults to give state compared with simply calling methods using either protocols or NSNotificationCenter.

Answer 1

It's important to remember that NSUserDefaults persists data. When you read and write from NSUserDefaults, you're actually reading and writing to/from disc. Whenever you use NSUserDefaults you should ask yourself "Is this something that needs to be persisted between app launches? Could/Should I do this thing without writing to disc?" (note about performance: any time you have to go to disc for something, expect that to take a much longer time)

NSUserDefaults is ideal for things like app settings. Does your app have multiple color schemes the user can choose from? Store those preferences in user defaults and look them up later.

I would put NSUserDefaults in a different category from the other communication patters, like delegation, notifications, blocks, KVO, target-action.

Here's an awesome article about communication patterns in iOS: http://www.objc.io/issue-7/communication-patterns.html . This goes into detail on each one and what they do, and I've found their flow-charts really useful. This article also talks about KVO (key-value observing) and blocks (closures in Swift).

Delegate:

One big difference between the two, where the logic branches in the flow-chart, is whether the recipient knows the sender. You'll often hear notifications talked about as a one-to-many communication where as delegation is one-to-one.

Notifications:

Answer 2

Notification is used to broadcast messages to possibly several recipients unknown from the sender.

Delegation is used to send messages to a single known recipient acting on behalf of the sender.

Considering the performance is a good idea (delegation better for small number of notified objects, notification centre better for larger number of objects, or is it? run a profiler) but I think a more important factor since you are talking about Objective-C and less likely to be talking about the really high performance parts of your code base, which are likely to be written in C, is reducing compile-time dependencies between modules.

Answer 3

I needed explaination for this when I was implementing push notification. I wanted to perform a segue from the view controller from the top view controller on the stack or something like that. performing segue only works from the view controller with its view on screen.

Both of these ways delegate and NSNotification was fine for this purpose. but both ways has a flow for this purpose (push notification). the flow occures when the app. is totally closed which doesn't have any view controllers to inform the incident of recieving a push notification. for that I used NSUserDefaults.

Actually, I did save user info in the user defaults and also informed every view controller that a notification received. In my master view controller (a controller that every other controller inherits) I handled both the NSNotification and the UserDefaults.

I didn't come with this solution so easily. I invested sometime on it. so if that is your problem that would be my proposed solution. I don't know maybe someone can inform us of a better one. I can send him my delegate to inform me through him :)