iOS NotificationCenter in a better way

A common pattern in app development is notifications (NSNotification and NotificationCenter). With notifications you can broadcast out messages to multiple listeners. This can be useful in many cases. A common example is if you have many UIViewControllers that all need to update on some model change.

However, I feel that the standard way of using NotificationCenter is error prone, complicated and verbose. I mostly use another approach, where you create your own version of NotificationCenter.

The normal way

First, an example on normal use of NotificationCenter:

Here we just use the standard APIs. We add an extension to Notification.Name for a bit smoother setup. But other that that, this is the default way to broadcast notifications. What I don’t like about this approach:

  • We use string literals. It feels old, bad and error prone.
  • We cast userInfo. The receiver needs to know the type of the payload. If we need to send more parameters we need to have more casting or string constants as keys.
  • The addObserver function is quite long and needs to be repeated for each listener.
  • We have to come up with names for the string literal, notification name variable and the callback method.

A better way?

The solution is quite straight forward. We create one optional func in our protocol for each type of notification. And we also create one function that broadcasts to all delegates.

NotificationManager is then stored in whatever place you prefer. If you want it as a singleton it can be done, but I prefer to have it as an instance somewhere.

And in Weak.swift we define a container for weak references. This is needed as normal arrays hold a strong reference to it’s elements.

And here is how you use NotificationManager:

As you can see, the setup becomes so much cleaner, one row for adding self as delegate, and one for removing. Then you extend your class and implement the optional functions of the NotificationDelegate protocol you want to listen to. That means that even if you listen to several notification you still need only that addDelegate one-liner as a setup!

The broadcasting becomes quite clean as well:

Here you can setup parameters in any way you want, no more casting from userInfo.

To summarize:

  • No more string literals
  • No more casting, we can pass along multiple typed parameters
  • The addDelegate function is super short and is only needed once per class
  • We still need to come up with two names, for the callback function and the corresponding function in NotificationManager, but I usually use the same

Hope you liked the solution. Let me know what you think in the comments. Can this perhaps be improved even further?

Some good blog posts for Swift/iOS

A good practice is to always keep your Storyboards small. Here is a good way of keeping your code for initializing Viewcontrollers from code:

https://medium.com/@gurdeep060289/clean-code-for-multiple-storyboards-c64eb679dbf6

I’ve totally missed that there are new literals to help you in Swift 3:

https://medium.com/@gurdeep060289/color-image-new-literals-in-the-cocoa-town-7ef4f2710194

I would also lite to recommend Soroush Khanlou’s blog on iOS development, a lot of good blog posts there:

http://khanlou.com/

Keeping your UIViewController clean in Swift

One of my biggest interest when it comes to coding is code quality and code structure. Code often grows complex over time and it can be hard not introducing bugs and making code that is difficult to refactor, maintain and read. A common issue I think many iOS developers have experienced is related to the UIViewController class. This class is very central when it comes to native iOS development. It handles the logic behind a single screen or parts of a screen displayed to the user. Also Apple does not provide any good guidance to avoid this.

I have based this post around the suggestions from this other blog post where the author discusses common bad practices with over-using the UIViewController:

http://doing-it-wrong.mikeweller.com/2013/06/ios-app-architecture-and-tdd-1.html

He lists a few common uses for the UIViewController which could be considered bad.

  1. View setup and custom layout code
  2. Core data code
  3. Delegate for everything
  4. Accessing global states (singletons)
  5. Navigation logic

I mostly agree with the author and want my classes and methods to be as small as possible as well as only have one single responsibility. iOS ViewControllers tend to become way to large and like the author says, if you do not put in effort to restructure and refactor your ViewControllers, your app will so only consist of enormous ViewControllers.

MVC Twitter link

 

A good starting point for anyone who wants smalled ViewControllers is to install the XCode Alcatraz plugin Luft which warns you (coloring the line number view red) when your ViewControllers get to big. I like the idea!

Continue reading

First blog post

This is the first blog entry of my new developer blog.

When I write this (july 2016) I have now been programming for mobile devices for nearly six years. Professionally for four years and as a freelance developer for five months. I thought it would be a good idea to write about my daily and past experience when it comes to apps, code, tools, hardware, jobs and starting a company.

// Jonas