socket read para node data android node.js websocket

read - ¿Qué biblioteca de WebSocket usar en la aplicación de Android?



socket io kotlin (3)

Algunas notas.

  • koush / AndroidAsync no realiza el apretón de manos de cierre requerido por RFC 6455 . Vea this para más detalles.

  • Project Tyrus funciona en Android, pero asegúrese de que su licencia ( CDDL 1.1 y GPL 2 con CPE ) y su tamaño ( Reducción del tamaño de jar del cliente WebSocket con ProGuard ) cumplan con sus requisitos. También tenga en cuenta que Tyrus puede lanzar una excepción cuando el tamaño del texto es grande (probablemente sea un error). Vea this para más detalles.

  • Jetty : un hilo de correo electrónico de hace 2 años en la lista de correo de usuarios de embarcadero dice "Actualmente no tenemos un cliente de JetS 9 WebSocket compatible con Android. Hay planes para intentar hacer una copia de respaldo del cliente de Jetty WebSocket de JDK 7 a JDK 5/6 para Android uso, pero es una prioridad menor que terminar nuestra implementación de la API JSR-356 Java WebSocket (javax.websocket) ". El document actual de Jetty sobre su API de cliente WebSocket no menciona nada sobre Android.

  • codebutler / android-websocket no realiza el apretón de manos de cierre requerido por RFC 6455 y puede lanzar una excepción al cerrar. Mira this .

  • Atmosphere / wasync usa AsyncHttpClient / async-http-client como su implementación de WebSocket. Entonces, más bien, debería mencionarse AsyncHttpClient / async-http-client.

  • firebase / TubeSock no verifica Sec-WebSocket-Accept . Esta es una violación contra RFC 6455 . Además, TubeSock tiene un error al crear un mensaje de texto. Encontrará el error tarde o temprano si utiliza caracteres UTF-8 de varios bytes para mensajes de texto. Consulte el número 3 en delight-im/Android-DDP para obtener una larga lista sobre los problemas de TubeSock.

Puntos de consideración

Puntos de consideración al seleccionar una implementación de cliente WebSocket escrita en Java:

  1. Cumplimiento No pocas implementaciones no implementan el apretón de manos de cierre requerido por RFC 6455 . (¿Qué sucede si no se implementa el apretón de manos de cierre? Vea this ).
  2. Se requiere la versión de Java . Java SE 5, 6, 7, 8 o Java EE? Funciona incluso en Android?
  3. Tamaño . Algunas implementaciones tienen muchas dependencias.
  4. soporte de wss .
  5. Soporte de proxy HTTP .
  6. wss sobre soporte de proxy HTTP . Consulte la Figura 2 en Cómo interactúan los sockets web HTML5 con los servidores proxy acerca de lo que debe hacer una biblioteca cliente WebSocket para admitir wss a través del proxy HTTP.
  7. Flexibilidad en la configuración SSL . SSLSocketFactory y SSLContext deberían poder utilizarse sin restricciones innecesarias.
  8. Encabezados HTTP personalizados en el protocolo de enlace inicial , incluida la autenticación básica.
  9. Encabezados HTTP personalizados en la negociación de proxy HTTP , incluida la autenticación en el servidor proxy.
  10. Capaz de enviar todos los tipos de trama (continuación, binario, texto, cierre, ping y pong) o no. La mayoría de las implementaciones no proporcionan a los desarrolladores medios para enviar cuadros fragmentados y cuadros pong no solicitados manualmente.
  11. Interfaz de escucha para recibir varios eventos de WebSocket. Una interfaz pobre hace que los desarrolladores se sientan frustrados. Una interfaz rica ayuda a los desarrolladores a escribir aplicaciones robustas.
  12. Capaz de consultar el estado de WebSocket o no. RFC 6455 define los estados de CONEXIÓN, ABIERTO, CIERRE y CERRADO, pero pocas implementaciones mantienen su transición de estado interno de la manera definida.
  13. Capaz de establecer un valor de tiempo de espera para la conexión de socket . (Equivalente al segundo argumento del método Socket. connect (SocketAddress endpoint, int timeout) )
  14. Capaz de acceder al zócalo sin procesar subyacente .
  15. API intuitiva fácil de usar o no.
  16. Bien documentado o no.
  17. Compatibilidad con RFC 7692 (Extensiones de compresión para WebSocket) (también conocido como permessage-deflate).
  18. Redirección (3xx) de apoyo.
  19. Soporte de autenticación de resumen .

TakahikoKawasaki/nv-websocket-client cubre todo lo anterior excepto los dos últimos. Además, una de sus características pequeñas pero convenientes es enviar periódicamente cuadros de ping / pong. Se puede lograr simplemente llamando a los métodos setPingInterval / setPongInterval (consulte JavaDoc ).

Descargo de responsabilidad: Takahiko Kawasaki es el autor de nv-websocket-client.

Quiero agregar un Service a mi aplicación de Android que se ejecuta en segundo plano con una conexión WebSocket (posiblemente durante varias horas o incluso días) y envía regularmente algunos datos a un servidor.

Ahora parece que hay un montón de bibliotecas WebSocket para Java, y no estoy seguro de cuál debo usar:

Además, hay una biblioteca de cliente socket.io nativa para Android:

  • nkzawa/socket.io-client.java Descripción de GitHub: Biblioteca de cliente Socket.IO con todas las funciones para Java, que es compatible con Socket.IO v1.0 y posterior.

Usar el cliente socket.io de Android sería útil para mí, porque de todos modos planeo usar nodejs / socket.io para la interfaz web. Pero el cliente nativo es bastante joven y tiene varios problemas abiertos. Y además de eso, tengo entendido que una aplicación de Android no tiene ningún beneficio de usar la biblioteca del cliente socket.io (además de ser compatible con el servidor socket.io 1.0), porque el soporte de WebSocket puede garantizarse en el lado del cliente .

Mis requisitos son los siguientes:

  • Compatibilidad con Android API 9 y superior
  • Posibilidad de conectarse a través de SSL
  • Mantenga la conexión durante mucho tiempo sin tener que mantener un wakelock permanente
  • Compatibilidad con una implementación de servidor websocket nodejs disponible o con socket.io

¿Alguna sugerencia sobre cuál es la biblioteca adecuada para estos requisitos?

Algunas otras consideraciones:

Tyrus funciona en Android. Sin embargo, las bibliotecas SSL que usa en Android 5.0 tienen errores y fallan los protocolos de enlace SSL . Se supone que esto se arregla en las versiones más recientes de Android, pero con la forma en que Android no se actualiza en muchos dispositivos, esto puede ser un problema para usted.

Dependiendo de cómo se implemente SSL para otras implementaciones de websocket, esto también puede ser un problema.

AndroidAsync no tiene este problema de SSL. Tiene otros problemas, como no poder establecer tiempos de espera .

a) Agregue este archivo en el archivo gradle

compile ''com.github.nkzawa:socket.io-client:0.3.0''

b) Agregue estas líneas en la Actividad de la aplicación:

public class MyApplication extends Application { private Socket mSocket; { try { mSocket = IO.socket(Config.getBaseURL()); } catch (URISyntaxException e) { throw new RuntimeException(e); } } public Socket getSocket() { return mSocket; } }

c) Agregue esta función a su actividad, donde llamó a WebSocket:

private void websocketConnection() { //Get websocket from application MyApplication app = (MyApplication ) getApplication(); mSocket = app.getSocket(); mSocket.on(Socket.EVENT_CONNECT, onConnect); mSocket.on(Socket.EVENT_DISCONNECT, onDisconnect); mSocket.on(Socket.EVENT_CONNECT_ERROR, onConnectError); mSocket.on(Socket.EVENT_CONNECT_TIMEOUT, onConnectError); mSocket.on("messageFromServer", onNewLocation); mSocket.connect(); } private Emitter.Listener onConnect = new Emitter.Listener() { @Override public void call(Object... args) { runOnUiThread(() -> { if (!isConnected) { RequestSocket mRequestSocket = new RequestSocket(); mRequestSocket.setToken("anil_singhania"); /* your parameter */ mSocket.emit("messageFromClient", new Gson().toJson(mRequestSocket)); Log.i("Socket Data", new Gson().toJson(mRequestSocket)); isConnected = true; } }); } }; private Emitter.Listener onDisconnect = args -> runOnUiThread(() -> { isConnected = false; /* Toast.makeText(getApplicationContext(), R.string.disconnect, Toast.LENGTH_LONG).show();*/ }); private Emitter.Listener onConnectError = args -> runOnUiThread(() -> { /* Toast.makeText(getApplicationContext(), R.string.error_connect, Toast.LENGTH_LONG).show()*/ }); private Emitter.Listener onNewLocation = new Emitter.Listener() { @Override public void call(final Object... args) { runOnUiThread(() -> { }); } };