We commonly say that you should only use libraries that you thoroughly understand but we rarely take the time to really dig into those libraries to see how they work. How exactly does Alamofire use a URLRequest or a URL String to make a network call?
It’s been a while since I wrote the previous tutorial. There are a few reasons for that but a big one is that I didn’t feel confident writing about Codable yet. It took a long time but I finally figured out why I was finding it so difficult. Often it just works but when it doesn’t you suddenly have to write a ton of not very obvious code, sometimes even to handle the stuff that was already working.
With more experience, I’m finding better ways to avoid writing as much custom code, like making the types for individual properties Codable instead of writing custom code for the top-level Codable item in my JSON. Like any language feature, it has some pros and cons so I didn’t want to just say “it’s great, use it all the time”. Now that I’ve had a chance to use Codable for varying projects, I’m comfortable making recommendations and writing up examples. Today we’ll look at handling Codable items in Alamofire responses.
Completion handlers can be a bit tough to wrap your head around when you first encounter them. Here are a few of the most frequently asked questions about completion handlers that I see from newer Swift developers.
Swift 4 includes a new way to generate & parse JSON using the Codable protocol. It’ll get rid of some boilerplate, especially when the objects or structs in our code have a similar structure to the JSON that we use to talk to a web service. In many cases you’ll be able to avoid writing any code that explicitly parses or generates JSON, even if your Swift structs don’t exactly match the JSON structure. That means no more long, ugly toJSON() or init?(json: [String: Any]) functions.
Codable can also replace use of NSCoding when we want to serialize objects to write them to a file and read them back again. It can work with plists as easily as JSON and you can write your own custom encoders & decoders for different formats.
Today let’s look at the simple case of converting an object or struct in our code to & from JSON. Then we’ll see how it might be more complicated when the JSON doesn’t match the objects & structs that we’re using in our code. We’ll use structs below but everything is the same if you need to use classes.
I previously wrote about adding custom headers to Alamofire 3 calls. Let’s figure out how to handle custom headers in Swift 3 and Alamofire 4.
When dealing with custom headers in Alamofire requests you might need to include a header for all of your API calls or just for a single call. We’ll show how to handle both of those scenarios and the four different ways that headers can be included in Alamofire calls.
The custom headers we set up previously were an API key and JSON accept header for the Mashape API:
Got a Swift project using Alamofire that needs to be migrated to Swift 3.0? Then you’ve probably figured out just how painful it can be if you try to just run the Xcode migration tool and figure out all of the errors. Changes to both Swift and Alamofire can make it tough to know just how to update those calls. So let’s look at a few common types of the Alamofire calls in Swift 2.2 and see how we can update them for Swift 3.0.
Then we’ll figure out how to create strongly typed objects in our code so that we’re not stuck passing JSON around everywhere.
Now that Xcode 8 is really here, it’s about time we thought about updating some of our code to Swift 3.0. If you’ve started migrating to Swift 3.0 you know it can be a real pain. I’ve got plans to update a bunch of posts but let’s start with the simplest stuff: Making networking calls using NSURLSession and parsing the resulting JSON.
The first thing you need to know is that it’s not called NSURLSession anymore. In an effort to streamline our code (and make everything harder to google), tons of NS prefixes have been removed in Swift 3.0.
Lots of web APIs give us dates but coercing them into a usable format can be a pain. We get something in our JSON like "2014-12-10T16:44:31.486000Z" or even just 1464192120 but we certainly can’t display those kinds of values to users. Today we’ll look at how to convert the dates that we get from APIs into Date objects then how to get nice display strings from those Date objects.
Did you know you can add IBOutlets & IBActions in Xcode without ever typing IBOutlet or IBAction? Here’s how to drag & drop connections from your storyboards to get Xcode to generate the code.
Read on →Previously we used NSURLSession data tasks to make some REST requests to a web service. Today let’s clean that up by building a higher layer of abstraction by mapping the JSON to a strongly-typed class.
Read on →
Grok Swift