Swish is a networking library that is particularly meant for requesting and decoding JSON via Decodable

Overview

Swish CircleCI Carthage compatible CocoaPods Compatible

Nothing but net(working).

Swish is a networking library that is particularly meant for requesting and decoding JSON via Decodable. It is protocol based, and so aims to be easy to test and customize.

Version Compatibility

Here is the current Swift compatibility breakdown:

Swift Version Swish Version
5.X >= 4.0.0
4.X >= 3.0.0
3.X > 2.0, < 3.0
2.X 1.X

Installation

Carthage

Add the following to your Cartfile:

github "thoughtbot/Swish"

Then run carthage update.

Follow the current instructions in Carthage's README for up to date installation instructions.

CocoaPods

Add the following to your Podfile:

pod 'Swish'

You will also need to make sure you're opting into using frameworks:

use_frameworks!

Then run pod install with CocoaPods 0.36 or newer.

Git Submodules

I guess you could do it this way if that's your thing.

Add this repo as a submodule, and add the Swish project file along with the dependency project files to your workspace. You can then link against Swish.framework along with the dependency frameworks for your application target.

Usage

Basic Playground

You can see an example of Swish in action via the included SwishExamples.playground.

To use that, clone this repository and run carthage bootstrap --platform iOS. When that finishes, open the Swish.xcworkspace and click the SwishExamples playground on the left.

Documentation

License

Swish is Copyright (c) 2019 thoughtbot, inc. It is free software, and may be redistributed under the terms specified in the LICENSE file.

About

thoughtbot

Swish is maintained and funded by thoughtbot, inc. The names and logos for thoughtbot are trademarks of thoughtbot, inc.

We love open source software! See our other projects or look at our product case studies and hire us to help build your iOS app.

Comments
  • Don't force completion blocks to be scheduled on the main queue

    Don't force completion blocks to be scheduled on the main queue

    (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.

    opened by sharplet 27
  • Add the ability to parse error objects

    Add the ability to parse error objects

    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

    opened by gfontenot 17
  • Update Argo.

    Update Argo.

    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

    opened by paulyoung 17
  • Why Swish?

    Why Swish?

    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:

    opened by paulyoung 12
  • Add Mac targets.

    Add Mac targets.

    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.

    opened by paulyoung 10
  • Segmentation fault: 11

    Segmentation fault: 11

    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.

    opened by nickvelloff 9
  • Errors on 2.0.3 with Xcode 9.3

    Errors on 2.0.3 with Xcode 9.3

    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.

    opened by gstro 8
  • Remove duplicate test

    Remove duplicate test

    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.

    opened by gfontenot 8
  • Deprecating Swish?

    Deprecating Swish?

    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

    opened by sidraval 7
  • Swift 3.0

    Swift 3.0

    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?
    opened by jakecraige 7
  • Responses that are not JSON

    Responses that are not JSON

    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?

    opened by nickvelloff 7
  • Release version 4.0.1

    Release version 4.0.1

    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

    opened by dregatos 0
  • Perform two requests concurrently and combine their results

    Perform two requests concurrently and combine their results

    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.

    opened by sharplet 1
  • Support multipart form data encoding

    Support multipart form data encoding

    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?

    opened by sharplet 0
  • Don't lock transitive dependencies using submodules

    Don't lock transitive dependencies using submodules

    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.

    opened by sharplet 7
Releases(4.0.0)
Owner
thoughtbot, inc.
We work with organizations of all sizes to design, develop, and grow their web and mobile products.
thoughtbot, inc.
This package is meant to make http request of an easy way inspiren in the architecture of Moya package

NetworkAgent This package is meant to make http request of an easy way inspiren in the architecture of Moya package. This package is 100% free of depe

Angel Rada 19 Sep 8, 2022
A network extension app to block a user input URI. Meant as a network extension filter proof of concept.

URIBlockNE A network extension app to block a user input URI. Meant as a network extension filter proof of concept. This is just a research effort to

Charles Edge 4 Nov 19, 2021
A Codable extension to decode arrays and to catch & log all decoding failures

SafeDecoder A Codable extension to decode arrays and to catch & log all decoding failures Features SafeDecoder makes two improvements for Codable mode

Idle Hands Apps 5 May 29, 2022
Elegantly connect to a JSON api. (Alamofire + Promises + JSON Parsing)

⚠ Important Notice: Farewell ws... hello Networking ! Networking is the next generation of the ws project. Think of it as ws 2.0 built for iOS13. It u

Fresh 352 Aug 18, 2022
QwikHttp is a robust, yet lightweight and simple to use HTTP networking library for iOS, tvOS and watchOS

QwikHttp is a robust, yet lightweight and simple to use HTTP networking library. It allows you to customize every aspect of your http requests within a single line of code, using a Builder style syntax to keep your code super clean.

Logan Sease 2 Mar 20, 2022
Asynchronous socket networking library for Mac and iOS

CocoaAsyncSocket CocoaAsyncSocket provides easy-to-use and powerful asynchronous socket libraries for macOS, iOS, and tvOS. The classes are described

Robbie Hanson 12.3k Sep 25, 2022
A networking library for iOS, macOS, watchOS and tvOS

Thunder Request Thunder Request is a Framework used to simplify making http and https web requests. Installation Setting up your app to use ThunderBas

3 SIDED CUBE 15 Aug 25, 2022
Library for interacting with Graph Store via UrsusHTTP

Swift Graph Store This is a library for reading from/writing to the Urbit GraphStore via the Swift airlock, UrsusHTTP. DISCLAIMER: This is a wildly in

Justin LeBlanc 6 Jul 22, 2022
Minimalist HTTP request library via async / await

Making HTTP API requests in Swift using Foundation can be verbose and use a mix of types like URL, URLComponents and URLRequest to form a request and then handling all the encoding and decoding steps later

Nicholas Maccharoli 12 Jul 26, 2022
OBSwiftSocket is a Swift library to be used for communication with OBS Studio via obs-websocket (v5).

OBSwiftSocket OBSwiftSocket is a Swift library to be used for communication with OBS Studio via obs-websocket (v5). obs-websocket v5 specification: ht

Edon 2 Aug 23, 2022
🏇 A Swift HTTP / HTTPS networking library just incidentally execute on machines

Thus, programs must be written for people to read, and only incidentally for machines to execute. Harold Abelson, "Structure and Interpretation of Com

John Lui 846 Sep 9, 2022
Malibu is a networking library built on promises

Description Palm trees, coral reefs and breaking waves. Welcome to the surf club Malibu, a networking library built on promises. It's more than just a

Vadym Markov 409 Sep 9, 2022
RSNetworking is a networking library written entirly for the Swift programming language.

RSNetworking is a networking library written entirly for the Swift programming language.

null 18 Feb 25, 2018
ServiceData is an HTTP networking library written in Swift which can download different types of data.

ServiceData Package Description : ServiceData is an HTTP networking library written in Swift which can download different types of data. Features List

Mubarak Alseif 0 Nov 11, 2021
foursquare iOS networking library

FSNetworking foursquare's iOS networking library FSN is a small library for HTTP networking on iOS. It comprises a single class, FSNConnection, and se

Foursquare 386 Sep 1, 2022
A networking library for Swift

Nikka Nikka is a super simple Swift HTTP networking library that comes with many extensions to make it modular and really powerful. Installation Usage

Emilien Stremsdoerfer 28 Jul 25, 2022
Malibu is a networking library built on promises

Description Palm trees, coral reefs and breaking waves. Welcome to the surf club Malibu, a networking library built on promises. It's more than just a

HyperRedink 10 Jan 29, 2022
AsyncHTTP - Generic networking library written using Swift async/await

Generic networking library written using Swift async/await

Laszlo Teveli 7 Aug 3, 2022
A resource based, protocol oriented networking library designed for pure-SwiftUI applications.

Monarch ?? - WIP A resource based, protocol oriented networking library designed for pure-SwiftUI applications. Features: Async/Await Resource Based P

Emilio Pelaez Romero 3 Jun 30, 2022