A protocol to serialize Swift structs and classes for encoding and decoding.

Added support for tvOS, watchOS, and OSX.

Part of this required separating all of the HexInitializable code into a separate file, so that it could be excluded from the OSX target

I want to update Travis to use Xcode 8.3 and to also build the example project on the lowest supported target.

Since I need to actually open a PR to see if this works, this PR is work in progress until further notice, so don't merge it yet

• [x] mention that it was previously known as Serializable
• [x] update the requirements to mention macOS/tvOS/watchOS
• [x] update the code examples in the README to be Swift 3
• [x] maybe mention older versions support in requirements (like in Installation - Carthage)

There are some bad APIs that return 200, but in the response JSON they return a status code that indicates an error.

It would be nice to have a way of manually checking for that and go to failure if necessary. In the example above, if ReturnCode is different than 0, the Failure case would be called and not the Success one (in the current implementation, it goes to Success).

Maybe returning nil in the Unwrapper should make it go to Failure instead of Success with the empty model.

I'm not sure if we're ready to break everyone's cartfiles yet, but we should coordinate across the other frameworks as well.

The master/dev branches do not have any features that swift-3.0 doesn't; the most recent commits to those are just updating to swift 2.3 and fixing travis. swift-3.0 has newer fixes and updates.

Serpent is still using the old comment style, which is no longer recommended by Apple, so we should switch to the new standard (/// on each line).

There's also some indentation issues in the project, which should be fixed. (maybe we could implement SwiftLint?)

Serializable saves it as a NSURL when encoding, resulting in the parser not parsing it correctly when deserialising from disk (Looks like it enters the mapped overload for StringInitializable and fails when it gets out a NSURL instead of a String)

This might be useful in cases where we don't need to parse a whole nested object and just care about one value.

For example:

JSON

{
    "name": "Your name",
    "times": {
        "createdAt": "some time",
        "updatedAt": "some time",
        "deletedAt": "some time"
    }
}

Model

struct User {
    var name = ""
    var createdAt = Date() // <-times/createdAt
}

This will force people to specify an unwrapper manually and prevent issues with a global "magic" unwrapper.

To imagine an example where this is problematic take Module A, where responseSerializable(completion) is called with no unwrapper and expects to receive whatever was passed in. Then Module B changes the Parser.defaultUnwrapper to something needed for itself. Module A does same action with the responseSerializable and now fails because the Parser was changed without it's knowledge.

Only workaround this issue for now was to manully specify the unwrapper everywhere, which in turn eliminates the need for the global unwrapper in the first place. This is a great example of why you should not use a global variable.

All Serializable related performance tests should be merged into develop and master.

Tests for comparing other frameworks against Serializable should be moved to a different repository, so that this one isn't cluttered.

This will also make sure that performance tests are run in each travis build, which should make it easier for us to spot regressions or improvements.

Serializable is seen as a mainly Objective-C repo. Renaming the Prebuild folder to Dependencies should make it be ignored when analysing language, according to https://github.com/github/linguist/blob/master/lib/linguist/vendor.yml

Add support for Swift.Codable that can be used with both Alamofire and URLSession

https://trello.com/c/6AUldeXS/99-codable-vs-serpent https://trello.com/c/iqT6jV2t/107-8-alamofire-vs-urlsession

Swift.Codable vs Serializable

Using Swift.Codable reduces quite a bit of the boiler plate code needed by our data struct's in ordeer to comply to Serializable.

With Swift.Codable, if the server response data contains matching keys with our variable names, the only code needed to conform to Swift.Codable is:

import Foundation

struct CategoryItem: Codable {
    var title = ""
    var id = ""
}

while if the variable names do not match conforming to Swift.Codable is done as follows:

import Foundation

struct CategoryItem: Codable {
    var title = ""
    var id = ""
        
    init(from decoder: Decoder) throws {
        let map = try decoder.container(keyedBy: CodingKeys.self)
        self.id = try map.decode(String.self, forKey: .id)
        self.title = try map.decode(String.self, forKey: .title)
    }
    
    private enum CodingKeys: String, CodingKey {
        case id
        case title
    }
}

when trying to Swift.Decode or Swift.Encode optionals we should do them by using try? instead of try :

import Foundation

struct CategoryItem: Codable {
    var title: String?
    var id = ""
       
    init(from decoder: Decoder) throws {
        let map = try decoder.container(keyedBy: CodingKeys.self)
        self.id = try map.decode(String.self, forKey: .id)
        self.title = try? map.decode(String.self, forKey: .title)
    }
    
    func encode(to encoder: Encoder) throws {
        var container = encoder.container(keyedBy: CodingKeys.self)
        try container.encode (id, forKey: .id)
        try? container.encode (title, forKey: .title)
    }
    
    private enum CodingKeys: String, CodingKey {
        case id
        case title
    }
}

As well we can use an Enum and conform it to Codable

enum Type: String, Codable {}

If needed Decoding an Enum can be done like this:

enumVar =  try map.decode(Type.self, forKey: .enumVar)

Swift.Codable and URLSession

Opening a dataTask with URLSession and decoding the data can be done fairly easy now by doing the following:

guard let urlComponent = urlComponent, let url = urlComponent.url?.appendingPathComponent("breaking") else { return } let dataTask = urlSession.dataTask(with: url, completionHandler: urlSession.decode(completion)) dataTask.resume()

where urlComponent is of type URLComponents? and urlSession.decode(completion) is introduced in the upcoming Pull Request. As the completion parameter we can pass a DResult<Value>, where Value is a Generic Type and can contain stand alone objects or Arrays of objects.

Also in order to facilitate the paginated requests there is added a DPaginatedResponse (DecodedPaginatedResponse) that can be added in the completion as follow: completion: @escaping (DResult<DPaginatedResponse<Value>>)

Pull Requst: https://github.com/nodes-ios/Serpent/pull/167

enum Attribute: String { case one = "15" case two = "19" case three = "" }

struct MyStructType { var myArray = [Attribute.one] }

extension MyStructType: Serializable { init(dictionary: NSDictionary?) { myArray <== (self, dictionary, "myArray") }

func encodableRepresentation() -> NSCoding {
    let dict = NSMutableDictionary()
    (dict, "myArray") <== myArray // myArray.map({ $0.encodableRepresentation() }) seems to fix it
    return dict
}

}

func shouldTriggerCrash() { let theInstance = MyStructType() Cashier.defaultCache().setSerializable(theInstance, forKey: rideContainerCacheKey)//Crashes }

I ran Jazzy locally on Serpent, and it looks like the documentation percentage is not very high. This is about documentation for functions that the users don't actually access, but still, for completeness and quality, we should document those too.