Thanks for writing me back.
I did considered using other implementation of WebSocket for Android:
This implementation also has an interface for Socket.IO. However, I was
not comfortable with that implementation, I've tried it, and it was a
bit unreliable under high load (10 messages per sec) or big messages
Also, I've read the code of android-websockets, and I think it needs a
lot more of work to get to the maturity AutobahnAndroid has (Also only
implements Hixie-76 btw).
Some months ago I've tried the AutobahnJS library using WAMP and it was
great, so when this project came, and I was looking for alternatives for
and Android client library I thought: why simply not implement
this(socket.io) over that(autobahn)?, an I did so.
About using Socket.IO, I agree with you, when WebSockets are available,
there's no point in using it. However, some projects require us to
support platforms where WebSockets are not available, and Socket.IO is
really flexible in that, requires little to none adaptation of code to
work even in the oldest browser. Also, this project is being developed
over node.js related technology, so using socket.io seems the most
natural option to use.
By the way, Socket.IO doesn't implement PubSub, but it is really close
to it: when clients connect, they can join rooms, and then the server
can broadcast messages to such rooms. This behavior is almost PubSub,
with the difference that client is not required to do a handshake to
listen to a channel (room), instead, the server puts the client where it
wants, and sends the events(messages) when it wants, after that, if the
client has a handler for that type of message, it handles the message,
if not, simply ignores the message. It's like a loose PubSub, where no
strict behavior of client and server is expected. Perhaps, this kind of
behavior has sense when the clients are from a wide range of platforms,
and maybe some of them are only observing, polling the information.
All that aside, If I could choose what the clients should use, I would
choose only android and chrome, so I could have fun programming and they
could get the best user experience.
The only client library I think that Autobahn is missing, is the native
IOS library. I know AutobahnJS works on IPhones, but some applications
require a native client, and something like a service running in
background is the best way to do it.
Anyway, AutobahnPython is a great server, and AutobahnAndroid is a great
client library, and I would use it for future projects if the
circumstances allows me.
On Sunday, July 8, 2012 10:29:42 AM UTC-4:30, Tobias Oberstein wrote:
great that you are reusing AutobahnAndroid for your project! We
should probably make AutobahnAndroid more visible as the most mature
WebSocket implementation - independent of it's WAMP functionality.
Curious: did you consider any other Android WebSocket
implementation? I only know weberknecht, and that seems to be
unmaintained and only implements Hixie-76.
That said I'm not sure I can follow the project goals fully ..
Socket.IO provides several fallback mechanism for "plain
bidirectional messaging". I does not provide RPC or PubSub messaging
patterns. When Socket.IO can use WebSocket as a transport, it's
subprotocol does not add anything significant to WebSocket: it's
just plain bidirectional messaging.
Honestly, when WebSocket is available, I can't see the point of
using Socket.IO ..
Am Freitag, 29. Juni 2012 04:43:57 UTC+2 schrieb Alejandro Hernandez:
Fellas I'm writing to first say thanks for this amazing project.
Second, I would like to contribute with the community, I
implemented a client library for the popular subprotocol
Socket.IO (which some prefer to work with), on top of the
This is a very early work, with only some hours of work, but
thanks to its solid base, is a very promising library.
I like a lot the WAMP, but you know, now we have another flavor
Thats all folks.