{"id":544,"date":"2014-08-31T10:41:49","date_gmt":"2014-08-31T16:41:49","guid":{"rendered":"http:\/\/dev.iachieved.it\/iachievedit\/?p=544"},"modified":"2016-09-18T08:11:26","modified_gmt":"2016-09-18T14:11:26","slug":"nsnotifications-with-userinfo-in-swift","status":"publish","type":"post","link":"https:\/\/dev.iachieved.it\/iachievedit\/nsnotifications-with-userinfo-in-swift\/","title":{"rendered":"NSNotifications with userInfo in Swift"},"content":{"rendered":"

Update 9\/18\/16:<\/b> Swift 3.0 has brough even more<\/i> changes to working with notifications and userInfo<\/code>; come visit our new article<\/a> on handling Notification<\/code>s with Swift 3.0<\/p>\n

Update:<\/b> Swift 2.2 has brought a number of changes; come visit our new article<\/a> on handling NSNotification userInfo<\/code> in Swift.<\/p>\n

I frequently sit down intent on writing about one topic, only finding myself in a situation where I feel motivated to write about something else. This is one such post.<\/p>\n

This morning I started with working on a HomeKit<\/a> application, only to take a detour to working with NSNotification<\/a>s in Swift. I’m going to make the assumption that you are already familiar with both NSNotification<\/code> and NSNotificationCenter<\/code>. I tend to use these a lot when programming applications that have a number of moving parts and threads. I may be doing it all wrong<\/i> and I’m sure there’s some pattern I’m missing out on, but the model of broadcasting events (notifications) to interested parties has served me well.<\/p>\n

Let’s look at the basic Swift method for getting a handle to the default notification center (I’m going to break my verbosity rule here and use nc<\/code> as the variable name rather than notificationCenter<\/code>):<\/p>\n

\nlet nc = NSNotificationCenter.defaultCenter()\n<\/pre>\n
Simple enough.  Now, I want to register my object (typically a view controller) for receiving a notification.<\/p>\n
\nnc.addObserver(self, selector: \"addHomeError\", name: kAddHomeError, object: nil)\n<\/pre>\n
In plain English, I’m telling the notification center to call my function<\/i> addHomeError<\/code> whenever someone posts a kAddHomeError<\/code> notification.  self<\/code> is the object to call and addHomeError<\/code> is the function.  Notice that the Objective-C @selector()<\/code> construct is gone in favor of naming the function as a string.  And of course kAddHomeError<\/code> is simply a constant string defined somewhere else.  In this case the definition is let kAddHomeError = \"AddHomeError\"<\/code>.<\/p>\n
In another object I can post my notification with:<\/p>\n
\nnc.postNotificationName(kAddHomeError, object: nil)\n<\/pre>\n
Since my first object registered to receive a notification when kAddHomeError<\/code> was posted, its addHomeError<\/code> function will be called.<\/p>\n
In both cases I’ve left the object<\/code> parameter nil<\/code>.  This parameter is applicable only if you want to distinguish between separate objects registering and posting notifications.  When specifying nil<\/code> in the addObserver<\/code> function you are saying, “Hey, I don’t care who<\/i> posts this notification, send it to me.”  If you provide an object to the object<\/code> parameter you are making a statement, “I’m only interested in notifications from this specific object.”<\/p>\n
In the above example our function we want called is addHomeError<\/code>, so we need to write it:<\/p>\n
\nfunc addHomeError() -> Void {\n  var alert = UIAlertController(title: \"HomeKit Wizard\", message: \"Unable to add home\", preferredStyle: UIAlertControllerStyle.Alert)\n  alert.addAction(UIAlertAction(title: \"OK\", style: UIAlertActionStyle.Default, handler: nil))\n  self.presentViewController(alert, animated: true, completion: nil)\n}\n<\/pre>\n
Given that I’m calling presentViewController<\/code> in our function, it’s a safe bet to assume that I’m handling receipt of the notification in a view controller.  So our notification comes from one object, and is handled in a view controller.  Straightforward.  What I don’t like though is the error message is Unable to add home<\/i>.  It would be nicer if the dialog indicated the name of the home it couldn’t add.<\/p>\n
We can accomplish that through the use of the userInfo<\/code> parameter when calling postNotificationName<\/code>.  It took a minute to figure out the function signature, because quite frankly it looks a little, well, non-obvious<\/a>.  Let’s take a look.<\/p>\n
\nfunc postNotificationName(_ notificationName: String,\n                   object notificationSender: AnyObject?,\n                 userInfo userInfo: [NSObject : AnyObject]?)\n<\/pre>\n
Perhaps you’re a quicker study than I am, but…  [NSObject : AnyObject]?<\/code>.  Huh? What? (No pun intended.)<\/p>\n
A glance back at the Objective-C signature for postNotificationName<\/code> and the lightbulb went off.  Or at least started glowing a little.  The userInfo<\/code> parameter in Objective-C is an NSDictionary<\/code> and it stands to reason Swift would be no different.  And it isn’t.  The signature syntax just looks strange.  Seriously though, all you need to do is pass in a dictionary where the keys are derived from NSObject<\/code> and the values are AnyObject<\/code>.  The question mark is just there to signify that this parameter could be nil<\/i>.<\/p>\n
Unlike earlier versions of Objective-C ([NSDictionary dictionaryWithObjectsAndKeys:]<\/code> anyone?), Swift comes out of the box with so-called “literal dictionaries,” a construct that other languages such as Python and Ruby call just dictionaries<\/i>.  So we don’t have to do any special dictionary-building to use userInfo<\/code>.  Our error notification can now be transformed into:<\/p>\n
\nnc.postNotificationName(kAddHomeError,\n                        object:nil,\n                        userInfo:[\"message\":\"Unable to add \\(homeName) Home\"])\n<\/pre>\n
We don’t have to limit ourself to a single-entry dictionary either:<\/p>\n
\nnc.postNotificationName(kAddHomeError, \n                        object:nil,\n                        userInfo:[\"message\":\"Unable to add \\(homeName) Home\",\n                                  \"details\":e.localizedDescription])\n<\/pre>\n
Now, let’s handle our notification.  The first thing we need to do is update our function to be passed the notification object which contains our userInfo<\/code>.  Recall the first version of the function had no arguments<\/i>, that is, we didn’t care about the NSNotification<\/code> object itself.<\/p>\n
Our method signature becomes func addHomeError(notification:NSNotification)<\/code>.  If we made this change now and ran our application it would most surely crash.  Why?  Because of this right here: 
\nnc.addObserver(self, selector: \"addHomeError<\/b>\", name: kAddHomeError, object: nil)<\/code>.  That selector definition indicates a function named addHomeError<\/code> which takes no arguments<\/i>.  We don’t have that anymore, we take one argument.  So you’re in for a unrecognized selector sent to instance<\/code> crash if you try that.  Update the selector to addHomeError:<\/code>:<\/p>\n
\nnc.addObserver(self, selector: \"addHomeError:\", name: kAddHomeError, object: nil)\n<\/pre>\n
Finally<\/i>, in our addHomeError<\/code> function, let’s unwrap our userInfo<\/code> dictionary and message.<\/p>\n
\n  func addHomeError(notification:NSNotification) {\n    \n    let userInfo:Dictionary = notification.userInfo as Dictionary\n    let messageString = userInfo[\"message\"]\n    \n    var alert = UIAlertController(title: \"HomeKit Wizard\", message: messageString, preferredStyle: UIAlertControllerStyle.Alert)\n    alert.addAction(UIAlertAction(title: \"OK\", style: UIAlertActionStyle.Default, handler: nil))\n    self.presentViewController(alert, animated: true, completion: nil)\n  }\n<\/pre>\n
Now perhaps there’s an easier way to do this, but, when receiving the userInfo<\/code>, the routine handling the notification doesn’t know what type of dictionary is there.  Recall that the only requirement was that it be of type [NSObject : AnyObject]?<\/code>.  So our code has to be a bit more explicit as what we know the dictionary to be, and that is of type [String : String!]<\/code>.  Once we’ve set the compiler straight, we obtain our messageString<\/code> and supply it to our UIAlertController<\/code>.<\/p>\n
Now we get a nice error message:<\/p>\n
With that out of the way I can get back to our upcoming article on HomeKit.<\/p>\n","protected":false},"excerpt":{"rendered":"
Update 9\/18\/16: Swift 3.0 has brough even more changes to working with notifications and userInfo; come visit our new article on handling Notifications with Swift 3.0 Update: Swift 2.2 has brought a number of changes; come visit our new article on handling NSNotification userInfo in Swift. I frequently sit down intent on writing about one […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,15,5],"tags":[],"class_list":["post-544","post","type-post","status-publish","format-standard","hentry","category-apple","category-homekit","category-swift"],"_links":{"self":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/544"}],"collection":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/comments?post=544"}],"version-history":[{"count":25,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/544\/revisions"}],"predecessor-version":[{"id":2804,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/544\/revisions\/2804"}],"wp:attachment":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/media?parent=544"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/categories?post=544"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/tags?post=544"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\"image1\"<\/a><\/p>\n