Wrapping my head around Socket.io Client API

Question

Normally, when we use HTTP requests, we have a specific set of methods/callbacks that would be called when the request succeeds/fails. Each connection request could have its own callback methods, which made structuring of code very easy.

So now that I am trying out Socket.io for a new project, I got all confused. For instance, you emit a message into the socket connection and you're done. no callbacks there. There is no easy way I can know if that actually succeeded or not I've managed to simulate a callback by writing this method:

public void emitRequest(final String event, JSONObject data, final emitResponseListener pListener)
{
  mSocket.on(event+"_resp", new Listener() {
    @Override
    public void call(final Object... args) {
      ((Activity)c).runOnUiThread(new Runnable() {
        @Override
        public void run() {
          JSONObject data = (JSONObject) args[0];
            if (pListener!=null)
            {
              pListener.onResponseRecieved(data);
            }
        }
      });
    }
  });
  mSocket.emit(event,data);
}

This method listens for a event_resp message from the server after emitting an event. But thats as far as I've got. I have no clue as to how to handle errors for specific emits, so as to update the UI or inform the user .etc.

Sure, there are callback events for the Socket but those are impossible to wire up into the apps flow.

So does anybody know a way to achieve this? I searched a lot but couldn't find anything. I'm using Java Client but generalized answers for any client API are welcome.

Kuf · Accepted Answer · 2016-01-28T17:26:44.003

1

You have to change your view - instead of callbacks think about events, and base your design accordingly.

When you make a request to the socket server, generate a unique token. Send the token to the server and have the server send it back with the request response. Using the token you can register a callback that will fire for event matching the request response event and this token.

This way you can execute the calls one after another.

To Cover cases where the server did not return a response, we use timeouts of 30 seconds. About 99.9% of the times we didn't get a response happened due to socket disconnection, so the socket error callback handled that after successful reconnection, without reaching the timeout.

edited Jan 28 '16 at 17:26

answered Jan 28 '16 at 07:32

Kuf

17,318
6
67
91

Good idea. but still, what if that response never came. How do I know there was an error? – ShahiM Jan 28 '16 at 14:20
1

well... you don't. we use timeouts of 30 seconds, but about 99.9% of the times we didn't get a response was due to socket disconnection, so the socket error callback handled that after successful reconnection. – Kuf Jan 28 '16 at 15:30
Yeah that makes sense. Thanks a lot. Can you add that too to the answer. I will accept tomorrow. – ShahiM Jan 28 '16 at 16:27

Wrapping my head around Socket.io Client API

1 Answers1