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
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.Read on →
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:
- X-Mashape-Key: MY_API_KEY
- Accept: application/json
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.Read on →
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
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 →
Sometimes we read tutorials or books and the code seems like magic. It works but it’s really not clear why. Especially when it’s full of weird Swift stuff like enums and computed properties and pattern matching. It’s enough to make you want to curl up in bed and give up on programming altogether.
A reader pointed out recently that my Alamofire router code is guilty of showing fancy code with funky Swift features. And the blog post doesn’t make it clear what’s happening. So today I’ll make things right and we’ll figure out exactly how something like
Alamofire.request(TodoRouter.get(1)).responseJSON… actually works.
Previously we set up some REST API Calls With Alamofire. While it’s a bit of overkill for those simple calls we can improve our code by using an Alamofire router. The router will put together the URL requests for us which will avoid having URL strings throughout our code. A router can also be used to apply headers, e.g., for including an OAuth token or other authorization header.
Updated to Swift 3.1 and Alamofire 4.4.
Yes, I see the date on this post. But well organized code is no joke. Be nice to your future self by making it easy to understand and work with your code. You’ll thank yourself later.Read on →