Following Semantic Versioning conventions, TRON 4.0 introduces API-breaking changes.
This guide is provided in order to ease the transition of existing applications using previous versions to the latest APIs, as well as explain the design and structure of new and updated functionality.
- iOS 9.0+ / tvOS 9.0+ / macOS 10.11+ / watchOS 2.0+
- Xcode 8.3+/ Xcode 9.x
- Swift 3.1/3.2/4.0
- Compatibility with Xcode 8 / Xcode 9, as well as Swift 3.x/4.x
- Support for Codable protocol in Swift 4
- Improved Carthage support
- Miscellaneous improvements
Both TRON 3.x and 4.0 have the same interface for creating request objects:
func request<Model, ErrorModel, Serializer: ErrorHandlingDataResponseSerializerProtocol>
(_ path: String, responseSerializer : Serializer) -> APIRequest<Model,ErrorModel>
where Serializer.SerializedObject == Model, Serializer.SerializedError == ErrorModel
/// Usage
let request : APIRequest<Foo,Error> = tron.request("path", responseSerializer: CustomResponseSerializer())This is rather verbose, so in TRON 3.x there was a shortcut, if you used SwiftyJSON as a default mapper:
func request<Model: JSONDecodable, ErrorModel:JSONDecodable>(_ path: String) -> APIRequest<Model,ErrorModel>
{
return APIRequest(path: path, tron: self, responseSerializer: JSONDecodableParser())
}
/// Usage:
let request : APIRequest<JSONDecodableFoo,Error> = tron.request("path")The problem with this approach in Swift 3 is if you try to define more extensions like this, Swift compiler is unable to understand, which extension you are trying to use, and throws a compiler error. In Swift 4 this became even worse, because compiler does not complain anymore, code compiles successfully, but method is then chosen randomly. Both of those options do not look good at all.
So now, in TRON 4.0, those methods no longer extend TRON, and instead they are written on Serializer instance. So new way of getting SwiftyJSON model parsed would be as follows:
let request : APIRequest<JSONDecodableFoo,Error> = tron.swiftyJSON.request("path")This change is huge and will break a lot of code, and we did not make this change lightheartedly. However it's better to completely break something in major release than carry on with compiler errors and potential undefined behavior. If you have ideas how those methods could be improved, please open PR or issue on GitHub.
New syntax for requests also allowed to introduce some parser customizations. For example, SwiftyJSON extension now allows specifying JSONSerialization.ReadingOptions to use while creating objects from Data:
let request = tron.swiftyJSON(readingOptions: .allowFragments)This example is partucularly important, because SwiftyJSON 4 now uses no .ReadingOptions by default, while previously .allowFragments was the default one. This is a breaking change for both SwiftyJSON and TRON and needs to be taken into account, while migrating.
Codable extension in similar fashion allows customizing both Model and ErrorModel decoder customization:
let request = tron.codable(modelDecoder: modelDecoder, errorDecoder: errorDecoder)Swift 4 introduces new way of coding and decoding your data models. Support for Codable is built-in in TRON 4.0 release. To use Codable protocol for your data model, simply conform it to Codable protocol and create a request:
let request : APIRequest<CodableFoo,Error> = tron.codable.request("path")Starting with 4.x release, prebuilt binaries will be now made available as a part of GitHub release for TRON.
Prebuilt binaries will only be compiled using latest version of compiler, so for example for Xcode 9.0 it will be Swift 4.0 compiler.
Also, to reduce project complexity, 4 framework targets have been merged into single target, using universal frameworks.
NetworkActivityPlugin now always dispatches access to UIApplication to main thread. This change is very important, so it was backported to 3.1.1 release.
APIError now conforms to LocalizedError protocol, and is able to take it's localized description from errorModel of error property.