(This PR depends on #67.)

Different request performers are allowed to have different semantics when it comes to the queue that results are delivered on. If a performer already happens to deliver results on the main queue, APIClient is injecting latency by scheduling an unnecessary async call. If a performer delivers results on a background queue (i.e., NetworkRequestPerformer), and there's further processing that would benefit from occurring in the background (e.g., image processing or decoding a large object), callers must dispatch back onto a background queue to avoid blocking the UI. It also hampers composability of requests, because multiple chained requests will incur a penalty from jumping back and forth from the main queue to a background queue.

This breaking change removes the dispatc_async and leaves that decision to callers, as it's not possible to anticipate the correct decision to use in every situation.

This adds a transformError function to Request. This acts as a hook to be able to change the error from the NSError used by the lower level network clients and JSON parsing into a model more suitable for your application.

By default, we are still going to return NSErrors, but it's useful to have a hook for being able to model the network error response if you know what it looks like.

This maintains 100% backwards compatibility with the existing API.

Fixes #46

This pull request points Argo to the same change but using a different commit SHA.

This is to address the issue described here: https://github.com/Carthage/Carthage/issues/812#issuecomment-145303514

I think the root cause is the force push that happened here: https://github.com/thoughtbot/Argo/pull/237#issuecomment-144621084

I know that this project is still under development but I'd love to know some of the goals / guiding principles, and why someone might prefer Swish over one of the other networking libraries available.

Keep up the great work :+1:

This renames the existing iOS targets and adds the equivalent targets for Mac.

In the process, framework paths were made relative to the built products directory so that a single binary reference can be used for both targets.

Hi. I inherited a project that utilizes this awesome library, but I'm super new to it. I updated the dependencies to support Swift 2.2 and am now receiving a Segmentation fault: 11 and I can't quite find the issue.

Looking through the change logs here I have a feeling it has something to do with the result error type Result<AccessToken, NSError> and SwishError (and not using it properly)... but I'm not sure.

I tries a few different approaches but am hitting a wall.

This is the first file to fail, and the others like it fail to compile for the same reason. https://github.com/the-grid/Disc/blob/redirect_uri_email/Disc/Networking/Authorization/GetAccessToken.swift

If you have a moment, does anything shout out at you as something I should look at?

Thanks for the work on this library.

One of my projects is using Swish 2.0.3. I updated Xcode to 9.3 and I started to see a couple errors. It would be great to get a quick fix for Swish 2.0 out if possible. Unfortunately, we're not able to migrate to Swish 3.0 at this time. Here are the errors I'm seeing:

Swish/Source/Models/APIClient.swift:10:108: Struct 'JSONDeserializer' is internal and cannot be referenced from a default argument value

(can't use internal type in default arg)

and

Swish/Source/Protocols/Request.swift:29:21: Missing argument for parameter #1 in call

(needs another() inside .success())

I've forked and branched from what looked like a good point for 2.0: 4c9233c. I don't want to open a PR onto master here -- is there a good branch I could PR with these updates? My changes are here: https://github.com/gstro/Swish/tree/2.0-fixes . Could there be a 2.x release branch? Would love to have this updated on CocoaPods soon too.

The null data test and the empty data test were identical. In addition, the custom parse function in our empty request was duplicated, since we're providing it for free with an extension on Request.

After Encodable/Decodable landed in Swift and the removal of Argo as a dependency of this project, I feel like this codebase doesn't do all that much. It provides a little bit of structure and has some niceties, but I'm not sure I'd reach for it on my next project, for example. I don't think I'd like to spend any time maintaining the project going forward.

Curious what contributors past and present think - cc @sharplet @klaaspieter @gfontenot

Built off @sharplet's open PR for 2.3 support

Do the minimum set of changes to support Swift 3.

There are other improvements we can make like:

• using Any instead of AnyObject (JSONSerialization returns this now)
• Adopt a more Swify API by not ignoring so many first args.

Open question(s):

• Now that we have URLRequest, should we still support NSURLRequest and NSMutableURLRequest?

I have what might be a really silly question... The client that I'm working on until this point only queried endpoints that return JSON, and as it turns out I need a route on the API that just returns response codes and a string.

I have tried a few things and not been able to quite figure out how to handle an HTTP response that is not JSON, and I know this library is oriented toward JSON responses. Seems everything I have tried get's pushed down a path of trying to be parsed, which could just be an oversight on my part for sure.

Is there a clean approach to a non-JSON http response?

Hi,

The latest released version available via Swift Package Manager (4.0.0) doesn't contain all the commits available on the master branch. Could you please add tag 4.0.1 on commit 24f58c51a3b1b1b318bf863a781d74ac46add441 so Swish can be integrated via SPM using tag instead of commit hash?

Thanks

Adds a new extension to the Client protocol that allows two requests to be performed concurrently, with their results combined into a tuple:

perform(_: RequestA, _: RequestB, completionHandler: (Result<(ResponseA, ResponseB), SwishError>) -> Void)

If either fails, the other request is cancelled and the failure result is passed to the completion handler. A new Cancelable protocol allows cancelable things to be composed together (e.g., dispatch blocks and URL session tasks).

I plan to add some tests for the basic behaviours, especially around how cancellation is handled. I honestly am not sure how to write a test for the thread-safety aspects of this code, but I'm pretty sure all reads and writes to the combined state are appropriately synchronised. I'll do another review to make sure there's no race between updating the combined state and waiting on the request group to complete.

At this stage I've been using Alamofire's MultipartFormData class which seems pretty solid and has some nice abstractions.

It would be great for Swish to support this natively. I wonder if we should talk to the Alamofire folks about extracting their implementation into a separate repo, to avoid reinventing the wheel?

When Carthage checks out Swish into a project, it also recursively copies its submodules. This means that even if Carthage finds a more recent version of Result or Argo, when Swish is built it will always link against the version in the submodule.

If the app and Swish are linked against two different versions of the same dependency, the app may crash on launch when looking up symbols.

This change now ignores Cartfile.resolved, and stops using submodules, so that Swish can dynamically be linked against any compatible version that the app uses, rather than a specific submodule revision.