Responses and Serialization with Requests in Alamofire

In this lesson

In this Alamofire lesson, we will be talking through how to serialize the response data of your network requests easily into useable forms from its origin as NSData. You can even chain these serializations to manipulate and handle your data in different types for whatever works for your app!

Kyle's Series

Transcript

Tap on time to skip ahead

0:11

0:11

Hello world, Kyle here with brax.tv and we’re going to talk about how to in Alamofire evaluate the response of a request and serialize the attached data to another type. And there are a few types that are supported out of the box with Alamofire and we’ll cover those. So to actually run a request after you’ve created it, you want to recall one of the response serialization methods on request. And our options for those are data, JSON, image, which is actually from a plugin amusing called AlamofireImage, String, and somewhere there is PList, okay. So let’s just use data for example.

0:59

0:59

And the syntax of this is when calling response data, you’re actually going to start a closure there and we have a reference to a tuple that is defined in Alamofire, then we’ll just call response and from this response tuple object, we can access a few other properties that we would, you know, want to get access here. The objects in this tuple that we can access ,and there are four of them, and there’s even more stuff we can access out of that, but let’s just go over the important stuff. And to access them all, we’ll say response. and the first object in this tuple is request which actually returns not an Alamofire request like we have created here but an NSURLRequest associated with this whole request and response.

1:48

1:48

For the next one, response.response, which is as you probably saw when I was typing for code completion, it gives us access to the NSHTTPURLResponse object. And these two so far are things you would normally be able to, you know, easily access if you’re planning a URL request with sessionDataTask or something like that. But here’s where it gets interesting. To get access to the actual response data you’ll say response.data. When you run in NSURLRequest and there is data attached, it’s going to return it to you in the form of NSData and not necessarily the value that we were looking for. And even though we are running this is data serializer here, this is not the serialized data.

2:42

2:42

To access that, it brings us to a whole other hierarchy of references we can access with response.result. Response.result is usually used in some sort of validation as you can includ it in a switch statement like this to validate the success or failure of the block and they do have associated values with them. But to access the actual serialized data value, we use response.result.value. And since we are serializing it as NSData, its value is NSData. But if we wanted to change this to string, we can see with code completion that the value associated with the response that result is actually now a string and not the data.

3:33

3:33

The available serializations here are data, string, which we have both gone over, JSON, which – that was kinda weird – JSON, which the value is now an AnyObject, and Plist. I’m not sure how common using PList is but I have never used it in a URLRequest so let’s check out what the value is, AnyObject.

4:00

4:00

So something interesting or cool you can do you is if we go back to responseJSON and we run all of that, we can actually chain other response serializers to this. So what if we wanted to serialize our JSON to a string just to see what it looks like. Let’s just put in a new line. And as we can see here real quick, the type associated with the value object is string. So when this is run and the request completes, this closure is going to have access to the return value serialized as JSON, and this closure, without running the request again is going to serialize that same returned NSData into a string. So let’s just give this a run and see what happens.

4:54

4:54

Alrighty! So we’ve hit the first break point immediately before the app has even done anything since I run some requests right away. So I’ll skip over that one, we see that it has printed some JSON of some Steam apps straight to the log. Which is pretty cool. Now if we continue playback to our next breakpoint and then step over that, we’ll see this JSON printed and as a very unreadable string to the log. That’s not necessary in this case but there are times when you could run into it being useful to serialize your responses differently whether it’s just for log output for maybe one and save your data to a PList though work with it in code as a JSON file or a JSON object. It’s just up to you and the data that you’re working with.