Bolts – Executing async blocks with BFExecutor

In this lesson

BFExecutor is a Bolts class that helps you run blocks of code on specific dispatch_queues or NSOperationQueues.


Tap on time to skip ahead


The third class that you’re going to need to familiarize yourself with if you want to learn Bolt, is the Executor. BFExecutor is a class. It’s purpose is to run blocks of code on a specific thread. Executors work with either dispatch queues in Grand Central Dispatch or it can also work with NSOperationQueue. So whichever your preference is for concurrency, BFExecutor works with either.


Additionally, there’s a couple of standard executors that are already created for your use. One is the mainThreadExecutor. That allows you to run code in the main thread and you’ll use that a lot when you’re wanting to handle continuations in a UIViewController that manipulate the UI. There’s an ImmediateExecutor and a DefaultExecutor. I generally don’t use the last two that much but you can read all about it on the Bolts Wiki.


Let’s see how I use the Executor in the application. To do that, let’s head on over to the Champion View Controller, which is in the app module. ChampionCollectionViewController, and let’s look at the Query Champions Method. This method is used to query the database, the local database, for Champion data so that I can display the images and the Champion names alphabetically.


Here’s the actual task that is run. It’s a command. Notice that the continuation, that is when I get the query results back, I use the BFExecutor mainThreadExecutor to run this block of code on the main thread. When the query comes back, I actually handle it on the main thread using the BFExecutor, mainThreadExecutor.


Let’s dive in here to the query task. This actually delegates the query to something called the contentResolver. Let’s just have a look here. In most cases, when things run concurrently, if you’ve watched my other videos on concurrency, you’ll notice that this application follows a pattern where work is done on an execution using an execution queue on one thread and responses are delivered on something called a completion queue. On a different thread. That allows the execution queue to be as free as possible to do work and offload the work of delivering results to another thread. That’s what I follow here. I used Bolts Executor to accomplish that.


For here, I actually run the work on an execution queue using the Execution Executor, I’ll look in just a second up above where I created that so you can see how that works. And, I continue to deliver the results to the caller on the completion queue.


Let’s head up here to the property. These are just properties. These are just BFExecutor instance. There’s two in this class, one for execution and one for completion. If we look here at the initializer, I created an instance of an Executor using a DispatchQueue. Here I used the create completion executor with a DispatchQueue. These are just dispatch queue that I created elsewhere and I passed in on the initializer. BFExecutors can be created with DispatchQueue or NSOperationQueue. I’ve chosen this application to build around DispatchQueue, but if you prefer operation queue then you can use that as well.


Once you have your Executors then you can run your work on any cue that you choose. This is what I use in the application to offload all the work, as much work as possible, off of the main thread, so that it remains responsive to the user.