Investigate usage of websocket with RoboSpice

[stephanenicolas]

A question has been posted on SOF in this direction : http://stackoverflow.com/q/15570595/693752

There seem to be, at least, 2 interesting implementations of Socket.io on GitHub :

• https://github.com/Gottox/socket.io-java-client
• https://github.com/benkay/java-socket.io.client

Some notable questions / comments about integration of websockets in RS :

• RS has been designed for "one shot" network request but websockets maintain an open connection
• What would be the interest of using RS's cache within websockets ?
• How can we deal with both String messages and Json messages ? RS requests are strongly typed and single typed.
• How can a request maintain an active connection and allow listeners from different activities to plug to it ? Should we maintain the connection in RS as well ?

[chrisjenx]

I like the idea of this, We are looking at web sockets for the future implementation. Will be nice.

Your right RS is based on restful implementation.

So I think a noteable change in framework for effective 'stream' as opposed to 'request'.

Something like SocketListener and SpiceSocket which are initialised on start stop.

I guess the larger difference is that SocketListener is a bit more involved due to it needing to handle events.

[stephanenicolas]

I like the idea too but it seems to me that we should digg out more details before starting implementing stuff. I am particularly concerned about the lifecycle of such a request and its listeners.

2013/3/27 Christopher Jenkins [email protected]

I like the idea of this, We are looking at web sockets for the future implementation. Will be nice.

Your right RS is based on restful implementation.

So I think a noteable change in framework for effective 'stream' as opposed to 'request'.

Something like SocketListener and SpiceSocket which are initialised on start stop.

I guess the larger difference is that SocketListener is a bit more involved due to it needing to handle events.

— Reply to this email directly or view it on GitHubhttps://github.com/octo-online/robospice/issues/71#issuecomment-15548653 .

Stéphane NICOLAS, OCTO Technology Développeur & Consultant Android / Java .......................................................... 50, Avenue des Champs-Elysées 75008 Paris +33 (0)6.26.32.34.09 www.octo.com - blog.octo.com www.usievents.com ...........................................................

[stephanenicolas]

This topic should be adressed within a month. It is planned for next issue. If people wish to help, let's see if something can be done with RS in that matter.

[weefbellington]

Just wondering what the status of this is. If it still needs to be implemented, I'd be willing to help.

[chrisjenx]

@weefbellington, @stephanenicolas will give more info, but the way Sockets interact with devices is quite different to a traditional RESTful approach, as Sockets apply a more RPC/FullDuplex communication method.

It needs architecturally thinking how this would fit into RoboSpices pattern (if it does at all). Wondering if it would be worth sketching out how this would work high level in an architectural way.

[weefbellington]

I recently tried out LucidChart for software architecture sketching and I was very pleased with it. It seems like it would be good tool for collaborative design.

[stephanenicolas]

I would enjoy if anyone could start the process of design thinking with the tool mentioned by David or not.

I come back from holidays and try to pile off my mails first, then patch bugs and later only I will be able to think of such a feature.

Benoit is right a large amount of thinking and design is needed before going into any coding effort.

S. Le 8 juil. 2013 23:30, "David Stemmer" [email protected] a écrit :

I recently tried out LucidChart https://www.lucidchart.com/ for software architecture sketching and I was very pleased with it. It seems like it would be good tool for collaborative design.

— Reply to this email directly or view it on GitHubhttps://github.com/octo-online/robospice/issues/71#issuecomment-20637552 .

[weefbellington]

OK, I'll take the first stab at it.

As an application developer, I know I would like the API for obtaining a persistent connection to resemble a SpiceRequest. But I also know that the SpiceService will need to differentiate between persistent and non-persistent connections. Here is what the interface looks like in my head:

CONFIGURATION

1. Implement a SpiceConnection class. This class has two abstract methods:

public void open()
public void close()

2. Implement a SpiceConnection.Listener class. This class has three abstract methods:

public void onConnectionOpened()
public void onConnectionClosed()
public void onConnectionFailure()

3. Implement a SpiceConnection.Transmitter<ConnectionType extends SpiceConnection> class. This class has one abstract method:

public void transmit(ConnectionType connection)

4. Implement one or more SpiceConnection.Receiver<ResultType> classes. These classes have one abstract method:

public void receive(ResultType result)

USAGE

1. Create an instance of SpiceConnection
2. Create an instance of SpiceConnection.Listener.
3. Create an instance of SpiceConnection.Transmitter.
4. Create an instance of SpiceConnection.Receiver
5. To open the connection, call SpiceManager.openConnection(SpiceConnection connection).
6. To register for callbacks from the connection, call SpiceManager.registerReceiver(SpiceConnection connection, SpiceConnection.Receiver receiver).
7. To send data through the connection, call SpiceManager.transmit(SpiceConnection connection, SpiceConnection.Transmitter transmitter).

COMMENTS

• If the SpiceConnection is in an connecting state, Calls to SpiceManager.transmit() would be queued until the connection has opened.
• One peculiar aspect of web sockets (and two-way connections in general) is that requests may or may not be mapped to responses. From what I've read it looks like the basic web socket protocol does not map requests to responses, but some subprotocols (such as WAMP) do. For this approach I've assumed no relationship between requests and responses, but it's worth considering whether this approach would be extensible to support that scenario.
• I've decoupled the actual connection object from the data transmission object. It's a little clumsy, but it addresses Stephan's comment about String and Json types.

Thoughts/comments/critiques? What am I missing, how would you do it differently?

[stephanenicolas]

Damn, would that still be RS ?

How RS can help to make it better than any other impl ?

And where do types come from : ConnectionType and ResultType ?

2013/7/9 David Stemmer [email protected]

OK, I'll take the first stab at it.

As an application developer, I know I would like the API for obtaining a persistent connection to resemble a SpiceRequest. But I also know that the SpiceService will need to differentiate between persistent and non-persistent connections. Here is what the interface looks like in my head:

CONFIGURATION

1. Implement a SpiceConnection class. This class has two abstract methods:

public void open() public void close()

1. Implement a SpiceConnection.Listener class. This class has three abstract methods:

public void onConnectionOpened() public void onConnectionClosed() public void onConnectionFailure()

1. Implement a SpiceConnection.Transmitter<ConnectionType extends SpiceConnection> class. This class has one abstract method:

public void transmit(ConnectionType connection)

1. Implement one or more SpiceConnection.Receiver<ResultType> classes. These classes have one abstract method:

public void receive(ResultType result)

USAGE

1. Create an instance of SpiceConnection
2. Create an instance of SpiceConnection.Listener.
3. Create an instance of SpiceConnection.Transmitter.
4. Create an instance of SpiceConnection.Receiver
5. To open the connection, call SpiceManager.openConnection(SpiceConnection connection).
6. To register for callbacks from the connection, call SpiceManager.registerReceiver(SpiceConnection connection, SpiceConnection.Receiver receiver).
7. To send data through the connection, call SpiceManager.transmit(SpiceConnection connection, SpiceConnection.Transmitter transmitter).

COMMENTS

• If the SpiceConnection is in an connection state, Calls to SpiceManager.transmit() would be queued until the connection has opened.
• One peculiar aspect of web sockets (and two-way connections in general) is that requests may or may not be mapped to responses. From what I've read it looks like the basic web socket protocol does not map requests to responses, but some subprotocols (such as WAMP http://wamp.ws/) do. For this approach I've assumed no relationship between requests and responses, but it's worth considering whether this approach would be extensible to support that scenario.
• I've decoupled the actual connection object from the data transmission object. It's a little clumsy, but it addresses Stephen's comment about String and Json types.

Thoughts/comments/critiques? What am I missing, how would you do it differently?

— Reply to this email directly or view it on GitHubhttps://github.com/octo-online/robospice/issues/71#issuecomment-20705507 .

Stéphane NICOLAS, OCTO Technology Développeur & Consultant Android / Java .......................................................... 50, Avenue des Champs-Elysées 75008 Paris +33 (0)6.26.32.34.09 www.octo.com - blog.octo.com www.usievents.com ...........................................................

[weefbellington]

ConnectionType is a generic type that extends SpiceConnection. For example the concrete type could be a WebSocketConnection. When Robospice is ready to initiate a queued request, the WebSocketConnection would be passed to the Transmitter, which would be responsible for sending the message. It's a similar idea doInBackground(). A Transmitter is basically the equivalent of a SpiceRequest when dealing with an open SpiceConnection.

ResultType is simply the type of data returned from the server, e.g., JSON, String, etc.

From a philosophical perspective, I think Robospice is a good match for web sockets for a few reasons:

• Robospice is designed to facilitate long-running, asynchronous networking tasks. Web sockets fit naturally into this definition.
• One of the tenants in the Design of Robospice document is protocol-agnosticism. So I don't think it should be limited to request/response type connections.
• It was designed with multithreading, which would be helpful when managing several open web socket connections.
• Most existing web socket libraries are fairly low-level and are not aware of the Android lifecycle. Robospice could help ease the burden on the developer by closing the connection when the application moves into a background state. It could also potentially re-open the connection when the application wakes up again.

[stephanenicolas]

Wow David, it looks like a birdie is flying on its own wing. +5 for your argumentation.

I just wonder if this design could grow 'in the onion way' like RS, by adding higher levels of abstraction to deal with JSON parsing or other POJO-based tech. But it should. :)

I may suggest that :

• spiceManager for websocket should get a better name. It's quite distinct from the usual spiceManager.
• the websocket stuff should have a module of its own and not interfere, as far as possible, with the actual core, at least at first.
• classes and or interfaces should not be inner classes. They are strong concepts and deserve classes of their own.
• some additional thinking about caching should be made. I got the feeling that most of RS-cache would still hold.
• dev should definitely start on a separate shared remote branch on github.
• There should be tests and at least a sample, of course.

That's really fine for me.

Stéphane

2013/7/17 David Stemmer [email protected]

ConnectionType is a generic type that extends SpiceConnection. For example the concrete type could be a WebSocketConnection. When Robospice is ready to initiate a queued request, the WebSocketConnection would be passed to the Transmitter, which would be responsible for sending the message. It's a similar idea doInBackground(). A Transmitter is basically the equivalent of a SpiceRequest when dealing with an open SpiceConnection.

ResultType is simply the type of data returned from the server, e.g., JSON, String, etc.

From a philosophical perspective, I think Robospice is a good match for web sockets for a few reasons:

• Robospice is designed to facilitate long-running, asynchronous networking tasks. Web sockets fit naturally into this definition.
• One of the tenants in the Design of Robospicehttps://github.com/octo-online/robospice/wiki/Design-of-RoboSpicedocument is protocol-agnosticism. So I don't think it should be limited to request/response type connections.
• It was designed with multithreading, which would be helpful when managing several open web socket connections.
• Most existing web socket libraries are fairly low-level and are not aware of the Android lifecycle. Robospice could help ease the burden on the developer by closing the connection when the application moves into a background state. It could also potentially re-open the connection when the application wakes up again.

— Reply to this email directly or view it on GitHubhttps://github.com/octo-online/robospice/issues/71#issuecomment-21145250 .

Stéphane NICOLAS, OCTO Technology Développeur & Consultant Android / Java .......................................................... 50, Avenue des Champs-Elysées 75008 Paris +33 (0)6.26.32.34.09 www.octo.com - blog.octo.com www.usievents.com ...........................................................

[ghost]

Hi guys, Please look at: https://github.com/Gottox/socket.io-java-client in combination with: sailsjs.org This combination and the environment of RoboSpice would be very nice! Sails uses http+socket.io with authentication together, one is able to make models in a blink of an eye at the server side. Looking at : http://milanito.github.io/web%20mobile/2013/12/29/sockets-with-android-and-sails/ , I was able to create a connect to Sails and was able to receive messages by means of socket.io (websockets). So, yeah, RoboSpice and Websockets, would be very nice to have!

[chrisjenx]

Robospice doesn't really fit the socket paradigm. Reactive Extensions and observables very neatly fit the channel subscription paradigm.

Have a look at RxJava and you'll see what I mean. On 12 May 2014 19:19, "Ivo Cazemier" [email protected] wrote:

Hi guys, Please look at: https://github.com/Gottox/socket.io-java-client in combination with: sailsjs.org This combination and the environment of RoboSpice would be very nice! Sails uses http+socket.io with authentication together, one is able to make models in a blink of an eye at the server side. Looking at : http://milanito.github.io/web%20mobile/2013/12/29/sockets-with-android-and-sails/, I was able to create a connect to Sails and was able to receive messages by means of socket.io (websockets). So, yeah, RoboSpice and Websockets, would be very nice to have!

— Reply to this email directly or view it on GitHubhttps://github.com/stephanenicolas/robospice/issues/71#issuecomment-42868201 .

[ghost]

Thanks, will take a peak!

[stephanenicolas]

+1 Christopher Le 12 mai 2014 20:30, "Christopher Jenkins" [email protected] a écrit :

Robospice doesn't really fit the socket paradigm. Reactive Extensions and observables very neatly fit the channel subscription paradigm.

Have a look at RxJava and you'll see what I mean. On 12 May 2014 19:19, "Ivo Cazemier" [email protected] wrote:

Hi guys, Please look at: https://github.com/Gottox/socket.io-java-client in combination with: sailsjs.org This combination and the environment of RoboSpice would be very nice! Sails uses http+socket.io with authentication together, one is able to make models in a blink of an eye at the server side. Looking at :

http://milanito.github.io/web%20mobile/2013/12/29/sockets-with-android-and-sails/, I was able to create a connect to Sails and was able to receive messages by means of socket.io (websockets). So, yeah, RoboSpice and Websockets, would be very nice to have!

— Reply to this email directly or view it on GitHub< https://github.com/stephanenicolas/robospice/issues/71#issuecomment-42868201>

.

— Reply to this email directly or view it on GitHubhttps://github.com/stephanenicolas/robospice/issues/71#issuecomment-42869526 .

[stephanenicolas]

This lib is also interesting on that matter : https://github.com/stanfy/enroscar