Question Meilleur moyen d'implémenter Socket.io dans Android


Je prévois d'implémenter Socket.io dans Android par ce bibliothèque pour une application basée sur le chat. Si j'ai bien compris, la bibliothèque semble être très bonne. Je veux savoir comment maintenir un unique connexion socket dans toute l'application tout le temps? Ici, j'ai énuméré les moyens de réaliser, dans lesquels j'ai besoin de la manière la meilleure et la plus stable.

Trois façons 

MainApplication La classe s'étend Application 

Par cela, nous avons une bonne portée que la connexion de socket est maintenue dans le fil principal(ou le cycle de vie de l'application) et chaque fois que l'instance de socket est nécessaire à l'activité, nous pouvons l'obtenir facilement. Mais c'est le fil conducteur qui pose aussi le problème. Cela pourrait bloquer le thread principal.

BoundService 

De cette façon, nous pouvons lier le service avec les activités et nous pouvons simplement l'utiliser. Faire dans un thread séparé est le moyen d'obtenir des appels IO / réseau. Mais le transfert de traitement croisé est plus coûteux que l'accès direct au même processus.

Singleton 

Maintenir la connexion dans Singleton est également logique. Mais nous ne savons pas quand l'instance est tuée par processus, car cela ne fonctionne pas dans le cycle de vie de l'activité.

Si j'ai du sens, aidez-moi s'il vous plaît. Si ce n'est pas le commenter.

modifier

J'ai donné la réponse qui me convient le mieux.


18
2017-08-19 17:51


origine


Réponses:


Tout d'abord, l'application onCreate() n'est pas pertinent dans votre cas d'utilisation, car vous ne pouvez pas exécuter un thread en arrière-plan lorsqu'il a été initialisé pour la première fois dans un code autre que le service.

Aussi, je recommanderais d’utiliser Google Cloud Messaging au lieu de créer votre propre mécanisme. Il serait préférable pour la vie de la batterie de l'appareil et beaucoup moins de code à gérer.

Si vous souhaitez implémenter ce chat complètement par vous-même, Service est votre seul choix. Vous pouvez également le combiner avec un singleton, mais je ne recommanderais pas cette approche. Vous pouvez utiliser des émissions et BroadcastReceiver pour communiquer entre votre Service et Activity, Je pense que c'est plus simple qu'un service lié, car la limitation au service est asynchrone et cela crée beaucoup de désordre par rapport à la diffusion simple.


6
2017-08-23 09:51



Service de maintenance socket connexion

Selon Ofek Ron mentionné Service avec BroadcaseReceiver est un meilleur idée que BoundService. Parce que c'est un processus fastidieux pour maintenir la communication. Et je recommande aussi pub/sub moyen de diffusion, comme Otto ou EventBus (Je suggère moi-même Otto par Square, qui est api propre et brillant).

Avantages de OTTO
1. Api plus propre
2. Vous pouvez vous abonner et publier dans / à tout Activity, Fragment, Service classe.
3. Découplage. (Vous devez coupler le moins possible dans votre code).

Et un autre point est l'utilisation START_STICKY dans le onStartCommand() pour démarrer le service après sa destruction. Voir ce référence.

MainApplication pour démarrer le service

Il est recommandé de démarrer le service dans le MainApplication qui s'étend Application. Parce que l'application sera supprimée lorsqu'il existe une contrainte de mémoire ou que l'utilisateur ferme de force l'application depuis la pile. Alors onStartCommand() ne sera pas appelé fréquemment comme si nous avions implémenté dans Activité.

Mise en place du statut en ligne

Vous pouvez implémenter le statut en ligne simplement en implémentant Application.LifeCycleCallbacks dans le MainApplication classe, qui a la plupart des rappels d'activité du cycle de vie et sera notifié dans le rappel. Par cela, vous pouvez mettre en œuvre Online statut simplement sans aucun code de plaque de chaudière. (Si quelqu'un a besoin d'aide, faites le moi savoir).

Télécharger ou télécharger des images ou des fichiers.

La meilleure pratique consiste à mettre en œuvre par IntentService parce qu'il s'exécute dans un thread distinct. Je promets que cela donnera les meilleures performances car il est géré par Android lui-même, pas comme les threads créés par nous.


5
2017-08-27 09:48



Vous pouvez combiner le premier et le troisième moyen comme:

Créer Sockets dans votre Application et les déclarer comme static. Vous pouvez donc les gérer et y accéder chaque fois que vous le souhaitez. N'oubliez pas de créer séparément Threads pour effectuer les opérations réseau, vous pouvez utiliser ThreadPool pour gérer ceux Thread. Si vous souhaitez mettre à jour votre interface utilisateur à partir de celles Thread vous pouvez utiliser Handler et Message à la communication avec l'interface utilisateur Thread


1
2017-08-26 09:47



Avant de créer votre propre implémentation d'un client socket.io, vous devriez donner une chance à cette bibliothèque: https://github.com/socketio/socket.io-client-java

Je l'utilise dans l'un de mes projets pour communiquer avec un serveur node.js qui fonctionne très bien. En fait, toutes vos suggestions sont correctes et dépendent principalement de ce que vous voulez réaliser. Cependant, un contexte est toujours disponible: le contexte de l'application. Par conséquent, vous devriez garder une instance singleton dans le Application classe et l'obtenir par getApplicationContext().

Statut en ligne de l'utilisateur: vous devez créer ici un service d'arrière-plan à l'écoute constante de l'état des utilisateurs. Comme il n'y a pas beaucoup d'informations, cela devrait être correct et ne pas vider la batterie trop. De plus, vous pouvez envoyer un indicateur si de nouvelles informations sont disponibles et seulement s'il y a quelque chose de nouveau, vous lancez un autre thread qui reçoit les nouvelles données. Cela garde les données faibles.

Chat: les données de discussion ne sont transférées que lorsque l'application est active. Donc, cela devrait être fait dans une activité.

Le service et l'activité peuvent tous deux accéder à l'instance singleton du client socket.io à partir du contexte d'application. Tant que vous ne traitez pas de données complexes sur le thread principal, tout va bien. Donc, enveloppez vos appels dans un thread séparé et ne les démarrez que lorsqu'ils sont réellement nécessaires.


0
2017-08-26 15:28