Bolts – Get The Bolts Sample App

Transcript

Tap on time to skip ahead

00:11

I want to talk about how I use Bolts in my sample application. If you head over to GitHub, if you’ve not already done so, my repository for this particular application is LolBookofChampions-ios-sqlite. Feel free to go ahead and grab it. I have other videos on how to get it set up. Go grab that or look at the code here in my Github repo when I’m referencing how I integrated Bolts with this application.

00:40

Let’s go ahead and open up Xcode for the LolBookofChampions application. I referenced Bolts as a- from Cocoapods. As we can see here, I have in my pod file, a reference to Bolts version 1.1.5. All you have to do is run Pod Install from the command line and Cocoapods will make sure that it downloads and builds the Bolts framework into your application.

01:16

Personally, I find promises to be the preferred way of interacting with asynchronous code. I also, as you may know from watching my other videos, am a huge fan of the command pattern. I feel like Bolts and the command pattern are perfectly suited for one another.

01:40

One of the things that I said in my other videos that I didn’t care for is the fact that I named my commands Task. I think you’ll see why now when integrating with Bolts. Because Bolts also used the name Task to refer to a promise. In my opinion, it makes it a little bit confusing that my commands are called Tasks and I wish I had named my commands Command. This would have been called NIOQueryCommand. None the less, I used the word Task here and please don’t confuse that with a BFTask, which I’ll talk about in another video.

02:21

Let’s take a look at the core integration here. If we go to the Task folder of my core application module, I have a protocol called NIOTask. Again, this is a command. I have a simple, very simple, definition. Every command must implement the runAsync method and it returns a promise. Again, BFTask is a promise. I’ve put a stake in the ground and I’ve said every single command in my application when you call execute, which is runAsync, it will return to you a promise. That is the way you interact with every command in this application. Just call it and you’ll get back a promise.

03:11

If we take a quick look at all the commands in the application, starting with the app module. You’ll notice that all my commands are in the task folder, subfolder. And every single command has a runAsync method which returns a promise. So here’s the only command in the app module that’s called QueryTask. If I look in dataDragon, there’s also a task subfolder, there’s all kinds of different commands here. Each one of them declares a runAsync method that returns a promise. If I look at all the implementations, runAsync returns a promise. This is just the standard interface every command has in this application. Call a command, it runs asynchronously, you get back a promise. Here’s some internal task, same thing, runAsync gives back a promise.

04:09

It’s a very simple and consistent interface. It makes it easy for anybody that’s using my commands or executing them to understand how to interact with them and what they get back in return.