Long Story Short: Codable Protocols
As developers, I’m sure we all have been in a place where we’ve had to deal with JSON in our lives. In my previous article, I detailed out how to deal with networking in Swift. Although the pattern discussed in the previous article still works excellently, we relied heavily on the
JSONSerialization class to convert data back and forth to JSON.
With Swift 4, there are three fancy protocols that we could leverage to build a better model to deal with networking data:
Encodable Protocol - defines a type that can be encoded into another form/representation for instance, JSON.
Decodable Protocol - defines a type that can be decoded from another representation into a native Swift type.
Codable Protocol - simply is a wrapper over Encodable and Decodable Protocols, and represents a type that can both be encoded and decoded.
In this section, we will discuss the concepts behind the Codable Protocols, using the example from the previous article:
Looking at the data, we realise that we could have two types to model this:
Swift 4 makes it easier to make types codable. As long as the type declares its properties using types that are already codable, by simply adding
Codable to the inheritance list on the definition it triggers the conformance to Codable automatically.
This means the type now can be encoded/decoded using a
JSONEncoder or a
PropertyListEncoder to encode and decode by itself, even though we didn’t have to implement anything for it.
The types that are natively codable include:
And as long as the elements they contain are Codable, the following types can also be considered as Codable:
In the above example, we’ve declared both our types as Codable and the automatic conformance is triggered without having to implement anything more because we simply are trying to encode/decode types that are already Codable.
Now that our types are
Codable, we can now get to the exciting part, trying to encode our type into say, JSON.
To encode the
Movie type into JSON. We use an instance of
Since the properties already conform to Codable, we were able to use the encoder directly to encode the movie.
encodedMovie contains the encoded data, typically as
Data, we can see how we could possible decode this into native movie type:
Codable types, can optionally specify an
CodingKeys that conforms to
CodingKey protocol. When this particular
enum is present, the cases specified are the list of properties that are included when the type is encoded or decoded.
Doin’ it manually
Things aren’t always nice. They’re not always easy. You may often find yourself in a place where your Swift type has a different structure than the JSON you have to deal with. In such cases the way to go is:
- Let Swift know about the structure of your encoded form
- Implement an init on the type reflecting the structure of the JSON or the encoded form
Assuming we have a property called
Movie which in JSON is nested like:
Because our JSON data contains a second level of nested information for the rating property, the type’s
Codable protocol use two enumerations that each list the coding keys on a particular level.
We can extend the
Movie type to reflect this structure by using two enumerations to list the Coding Keys used on each level.
To be able to support
Decodable for our data with a nested structure, we can extend the
Movie to conform to
Decodable by implementing its initialiser:
That should take care of decoding nested data from JSON.
Codable Protocols are very handly, and make dealing with an API a little easier, so the next time you’re looking to work with an API, give Codable Protocols a shot.
Feel free to leave any feedback, or questions behind!