Bibliotecas de websockets

[mocelet]

Creo que alguna vez hemos hablado de bibliotecas de websocket para Android, no estaba el panorama muy maduro y algunas incluso eran de desarrolladores independientes que ahora están abandonadas.

Sin embargo desde el mes pasado la biblioteca OkHttp (http://square.github.io/okhttp/) de Square incluye soporte websockets de manera estable y en teoría han pulido la mayoría de bugs que había. El API es muy sencilla, basta darle la URL y registrar un listener que te avisa de los cambios de estado y cuando se reciben mensajes (una lástima que no avise en el hilo principal a todo esto). Es compatible tanto con Java como con Android 2.3 o superior

Para el lado del servidor siempre he sido fan de Netty pero para algunas cosas el nivel de abstracción es bajo (los websockets de hecho...), así que estoy migrando a Vert.x (http://vertx.io) que está basado en Netty pero añade bastante funcionalidad y viene de serie con bus de eventos y drivers asíncronos para bases de datos.

[Dexafree]

Soy fan del stack I/O de Square (Okio, OkHttp, Retrofit y Picasso), pero la verdad es que nunca he necesitado utilizar los websockets en Android, aunque desde luego OkHttp sería mi primera opción sin dudarlo.

Para web + NodeJS (no soy muy fan de la JVM en servidor, demasiado pesada) hasta ahora me ha dado muy buen resultado Socket.io, extremadamente fácil de utilizar. Además dan soporte nativo en Android:
http://socket.io/blog/native-socket-io-and-android/

una lástima que no avise en el hilo principal a todo esto

Te tocará crear a ti el método que lo ejecute en primer plano:
http://stackoverflow.com/questions/11123621/running-code-in-main-thread-from-another-thread

También puedes usar esta librería, que hace el tema de threading algo más limpio:
https://github.com/Arasthel/AsyncJobLibrary


AsyncJob.doOnMainThread(new AsyncJob.OnMainThreadJob() {
override
public void doInUIThread() {
Toast.makeText(context, "Result was: "+ result, Toast.LENGTH_SHORT).show();
}
});


De todos modos no me extrañaría que en un futuro OkHttp lo soportara. Siempre puedes abrir un issue y comentarlo: https://github.com/square/okhttp/issues

[mocelet]

Gracias, a mí me pasa lo mismo con javascript (no soy muy fan jeje).

Lo de que no avise en el hilo principal supongo que lo hacen porque ya tienen un eventbus (Otto creo que se llama) para esas cosas. Y, bueno, como estoy usando Kotlin que tiene lambdas con poner delante runOnUiThread ya está. Si tuviera que escribir new Runnable y toda la parafernalia igual me molestaba más tanta "verbosidad" xD

[Dexafree]

Otto creo que se llama

Otto está deprecated (aparte de que el patrón EventBus en Android es muy fácil de abusar) xD
Se ha sustituido sobretodo por RxJava (y las extensiones de RxAndroid). No es fácil cogerle el truco al principio, pero cuando hace "click" es espectacular la componibilidad que da.

Kotlin

Otro que se ha pasado al lado menos verbose de la vida xD


Volviendo al tema del hilo, finalmente le das el visto bueno a OkHttp para Websockets?
Por si algún día lo necesito :ok:

[mocelet]

cuando hace "click" es espectacular la componibilidad que da

Me imagino, con Swift tuve el "click" previo de olvidarme de los bucles con condicionales y pensar en transformar colecciones (y fue el culpable de ver Kotlin con otros ojos).

RxJava no lo he usado pero ciertamente parece muy potente si consigues ver/modelar la funcionalidad como transformaciones de flujos de eventos.

le das el visto bueno a OkHttp para Websockets?

Es el que más confianza me inspira ahora mismo y viendo los issues parece que hay mucha gente que lo usa en producción desde hace tiempo (los de Square dicen que la funcionalidad llevaba tres años en la biblioteca hasta marcarla como estable).

EDIT: Sobre socket.io, acabo de leer esto https://github.com/rethinkdb/horizon/issues/413 y lo ponen a caer de un burro Dexafree xD En su día sí que era una solución, pero ahora que todo soporta websockets mejor usarlos y olvidarse de fallbacks.