An attach-and-forget library for your iOS Projects The Observer Pattern The Observer Patter (sometimes also called Notifications, Broadcast-Listener, or Publish-Subscribe pattern) is a communication style common in OOP languages, much like Delegation (useful on a Parent-Children relationship) and Blocks (useful on Concurrent/Asynchronous tasks). The concept is to enable objects to “listen” or “observe” data from a relatively unrelated source. Think: radio broadcast. The source of the analog signals simply broadcasts them on air, regardless of whether anything is listening. The receivers simply listens, regardless of whether a signal is actually being sent. The same relationship is to be considered when choosing this pattern for data communication. Signals Library I came across this awesome while looking for alternative methods to implement an Observer Pattern. I liked this one particularly because of its simple implementation. It basically goes like this: library Create a . Signal Object that Signal Object. Fire to that Signal Object from anywhere in your project. Subscribe Create a Signal Object Initialize a Signal Object and pass the data type of your broadcast ‘message’ as its parameter let onData = Signal<(data:NSData, error:NSError)>()let onProgress = Signal<Float>() that Signal Object Fire Simply call the method on your Signal Objects and it will broadcast your data to all of its subscribers. fire(_ data: T) func receivedData(receivedData:NSData, receivedError:NSError) {// Whenever appropriate, fire off any of the signalsself.onProgress.fire(1.0)self.onData.fire((data:receivedData, error:receivedError))} to that Signal Object Subscribe Subscribing to a Signal takes a closure with the data as parameters. It will be called whenever a data was fired. onProgress.subscribe(on: self) { (progress) inprint("Loading progress: \(progress*100)%")} onData.subscribe(on: self) { (data, error) in// Do something with the data} The “attach-and-forget” usage is also very cool as it removes the hassle of observing your object’s life cycles — avoiding memory leaks due to unbound listener bindings. If you want to read more on the Signals library, follow this for its official documentation. github link Exercise: A Mock Downloader App In this short tutorial, let me demonstrate the use of this library and pattern with a dummy “file downloader” app. This app is supposed to function like a download manager. CoreData and Asynchronous Tasks are huge topics on their own so we will skip those and implement a dummy download task. We’ll have them broadcast their ongoing tasks for any listeners you may need. programming Network Our target is literally this simple. To save you the hassle of doing all the boiler plate codes of creating a Tableview, Cells and Data Sources, I’ve created a starting project which you can download . here 1. Project Overview Okay, here’s a quick overview of our template project. We’ll be implementing a light MVP-MVVM design so expect the usual suspects (Views, Models, Presenters, Interactors, etc). Here we have a simple : DownloadViewController Simple and straightforward. It contains our tableView (plugged in via interface builder) and its datasource and delegate methods. It holds a set of two models, an array of and a dictionary of . These two automatically gets plugged in to our tableViewCells to present our download object’s name and download status if it’s currently being downloaded. DownloadableItems DownloadTasks The ViewController also follows a protocol, which gives us access to receiving data from our Presenter. PresenterDelegate Our here holds all the logic outside the view, and practically becomes the logical identity of our screen/scene/page. Presenter Presenter has three objects to fulfill its responsibility, objects that , , and . CanFetchItems CanDownloadItems CanBroadcastTasks For our dummy app, all of them will be fulfilled by dummy classes, of course. will be held by an ItemStore that provides an array of statically-generated objects. CanFetchItems will be fulfilled by a class with a dummy requestDownload(item:) method. CanDownloadItems For now this will be held by our , which will mock a download request by creating a — an object that can hold an item’s download progress. DownloadManager DownloadTask will be fulfilled by a class that holds a Signal object, specifically one that broadcasts a dictionary of . CanBroadcastTasks DownloadTasks In our case, this will be held (again), by our DownloadManager since this class will be the one initiating the downloads and managing their queue of tasks. Still following? :D Now let’s start coding. 2. Initiate the download task First we’ll be editing our DownloadManager’s requestDownload(item:) method: We’ll be creating a DownloadTask from the item and give it an initial progress value. To increment our download progress’s value asynchronously, we’ll be using a Timer schedule function which will be called at every 1/4 of a second. This updates our current task queue with each increment and removes it when the task is finished. 3. Broadcast the tasks Still in our DownloadManager, we’ll override the init() method to initiate a Timer schedule again, which will then continuously broadcast our queue of tasks. We’ll automate our broadcast here so we don’t spam our listeners with too many calls. Our broadcasts will be consistent ticks instead of automatic firing whenever an update has been made. 4. Listen to broadcasts Now that we have setup our broadcasters, let’s go back to our Presenter and start listening. In our Presenter’s viewDidLoad(), add the subscribe method so we can start listening immediately after our view gets loaded. Pass the callback’s returned to your Presenter’ . It will then be passed to your View’s , and subsequently presented to your user. Everything happens in somewhat a reactive manner. tasks tasks tasks Run the code now, and you should be able to get something like this: Didn’t run? Grab a copy of the final project and see if you got everything right. here What’s Next? Well. Now that you have a working pattern implementation, try to have more Observers by adding another ViewController and Presenter. This time, with a TableView, try to show all the working DownloadTasks only Have fun! Before you get too comfy.. A few remarks about the topic: The Observer Pattern is a good option to avoid a lot of relationship complications (like too much delegations and callback-ceptions). It can still be abused. Here are some to remember when broadcasting your objects: Don’ts 1. Overbroadcasting updates with little significance I guess we can say that spamming is part of the nature of this pattern. Still, be mindful about the scalability of your implementation and the fact that you are running on a limited hardware. In our example, I placed the broadcast call outside the actual items update methods and into a dedicated timer. When you have hundreds of ongoing downloads, this would mean you would be broadcasting hundreds or thousands of download progresses per second. This could potentially clog your Main Thread with unnecessary update calls to your views and drastically impair the usability of your app. When implementing this design, . try to keep the pace as minimal as necessary 2. Ruining your architecture for convenience It’s tempting. You could be directly listening for broadcasts from your View Layer, past your Presenters, because you can. With this, you can just update your view without the Presenter knowing. But if we do this, we would violate the concept of MVP. Our View starts to manage its own business models and our Presenter starts to lose control over the View. If the Presenter receives an update, it can’t be sure if its data is consistent with the ones presented on the View. When integrating this pattern, be mindful of your architecture standards and don’t let the convenience override your own rules. You made it all the way here! I hope that you got what you’re looking for when you opened this article. If so, I would very much appreciate it if you would recommend this to your friends ^^ if you have any more questions/feedbacks, please feel free to drop a ! message
