Notifications Push ou Socket.io?, ou les deux?
je développe un système de chat pour le web, Android et iOS. En faisant mes recherches, j'ai trouvé des différences sur la façon dont GCM et APNS traitent les notifications Push.
si j'envoie une notification Push à un appareil Android via le GCM, l'appareil est en mesure de décider s'il en informe l'utilisateur, ou si ce n'est pas nécessaire, il ne le dit pas à l'utilisateur. Il pourrait être juste une mise à jour de données que l'utilisateur n'a pas besoin d'être informé. D'un autre côté, si j'envoie une notification Push à un appareil iOS par APNS, le dispositif n'est pas en mesure de décider si de montrer ou non la notification, la notification doit être montré. En outre, lorsqu'un périphérique iOS reçoit la notification, les données de notification doivent contenir la chaîne qui va être montrée à l'utilisateur. Sur Android, l'appareil peut générer cette chaîne.
donc, je voulais créer un système qui fonctionne de la même manière pour iOS et Android, et aussi pour le site web (basé sur API). C'est là que j'ai trouvé Socket.io. Socket.io me donne le la liberté d'envoyer des données à l'appareil (peu importe si son iOS ou Android), de sorte que l'appareil décide d'afficher ou pas les modifications faites (peut-être une mise à jour d'un utilisateur, un nouveau message, une invitation, ou de beaucoup d'autres "événements"). Mais, en faisant mes recherches j'ai trouvé quelques inconvénients sur L'utilisation de Socket.io. L'appareil doit être connecté à la socket de sorte que l'information circule entre le client et le serveur, mais un smartphone, dans le monde réel, se connecte et se déconnecte tout le temps à différents réseaux, et qui rompt la connexion de socket. En outre, en ayant la connexion ouverte, sur l'arrière-plan, il y a un ping pong entre le serveur et le client pour vérifier que la connexion est toujours ouverte, et qui finit par consommer des mégas (dans mon pays, nous payons pour chaque mega que nous utilisons, nous n'avons pas encore un tarif fixe) et aussi la vie batery. Je ne sais pas si cette consommation est importante ou non.
côté web, il doit fonctionner avec Socket.io, donc ce n'est pas un problème à tout.
enfin, connaissant le pour et le contre des deux alternatives, j'ai découvert que je pouvais mélanger les deux options et que cela pourrait finir par être ma meilleure option. Par exemple, lorsque l'application est ouverte, elle utilise Socket.io et quand est fermé utilisez les APN ou GCM (selon le système D'exploitation de l'appareil). Mais, est-ce une bonne pratique? Ou serait-il préférable de s'en tenir à une seule solution au lieu de mélanger les deux et pourquoi?
Merci beaucoup d'avoir pris votre temps pour lire ceci et encore plus pour répondre.
1 réponses
Vous avez énuméré les avantages et les inconvénients de précision. Utiliser les deux vous donnera plus de travail en termes de maintenance, et aussi plus de complexité, mais vous donnera la flexibilité que vous recherchez. Il va bouillir vers le bas à vos exigences.
vous trouverez probablement aussi que d'avoir une prise.une connexion io ouverte dans un processus de fond iOS sera gênante. iOS est beaucoup plus restrictif dans ce que les tâches peuvent exécuter en arrière-plan que Android.