Differences with SwiftPhoenixClient

[alexbredy]

Hi there,

Very nice library, especially with the handling of presence! Could you please outline what are the differences with this one (beyond the presence)? https://github.com/davidstump/SwiftPhoenixClient

Thanks for your help, Alex

[sjrmanning]

Hi Alex,

Thanks for your comments and interest! There are a few minor differences of opinion and bug fixes that I ran into after using SwiftPhoenixClient, but the major difference is in the architecture of sending and receiving payloads on the socket connection.

All actions (joining/leaving channels, sending messages, etc.) are based off the Phoenix JavaScript client architecture (see: https://github.com/phoenixframework/phoenix/blob/master/web/static/js/phoenix.js), where they return an object (Push), containing the unique reference ID and a way to subscribe to responses to that event (e.g. when sending a message, you can "receive" the response from the server by the status returned, as well as the payload). This is documented in the README with a few examples, such as:

    channel.send("new:msg", payload: ["body": "Hello!"])
        .receive("ok", callback: { response in
            print("Sent a message!")
        })
        .receive("error", callback: { reason in
            print("Message didn't send: \(reason)")
        })

As shown above, .receive returns the same Push object, so you can also chain on a callback to respond to errors with .receive("error" ..., allowing the client to handle errors on specific actions. This differs from SwiftPhoenixClient, where after a message is sent no reference is kept to it. Birdsong keeps the unique ref IDs to messages until a response is received back from the server, confirming that the message was received server-side and allowing this .receive functionality.

Hope that helps!

[alexbredy]

Hi Simon,

Thanks for spending time in answering my question. It helped a lot! Keep up the good work, issue resolved :)

Alex