Hassle-free JSON encoding and decoding in Swift

My workaround:

For example: CGAffineTransform

extension JSONEncoder {
    func encode(value: CGAffineTransform, key: String) {
        object[key] = NSValue(CGAffineTransform: value)
    }
}

extension JSONDecoder {
    func decode(key: String) throws -> CGAffineTransform {
        guard let value = get(key) else {
            throw JSONDecodableError.MissingTypeError(key: key)
        }
        guard let compatible = value as? NSValue else {
            throw JSONDecodableError.IncompatibleTypeError(key: key, elementType: value.dynamicType, expectedType: NSValue.self)
        }
        guard let type = String.fromCString(compatible.objCType) where type.containsString("CGAffineTransform") else {
            throw JSONDecodableError.IncompatibleTypeError(key: key, elementType: value.dynamicType, expectedType: CGAffineTransform.self)
        }
        return compatible.CGAffineTransformValue()
    }
}

But the object is internal and get() is private, So I have to change the source code.Would you consider add these pattern in the source code? I can make a pull request. But I think maybe there is a more elegant solution.

The protocol extension for JSONDecodable with the failable initializer init?(JSONString: String) produce the following error message: ... Cannot find an initializer for type 'UserState' that accepts an argument list of type '(JSONString: String)' ...

To reproduce this I added the following code at the end of the Playground

do {
    let jsonString = try user.JSONString()
    if let user_the_same = User(JSONString: jsonString) {
        print("Same User: \n\(user_the_same)")
    }
} catch {
     print("Error: \(error)")
}

To fix this I could add the complete failable initializer init?(JSONString: String) to the User structure declaration, but this is not how it should work.

Do you have any Idea?

Changes default transformers to static function to make use of Swift type inference

date = try decoder.decode("date", transformer: JSONTransformers.StringToNSDate)

becomes

date = try decoder.decode("date", transformer: .stringToDate())

This improves readability while extending this pattern is easy. Just create an extension on JSONTransformer for every custom transformer.

Hi,

First of all, thanks for sharing this amazing library.

I'm using some structs with UInt64 and that caused a compilation error indicating references to ambiguous decode functions.

My workaround was to extend JSONDecoder but this does not work too. Compilation works fine but it throws error while decoding.

private struct StorePromotionItem {
    let banner: String
    let icon: String
    var saleOptionId: UInt64?
    var productOfferId: UInt64?
}

extension StorePromotionItem: JSONDecodable {
    init(object: JSONObject) throws {
        let decoder = JSONDecoder(object: object)
        banner = try decoder.decode("banner")
        icon = try decoder.decode("icon")
        saleOptionId = try decoder.decode("sale_option_id")
        productOfferId = try decoder.decode("product_offer_id")
    }
}

extension JSONDecoder {
    public func decode(key: String) throws -> UInt64 {
        let JSONTransformerStringToUInt64 = JSONTransformer<String, UInt64>(
            decoding: {
                UInt64($0)
            },
            encoding: {
                String($0)
        })

        return try decode(key, transformer: JSONTransformerStringToUInt64)
    }
}

Thanks,

Hi, Right now the definition for JSONDecodable requires an implementation of an initializer. This has a couple of drawbacks IMO:

• Enums with associated values can't conform to JSONDecodable (see #29)
• For classes, JSONDecodable has to be conformed to in the main class declaration, not in an extension. This means that classes defined in ObjC can't conform to JSONDecodable in a Swift extension, for example.

My question is: what are opinions on a breaking change to moving to a definition of JSONDecodable that looks like this:

protocol JSONDecodable {
    static func parse(decoder: JSONDecoder) throws -> Self
}

I know that this would be a breaking change, but are there other reasons why this is a bad idea?

Line 57 in the file JSONDecodable will not compile anymore since it is not valid to have a non-failable initializer requirement be satisfied by a failable one.

https://developer.apple.com/library/mac/documentation/Swift/Conceptual/Swift_Programming_Language/Initialization.html#//apple_ref/doc/uid/TP40014097-CH18-ID224

Great library by the way !

• Removes all platform specific targets
• Creates a single target which supports iOS, macOS, tvOS, watchOS
• Adds Travis CI configuration
• • Travis currently runs at https://travis-ci.org/lightsprint09/JSONCodable
• • You have to create your own Travis CI instance when this is merged

Read this and this for more information on multiplatform schemes

For example:

struct model {
    let areas: [[Float]]
  }

 extension model: JSONDecodable {
    init(object: JSONObject) {
        do {
            let decoder = JSONDecoder(object: object)
            areas = try decoder.decode("areas")
            // Compiler error:  Ambiguous reference to member 'decode'
        }catch{
            fatalError("\(error)")
        }
    }

}

This allows for JSONDecoder extensions that allow the type system to better aid in decoding. For example, you could do:

extension JSONDecoder {
    public func decode(key: String) throws -> NSURL {
        return decode(key, JSONTransformers.StringToNSURL)
    }
}

then you only need to do:

try url = decoder.decode("url")

instead of

try url = decoder.decode("url", JSONTransformers.StringToNSURL)

And with the proper extensions setup, you never need to specify how to decode something at the call site unless there are multiple ways to decode a given type. As an example of a transformer that isn't built-in that we'd like this functionality for, we have a custom ID type that is convertible to/from a string, but don't want to have to manually specify the transformer each time we're decoding an ID.

Hi @matthewcheok,

Kudos for the library! I have just one question. Why is the initializer init?(JSONDictionary: JSONObject) a failable initializer rather than a throwing one? Sometime one might want the handle the error from the outside...

Thanks!

Is there any way to do this with the current release? I see that the JSONDecodable protocol declares a convenience init method for dictionaries, but what about for APIs that return an array as their root?

When i try to update my project to swift 5.0. I cant build with carthage with error: SWIFT_VERSION '3.0' is unsupported, supported versions are: 4.0, 4.2, 5.0. (in target 'JSONCodable iOS' from project 'JSONCodable')

Please update the library for support swift 5. Thank you very much!

I've bumped into a problem while using xcode9. Error I was getting was:

'JSONDecoder' is ambiguous for type lookup in this context

The only way to fix this is to put class in proper namespace by add prefix JSONCodable like JSONCodable.JSONDecoder, but there is a problem that compiler want to use protocol called the same, not lib name

the only idea I've figure out is to remove this protocol

JSONDecoder is now a part of Foundation on iOS 11 and there is no way to use JSONDecoder anymore because there are now two of them. I have a code that extends both JSONDecoder and JSONEncoder and both throw an error on Xcode 9 beta:

'JSONDecoder' is ambiguous for type lookup in this context

It seems like JSONCodable will have to prefix its classes.

Perhaps I'm missing something, but it doesn't seem like multi-dimensional arrays are supported with the JSONEncodable protocol. For example, this test fails:

class TwoDimensionalArrayClass: JSONEncodable {
    var array2D: [[String]]?
}

class JSONCodableTests: XCTestCase {
    
    func testTwoDimensionalArray() {

        let twoDim = TwoDimensionalArrayClass()
        twoDim.array2D = [["One", "Two", "Three"], ["Four", "Five", "Six"], ["Seven", "Eight", "Nine"]]
        
        do {
            try twoDim.toJSON()
        }
        catch {
            print(error)
            XCTFail()
        }
    }
}

Any help or suggestion would be greatly appreciated.