What is JSONModel?

And what problem does it tempt to solve?

https://github.com/jsonmodel/jsonmodel

Transform JSON from/to Objective-C entity classes

{
  "id": 1,
  "name": "Lawrence",
  "friends": [
    {
      "id": 3,
      "name": "Michael"
    },
    {
      "id": 7,
      "name": "Davis"
    }
  ]
}

@interface User : JSONModel
@property (nonatomic) NSUInteger id;
@property (nonatomic) String *name;
@property (nonatomic) Optional<NSArray<User>> *friends;
@end

Code example

NSError *error;
User *user = [[User alloc] initWithString:jsonString error:&error];
NSDictionary *userDictionary = [user toDictionary];
String *stringifiedUser = [user toJSONString];

Why Use JSONModel?

It's natural!

Server & App Communication

• Server: HTTP Server
• App: Send HTTP Requests and Get Responses

• Server: RESTful Server with JSON contents
• App: Use AFNetworking/Alamofire and JSONModel

We need fast serialization/de-serialization for JSON

See Common parts?

• Write mapping logics in the implemented method body and you're good to go!

• Write mapping logics in the implemented method body and you're good to go!

Why do we need to write additional mapping logics? Unlike JSONModel, which only requires defining our @property name well?

Back to Swift, what JSONModel alternative library features do we want?

1. Convenience

• As less encode/decode codes as possible
• Less code = less chance to get things wrong (typo, API change, etc.)
• JSONModel is the most ideal form: define@propertyname and everything is set.

2. Customizable for non-default cases

• Only write additional codes when mapping does not fit in default cases
• Examples:
  • id(JSON) touserId(property name) mapping
  • Custom time formatting, e.g. Unix timestamp (JSON) toDateobjects
  • URL strings toNSURLobjects

3. Coupling and cohesion

• We want less coupling with other libraries
• For example, in ObjectMapper you must use ObjectMapper.Map instead of built-in NSDictionary to store raw JSON
• Can we use different libraries together for server-app HTTP connections without writing cross-library adapters?

Proposed architecture

Libraries we used

• Alamofire: Library for handling HTTP request/response
• Siesta: Build RESTful requests similar to Retrofit and Restangular
• SwiftyJSON: A JSON library with exellent error handling

Alamofire + Siesta

Use built-in extension to configure Siesta

let conf = URLSessionConfiguration.default
conf.timeoutIntervalForRequest = 60
conf.timeoutIntervalForResource = 60
self.service = Service(baseURL: "https://my.api.com/api/v1",
  useDefaultTransformers: true,
  networking: AlamofireProvider(configuration: conf))

Parse JSON with SwiftyJSON

self.onCompletion { responseInfo in
  switch responseInfo.response {
  case .success(let entity):
    let json: SwiftyJSON.JSON
    if let _json = entity.content as? SwiftyJSON.JSON {
      json = _json
    } else {
      json = SwiftyJSON.JSON(entity.content)
    }
    var ent = Siesta.Entity<SwiftyJSON.JSON>(content: json,
      contentType: entity.contentType)
    ent.headers = entity.headers
    ent.charset = entity.charset
    ent.timestamp = entity.timestamp
    o.onNext(ent)
  case .failure(let error):
    o.onError(self.parseLadderError(error) ?? error)
  }
  o.onCompleted()
}

Use SwiftyJSON as request body for Siesta

extension Resource {
  func swiftyJSONRequest(_ method: RequestMethod = .get,
    data: JSON? = nil) -> Request {
    if method != .get, let _data = data {
      return self.request(method, text: _data.stringify,
        contentType: "application/json")
    } else {
      return self.request(.get)
    }
  }
}

Object Mapper: map JSON to entity class

First attempt: use Mirror API

By utilizing Swift Mirror API, we can get object information in run-time:

let r = Mirror(reflecting: entity)
print(r.subjectType)
for child in r.children {
  if let label = child.label {
    print("key:  ", label)
  }
  print("value:", child.value)
}

struct User {
  var id: UInt64 = 0
  var name: String = ""
}

Limitaion

• Mirror API provides reflection mechanism, not dynamic object inspection like NSKeyValueCoding
• Thus, we can get entity properties dynamically, but cannot set values
• Swift mapping libraries eventually requires own mapping implementation to work, and the libraries try to make developers write as less codes as possible

protocol SwiftyJSONModel {
  init(from json: JSON)
  mutating func from(_ json: JSON)
}
 
struct User: SwiftyJSONModel {
  init(from json: JSON) {
    self.from(json)
  }
  mutating func from(_ json: JSON) {
    self.id = json["id"].uInt64Value
    self.name = json["name"].stringValue
  }
}

Usage example, combined with generic type class to ensure flexibility

class ResponseTransformer<T: SwiftyJSONModel> {
  static func transform(_ json: JSON) -> T {
    return T.self.init(from: json)
  }
}
 
let user = ResponseTransformer<User>.transform(json)

Pros and cons for this approach

Pros

• Compose with any libraries you like
• Add custom features as your need, e.g.
  • Inspect API-specific structures in mapper function
  • Use encode/decode implementations forUserDefaultsdirectly

Cons

• Heavily couples with JSON library
  • Solution: abstract the JSON library (like Unbox)
• Re-invent wheels?