The right way to Make Swift Codable Protocol Even Extra Helpful – Grape Up
It’s onerous to think about trendy Swift iOS software that doesn’t work with a number of knowledge sources like servers, native cache DB, and so on, or doesn’t parse/convert knowledge between totally different codecs. Whereas Swift Codable protocol is a superb resolution for this objective it additionally has some necessary drawbacks when creating a posh app that offers with a number of knowledge codecs. From this text, you’ll know easy methods to enhance the Swift Codable mechanism and why it’s necessary.
Swift has an awesome function for encoding/decoding knowledge in key-value codecs known as Coding protocol. That’s, you might select to retailer knowledge in e.g. JSON format or plist by at minimal simply defining names of the keys for which the corresponding values must be saved.
Benefits and Disadvantages of Swift Codable protocol
Listed below are some great benefits of Codable protocol:
1) Sort security. You don’t want typecasting or parsing the strings learn from the file. Swift does for you all of the low-level studying and parsing solely returning you a prepared to make use of object of a concrete kind.
2) The Simplicity of utilization. At a minimal, you might simply declare that your kind that must be encodable or decodable confirms to the corresponding protocol (both Codable or it’s components Decodable or Encodable). The compiler will match the keys out of your knowledge (e.g., JSON) mechanically based mostly on the names of your kind’s properties. In case you want superior matching of keys’ names together with your kind’s properties (and in most actual life circumstances you want it), you might outline an enum CodingKeys that may do the mapping.
3) Extensibility. While you want some superior parsing, you might implement initialization and encoding strategies to parse/encode the info. This, for instance, permits you to decode a number of fields of JSON combining them right into a single worth or make some superior transformation earlier than assigning worth to your codable object’s property.
Regardless of its flexibility, the Codable strategy has a critical limitation. For real-life duties, it’s typically wanted to retailer the identical knowledge in a number of knowledge codecs on the identical time. For instance, knowledge coming from a server could also be saved domestically as a cache. Data about person account coming from the server is commonly saved domestically to maintain person register. At first look, the Swift Codable protocol could be completely used on this case. Nonetheless, the issue is that, as quickly as one knowledge supply modifications names of the keys for the saved values, the info gained’t be readable anymore by Codable object.
For instance let’s think about a state of affairs when an software will get person data for a person account from the server and shops it domestically for use when the app is relaunched. On this case, the correct resolution for parsing JSON knowledge from the server right into a mannequin object is to make use of Codable protocol. The best solution to retailer the article domestically could be to simply use Codable to encode the article (e.g. in plist format) and to retailer it domestically. However codable object will use a sure set of keys that’s outlined by server JSON discipline names in our instance. So if the server modifications names of the JSON fields it returns, we’ll have to alter Codable implementation to match the brand new fields’ names. So Codable implementation will use new keys to encode/decode knowledge. And because the identical implementation is used for native knowledge, as properly the person data that was beforehand saved domestically will develop into unreadable.
To generalize, if we’ve got a number of knowledge sources for a similar keyed knowledge, the Codable implementation will cease working as quickly as one of many knowledge sources modifications the names of the keys.
Approach with A number of Entities
Let’s see easy methods to enhance the Swift Codable protocol to correctly deal with such a state of affairs. We want a solution to encode/decode from every knowledge supply with out restriction to have the identical key names. To do it, we could write a mannequin object kind for every knowledge supply.
Again to our instance with server and native knowledge, we’ll have the next code:
// Server person data
struct ServerUserInfo: Codable {
let user_name: String
let email_address: String
let user_age: Int
}
// Native person data to retailer in Consumer Defaults
struct LocalUserInfo: Codable {
let USER_NAME: String
let EMAIL: String
let AGE: Int
}
So we’ve got two totally different constructions: one to encode/decode person data from server and the opposite to encode/decode knowledge for native utilization in Consumer Defaults. However semantically, this is similar entity. So code that works with such object ought to be capable of use any of the constructions above interchangeably. For this objective, we could declare the next protocol:
protocol UserInfo {
var userName: String { get }
var e mail: String { get }
var age: Int { get }
}
Every person data construction will then conform to the protocol:
extension LocalUserInfo: UserInfo {
var userName: String {
return USER_NAME
}
var e mail: String {
return EMAIL
}
var age: Int {
return AGE
}
}
extension ServerUserInfo: UserInfo {
var userName: String {
return user_name
}
var e mail: String {
return email_address
}
var age: Int {
return user_age
}
}
So, code that requires person data will use it through UserInfo protocol.
Such resolution is a really simple and straightforward to learn. Nonetheless, it requires a lot code. That’s, we’ve got to outline a separate construction for every format a specific entity could be encoded/decoded from. Moreover, we have to outline a protocol describing the entity and make all of the constructions conform to that protocol.
Approach with Variational Keys
Let’s discover one other strategy that may make it attainable to make use of a single construction to do the encoding/decoding from totally different key units for various codecs. Let’s additionally make this strategy preserve simplicity in its utilization. Clearly, we can’t have Coding keys certain to properties’ names as within the earlier strategy. This implies we’ll have to override init(from:) and encode(to:) strategies from Codable protocol. Under is a UserInfo construction outlined for coding in JSON format from our instance.
extension UserInfo: Codable {
personal enum Keys: String, CodingKey {
case userName = "user_name"
case e mail = "email_address"
case age = "user_age"
}
init(from decoder: Decoder) throws {
let container = strive decoder.container(keyedBy: Keys.self)
self.userName = strive container.decode(String.self, forKey: .userName)
self.e mail = strive container.decode(String.self, forKey: .e mail)
self.age = strive container.decode(Int.self, forKey: .age)
}
func encode(to encoder: Encoder) throws {
var container = encoder.container(keyedBy: Keys.self)
strive container.encode(userName, forKey: .userName)
strive container.encode(e mail, forKey: .e mail)
strive container.encode(age, forKey: .age)
}
}
In reality, to make the code above decode and encode one other knowledge format we solely want to alter the keys themselves. That’s, we’ve used easy enum conforming to the CodingKey protocol to outline the keys. Nonetheless, we could implement arbitrary kind conforming to the CodingKey protocol. For instance, we could select a construction. So, a specific occasion of a construction will symbolize the coding key utilized in calls to container.decode() or container.encode(). Whereas implementation will present data concerning the keys of a explicit knowledge format. The code of such construction is supplied beneath:
struct StringKey: CodingKey {
let stringValue: String
let intValue: Int?
init?(stringValue: String) {
self.intValue = nil
self.stringValue = stringValue
}
init?(intValue: Int) {
self.intValue = intValue
self.stringValue = "(intValue)"
}
}
So, the StringKey simply wraps a concrete key for a specific knowledge format. For instance, to decode userName from JSON, we’ll create the corresponding StringKey situations specifying JSON user_name discipline into init?(stringValue:) technique.
Now we have to discover a solution to outline key units for every knowledge kind. To every property from UserInfo, we’d like in some way assign keys that can be utilized to encode/decode the property’s worth. E.g. for property userName corresponds to user_name key for JSON and USER_NAME key for plist format. To symbolize every property, we could use Swift’s KeyPath kind. Additionally, we wish to retailer details about which knowledge format every key’s used for. Translating the above into code we’ll have the next:
enum CodingType {
case native
case distant
}
extension UserInfo {
static let keySet: [CodingType: [PartialKeyPath<UserInfo>: String]] = [
// for .plist stored locally
.local: [
Self.userName: "USER_NAME",
Self.email: "EMAIL",
Self.age: "AGE"
],
// for JSON acquired from server
.distant: [
Self.userName: "user_name",
Self.email: "email_address",
Self.age: "user_age"
]
]
}
To let the code inside init(from:) and encode(to:)strategies conscious of the decode/encode knowledge format we could use person data from Decoder/Encoder objects:
extension CodingUserInfoKey {
static var codingTypeKey = CodingUserInfoKey(rawValue: "CodingType")
}
...
let providedType = <both .native or .distant from CodingType enum>
let decoder = JSONDecoder()
if let typeKey = CodingUserInfoKey.codingTypeKey {
decoder.userInfo[typeKey] = providedType
}
When decoding/encoding, we’ll simply learn the worth from person data for CodingUserInfoKey.codingTypeKey key and decide the corresponding set of coding keys.
Let’s carry all of the above collectively and see how our code will appear like:
enum CodingError: Error {
case keyNotFound
case keySetNotFound
}
extension UserInfo: Codable {
static func codingKey(for keyPath: PartialKeyPath<Self>,
in keySet: [PartialKeyPath<Self>: String]) throws -> StringKey {
guard let worth = keySet[keyPath],
let codingKey = StringKey(stringValue: worth) else {
throw CodingError.keyNotFound
}
return codingKey
}
static func keySet(from userInfo: [CodingUserInfoKey: Any]) throws -> [PartialKeyPath<Self>: String] {
guard let typeKey = CodingUserInfoKey.codingTypeKey,
let kind = userInfo[typeKey] as? CodingType,
let keySet = Self.keySets[type] else {
throw CodingError.keySetNotFound
}
return keySet
}
init(from decoder: Decoder) throws {
let keySet = strive Self.keySet(from: decoder.userInfo)
let container = strive decoder.container(keyedBy: StringKey.self)
self.userName = strive container.decode(String.self, forKey: strive Self.codingKey(for: Self.userName,
in: keySet))
self.e mail = strive container.decode(String.self, forKey: strive Self.codingKey(for: Self.e mail,
in: keySet))
self.age = strive container.decode(Int.self, forKey: strive Self.codingKey(for: Self.age,
in: keySet))
}
func encode(to encoder: Encoder) throws {
let keySet = strive Self.keySet(from: encoder.userInfo)
var container = encoder.container(keyedBy: StringKey.self)
strive container.encode(userName, forKey: strive Self.codingKey(for: Self.userName,
in: keySet))
strive container.encode(e mail, forKey: strive Self.codingKey(for: Self.e mail,
in: keySet))
strive container.encode(age, forKey: strive Self.codingKey(for:
Self.age,
in: keySet))
}
}
Word we’ve added two helper static strategies: codingKey(for keyPath, in keySet) and keySet(from userInfo). Their utilization makes code of init(from:) and encode(to:) extra clear and simple.
Generalizing the Resolution
Let’s enhance the answer with coding key units we’ve developed to make it simpler and sooner to use. The answer has some boilerplate code for reworking KeyPath of the sort right into a coding key and selecting the actual key set. Additionally, encoding/ decoding code has a repeating name to codingKey(for keyPath, in keySet) that complicates the init(from:)and encode(to:) implementation and could be diminished.
First, we’ll extract serving to code into helper objects. It is going to be sufficient to simply use constructions for this objective:
personal protocol CodingKeyContainable {
associatedtype Coding
var keySet: [PartialKeyPath<Coding>: String] { get }
}
personal extension CodingKeyContainable {
func codingKey(for keyPath: PartialKeyPath<Coding>) throws -> StringKey {
guard let worth = keySet[keyPath], let codingKey = StringKey(stringValue: worth) else {
throw CodingError.keyNotFound
}
return codingKey
}
}
struct DecodingContainer<CodingType>: CodingKeyContainable {
fileprivate let keySet: [PartialKeyPath<CodingType>: String]
fileprivate let container: KeyedDecodingContainer<StringKey>
func decodeValue<PropertyType: Decodable>(for keyPath: KeyPath<CodingType, PropertyType>) throws -> PropertyType {
strive container.decode(PropertyType.self, forKey: strive codingKey(for: keyPath as PartialKeyPath<CodingType>))
}
}
struct EncodingContainer<CodingType>: CodingKeyContainable {
fileprivate let keySet: [PartialKeyPath<CodingType>: String]
fileprivate var container: KeyedEncodingContainer<StringKey>
mutating func encodeValue<PropertyType: Encodable>(_ worth: PropertyType, for keyPath: KeyPath<CodingType, PropertyType>) throws {
strive container.encode(worth, forKey: strive codingKey(for: keyPath as PartialKeyPath<CodingType>))
}
}
Protocol CodingKeyContainable simply helps us to reuse key set retrieving code in each constructions.
Now let’s outline our personal Decodable/Encodable-like protocols. It will enable us to cover all of the boilerplate code for getting the correct key set and making a decoder/encoder object within the default implementation of init(from:) and encode(to:) strategies. Then again, it’s going to enable us to simplify decoding/encoding the concrete values through the use of DecodingContainer and EncodingContainer constructions we’ve outlined above. One other necessary factor is that through the use of the protocols, we’ll additionally add the requirement of implementing:
static let keySet: [CodingType: [PartialKeyPath<UserInfo>: String]] by codable sorts for which we need to use the strategy with variational keys.
Listed below are our protocols:
// MARK: - Key Units
protocol VariableCodingKeys {
static var keySets: [CodingType: [PartialKeyPath<Self>: String]] { get }
}
personal extension VariableCodingKeys {
static func keySet(from userInfo: [CodingUserInfoKey: Any]) throws -> [PartialKeyPath<Self>: String] {
guard let typeKey = CodingUserInfoKey.codingTypeKey,
let kind = userInfo[typeKey] as? CodingType,
let keySet = Self.keySets[type] else {
throw CodingError.keySetNotFound
}
return keySet
}
}
// MARK: - VariablyDecodable
protocol VariablyDecodable: VariableCodingKeys, Decodable {
init(from decodingContainer: DecodingContainer<Self>) throws
}
extension VariablyDecodable {
init(from decoder: Decoder) throws {
let keySet = strive Self.keySet(from: decoder.userInfo)
let container = strive decoder.container(keyedBy: StringKey.self)
let decodingContainer = DecodingContainer<Self>(keySet: keySet, container: container)
strive self.init(from: decodingContainer)
}
}
// MARK: - VariablyEncodable
protocol VariablyEncodable: VariableCodingKeys, Encodable {
func encode(to encodingContainer: inout EncodingContainer<Self>) throws
}
extension VariablyEncodable {
func encode(to encoder: Encoder) throws {
let keySet = strive Self.keySet(from: encoder.userInfo)
let container = encoder.container(keyedBy: StringKey.self)
var encodingContainer = EncodingContainer<Self>(keySet: keySet, container: container)
strive self.encode(to: &encodingContainer)
}
}
typealias VariablyCodable = VariablyDecodable & VariablyEncodable
Let’s now rewrite our UserInfo construction to make it conform to newly outlined VariablyCodable protocol:
extension UserInfo: VariablyCodable {
static let keySets: [CodingType: [PartialKeyPath<UserInfo>: String]] = [
// for .plist stored locally
.local: [
Self.userName: "USER_NAME",
Self.email: "EMAIL",
Self.age: "AGE"
],
// for JSON acquired from server
.distant: [
Self.userName: "user_name",
Self.email: "email_address",
Self.age: "user_age"
]
]
init(from decodingContainer: DecodingContainer<UserInfo>) throws {
self.userName = strive decodingContainer.decodeValue(for: .userName)
self.e mail = strive decodingContainer.decodeValue(for: .e mail)
self.age = strive decodingContainer.decodeValue(for: .age)
}
func encode(to encodingContainer: inout EncodingContainer<UserInfo>) throws {
strive encodingContainer.encodeValue(userName, for: .userName)
strive encodingContainer.encodeValue(e mail, for: .e mail)
strive encodingContainer.encodeValue(age, for: .age)
}
}
That is the place a real energy of protocols comes. By conforming to VariablyCodable our kind mechanically turns into Codable. Furthermore, with none boilerplate code, we now have the flexibility to make use of totally different units of coding keys.
Going again to some great benefits of the Codable protocol we outlined firstly of the article, let’s verify which of them VariablyCodable has.
1) Sort security. Nothing modified right here evaluating to the Codable protocol. VariablyCodable protocol nonetheless makes use of concrete sorts with out involving any dynamic kind casting.
2) The simplicity of utilization. Right here we don’t have declarative type choice with enum describing keys and values. We at all times must implement init(from:) and encode(to:) strategies. Nonetheless, because the minimal implementation of the strategies is so easy and simple (every line simply decodes/encodes single property) that it’s corresponding to defining CodingKeys enum for the Codable protocol.
3) Extensibility. Right here we’ve got extra skills evaluating to the Codable protocol. Moreover to the flexibleness that may be achieved by implementing init(from:) and encode(to:) strategies, we’ve got additionally keySets map that gives a further layer of abstraction of coding keys.
Summary
We outlined two approaches to increase the conduct of the Codable protocol in Swift to have the ability to use a special set of keys for various knowledge codecs. The primary strategy implying separate sorts for every knowledge format works properly for easy circumstances when having two knowledge codecs and a single knowledge movement route (e.g. decoding solely). Nonetheless, in case your app has a number of knowledge sources and encodes/decodes arbitrarily between these codecs you might stick with strategy with VariablyCodable protocol. Whereas it wants extra code to be written firstly, as soon as carried out, you’ll achieve nice flexibility and extensibility in coding/decoding knowledge for any kind you want.
