Is it best practice to communicate an event or something similar (like successful login) through NSNotificationCenter or is there any other controlling mechanism you can recommend?
As for me I do not like to use NSNotificationCenter because it is overloaded with a big amount of system and custom events.
If you add a lot of observers to NSNotificationCenter, you should not forget to remove these observers, also sometimes it is difficult to know the sequence, in which observing methods will be called. Also NSNotificationCenter doesn't check or manage adding the same observer more than one time(it sometimes becomes a real trouble, when you addObserver not in the correct place).
So: Why just not create some LoginManager singleton which will contain all the needed data and manage all login behaviour? It will contain some data as : isAuthorithed, etc.. And of course if you need to implement Observer pattern, your singleton class can implement this in the same way as NSNotificationCenter
That depends on what the event is and what classes are likely to need to know about it. For login / logout notifications are a good option because many different classes may want to respond tithe event. That doesn't mean that you can't also have a delegate / block callback for use by the class which triggered the login.
Generally, notifications for general things that could be interesting to many classes and direct callbacks for specific events (and the instance which triggered the event).
Related
I have an existing project, in which we have built it using NSNotificationCenter. Now if i want to add rich notification to my app, should all the NSNotification calls be replaced by NSUserNotification?
Without replacing when i tried the notification service extension is never getting called for remote as well as local notification.
They are totally different. NSNotifications are used as a way to inform objects instances that something has happened in a decoupled way.
This is an implementation of the observer pattern, useful when you need to inform more objects (observers) that an event has happened and they can respond to that event.
NSUserNotifications are used as a way to inform the user that something as happened and is displayed in the NSUserNotificationCenter.
I am new to iOS. I have come to know about these two approaches for message passing but I am unable to choose between them.
Conceptually, a delegate is a helper or an object that does part of the work for some other object that it can't do by itself. Frequently there will be a protocol involved and the object that has a reference to the delegate expects it to behave in a predefined way or, at least, in a way that's specific to the needs of the calling class.
Example: All the methods defined for a UITableViewDelegate are specific to table activity.
Notifications are more about state changes. The object sending the notification doesn't need help to do its work, it just lets other objects know about a change in case they want to react. If nothing else cares about the change, that's OK.
Example: An object that receives a UIApplicationDidBecomeActiveNotification may do whatever the developer needs at that time, not just things related to the UIApplication.
Delegate Patterns are mostly used because of delegate Object knows in which class delegate methods are implement. Delegate Object contains the references for object of that Class where you want to perform you task.
In Notification Patterns , simply a notification is broadcast over the entire classes and each class is search for the observer methods implementations So it took more time to search observer methods as compare to Delegate pattern.
I have a situation where I need to share WCSession among multiple WKInterfaceControllers. Singleton approach won't work, once you set delegate to a class, all delegates in the other classes are invalidated. Scenario: interface A send and receive data, based on the data content, present interface B. Tap on interface B, will request and receive additional data. How would you share the WCSession between A and B ?
The other answer doesn't explain that an app-wide session would work.
You can use an app-wide WCSession singleton which would be available to all your interface controllers. You simply instantiate a session manager very early in the app life cycle, and let it be its own delegate.
Instead of trying to make each interface controller handle the session delegation (which won't work well), a session manager (singleton) can handle all the transfers for your interface controllers.
As mentioned in the other answer, you could then use notifications to let interested interface controllers know when their new data arrives.
Using a modular approach, such as a session or data manager, helps to keep such code out of a controller, where it really doesn't belong. It also makes it easier to test and utilize each module.
I won't repeat the code here, as there have already been several existing answers posted on Stack Overflow, as well as
articles on the web, which cover this technique in detail. For example:
Using WCSession with more than one ViewController
WatchConnectivity: Say Hello to WCSession
You'll often find these types of answers within narrower questions that ask how to share data between, say, a watch app and its complication controller.
Use NSNotification and listen for changes in all view controllers.
Ok so i have been trying to figure out how to do this for a while but i did not seem to find way to do it. Also i would like the proper way to do this.
A server that i have is sending notifications every 30 seconds to my device. Lets say i am in ViewController B, but the data that is received by the notification is ment to be displayed/used in ViewController A.
Lets say i received two notifications while i was in ViewController B. Then i navigate to ViewController A. How would i get it to display the most recent data that was received by the notification?
You should receive the notification in a (global) 3rd object that will store them, then when the VC A is displayed you'll easily retrive them from that object...
Follow the "shared instance" path used by many iOS classes (even if someone don't like it 'cause they read singletons are evil, I think this's the perfect case to use it).
You can solve it this way:
Create at startup your singleton class that will receive the notifications and keep them in a queue.
Add to the singleton methods to read/consume the notification queue.
From any class you need the data (i.e. your view controller) get the infos you need via the methods above.
This solution keep data manager (notification handling) and presentation (the view controller) separated, I don't see any real cons...
Again, I know singletons have a bad reputation (and often people abuse of this pattern) but you know Apple's NSNotificationCenter have a +defaultCenter class method that return the shared instance (another word for singleton) so I'm quite sure this's the case to use it.
here http://www.daveoncode.com/2011/12/19/fundamental-ios-design-patterns-sharedinstance-singleton-objective-c/ you can find a good example how to implement the +sharedInstance (or +defaultCenter or whatever you want to call it) method.
Hope this help.
So I have two view controllers. One has autocomplete for location search, and all it does is let the user use the google places api to get an address. The other lets the user do a keyword search and actually displays results in a table view(with a custom uitablecell).
I want to make it so that the I can take the address from one view controller, execute a search and use the code that draws the table in the other controller to draw my results.
In other words, I'm looking for a way for one view controller to trigger a message and the other view controller to listen.
Is there a way to do this?
When there are more than one receiver, use Notifications. We can set only one delegate.
When to use NSNotificationCenter Checklist:
You need a one-to-many relationships. You need few observers to react on a particular notification. Example: reachability notifications. When your network reachability changes, e.g. wi-fi becomes unavailable, all of the objects subscribed to this type of notifications will receive them and can process accordingly.
By design you encourage loose coupling. In the example above, producer that sends a ‘reachability changed’ notification doesn’t know anything about possible observers of this notifications. There could be few of them or none. Same true for observers, they don’t need to know anything about producers of this notification.
When to use Delegates Checklist:
Delegates should always be used only for one-to-one relationships.
Use delegates if you encourage tight coupling. Bear in mind, by using delegates you create more interdependency between objects and have more coordination with information flow.
A very good example of delegates would be UITableView. UITable ViewDelegate encourages more information flow and creates more interdependency between view controller and table view.
Here is what you need
Notification or Delegate
link 2