Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


La mejor manera de implementar Socket.io en android

Estoy planeando implementar Socket.io en android por esta biblioteca para una aplicación basada en chat. Por lo que he entendido la biblioteca parece ser bastante bueno. Quiero saber cómo mantener una conexión de socket único en toda la aplicación todo el tiempo? Aquí he enumerado maneras de lograr, en el que necesito la mejor y estable manera.

Tres maneras

La clase MainApplication extiende la aplicación

Por esto tenemos un buen alcance que la conexión del zócalo se mantiene en el hilo principal (o el ciclo de vida de la aplicación) y cada vez que la instancia del zócalo es necesaria de la actividad podemos conseguirla fácilmente. Pero es el hilo principal que también el problema. Puede bloquear el hilo principal.

BoundService

De esta manera podemos vincular el servicio con las actividades y simplemente podemos usarlo. Hacer en hilos separados es la manera de lograr llamadas IO / Network. Pero la transferencia de procesamiento cruzado es más cara que el acceso directo en el mismo proceso.

Semifallo

Mantener la conexión en Singleton también tiene sentido. Pero no sabemos cuando la instancia es eliminada por proceso, porque no funciona en el ciclo de vida de la actividad.

Si tengo sentido, por favor ayúdame. Si no lo comenta.

Editar

He dado la respuesta que es más conveniente para mí.

  • Comunicación de LocalSocket con el dominio de Unix en Android NDK
  • Captura de paquetes de red en Android?
  • Proteger un socket en VpnService
  • Llegar a un dispositivo de red por IP y puerto mediante el emulador de Android
  • Conexión HTTP de Android
  • Enviar datos a través de wifi (no internet) cuando los datos móviles
  • Socket para servidor Android
  • ¿Hay algún mecanismo de devolución de llamada en android cuando hay datos disponibles para leer en socket
  • 4 Solutions collect form web for “La mejor manera de implementar Socket.io en android”

    En primer lugar, onCreate la aplicación es irrelavant a su caso de uso, ya que no puede tener un hilo que se ejecuta en segundo plano cuando se inició por primera vez en un código de no servicio.

    Además, recomendaría usar Google Cloud Messaging en lugar de crear tu propio mecanismo. Sería mejor para la duración de la batería del dispositivo y mucho menos código para que usted pueda manejar.

    Si desea implementar esa charla por su cuenta, el servicio es su única opción. También se puede combinar con un singleton, pero yo no recomendaría ese enfoque. Puede utilizar transmisiones y difundir receptores para comunicarse entre su servicio y las actividades, creo que es más fácil que un BoundService ya que el límite al servicio es asíncrono y crea un montón de desorden en comparación con la simple radiodifusión.

    Servicio de mantenimiento de la conexión de socket

    Según Ofek Ron mencionó el Service con BroadcaseReceivers es una idea mejor que BoundService . Porque es un proceso tedioso para mantener la comunicación. Y también recomiendo pub/sub manera de radiodifusión, como Otto o EventBus (yo mismo sugiero Otto por Square, que es api limpio y brillante).

    Pros de OTTO
    1. Limpiador Api
    2. Usted puede suscribirse y publicar en / a cualquier actividad, fragmento, servicio, Clase.
    3. Desacoplamiento . (Tienes que acoplar lo menos posible en tu código).

    Y un punto más es usar START_STICKY en el onStartCommand para iniciar el servicio después de que se esté destruyendo. Vea esta referencia.

    MainApplication para iniciar el servicio

    Es recomendable iniciar el servicio en MainApplication extends Application. Porque la aplicación se eliminará cuando hay una restricción de memoria o el usuario cierra la aplicación de la pila. Así que onStartCommand no será llamado frecuentemente como si lo hayamos implementado en Activity.

    Implementación del estado en línea

    Puede implementar el estado en línea simplemente implementando Application.LifeCycleCallbacks en la clase MainApplication , que tiene la mayoría de las llamadas de retorno del ciclo de vida de la actividad y se notificará en la devolución de llamada. Por eso se puede implementar el estado en Online sin ningún tipo de códigos de placas de calderas. (Si alguien necesita ayuda, házmelo saber).

    Carga o descarga de imágenes o archivos.

    La mejor práctica es implementar por IntentService porque se está ejecutando en un hilo independiente. Prometo que dará el mejor funcionamiento porque es manejado por androide sí mismo, no como los hilos creados por nosotros.

    Puede combinar la primera y la tercera vía como:

    Cree Socket s en su Application y declárelos como static . Así que usted puede mantener y acceder a ellos cada lugar en su aplicación. No olvide crear ThreadPool separados para realizar las operaciones de red, puede usar ThreadPool para administrar esos ThreadPool . Si desea actualizar su interfaz de usuario desde esos Thread , puede utilizar el Handler y el Message para comunicarse con UI Thread

    Antes de crear su propia implementación de un cliente socket.io, debe darle una oportunidad a esta biblioteca: https://github.com/socketio/socket.io-client-java

    Lo uso en uno de mis proyectos para comunicarse con un servidor node.js que está funcionando bastante bien. En realidad, todas sus sugerencias son correctas y dependen principalmente de lo que desea lograr. Sin embargo, siempre hay un contexto disponible: el contexto de la aplicación. Por lo tanto, debe mantener una instancia singleton en la clase Application y obtenerla por getApplicationContext() .

    Estado en línea del usuario: aquí debe crear un servicio de fondo que está escuchando constantemente para el estado de los usuarios. Como no hay mucha información, esto debería estar bien y no debe drenar la batería demasiado. Además, puede enviar un indicador si hay nueva información disponible y sólo si hay algo nuevo, se inicia otro hilo, que está recibiendo los nuevos datos. Esto mantiene los datos bajos.

    Chat: los datos del chat se transmiten sólo cuando la aplicación está activa. Por lo tanto, esto debe hacerse en una actividad.

    Tanto el servicio como la actividad pueden acceder a la instancia singleton del cliente socket.io desde el contexto de la aplicación. Siempre y cuando no procese ningún dato complejo en el hilo principal todo está bien. Por lo tanto, envuelva sus llamadas en hilos separados y sólo iniciarlos cuando son realmente necesarios.

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.