J'apprends comment implémenter le Comme je l'ai eu, l'ID d'enregistrement est un jeton qui lie l'application sur un périphérique spécifique au service gcm et au serveur d'applications; Donc, le backend peut envoyer des messages en aval directement à ce périphérique.
Dans mon scénario, je pourrais avoir utilisateurs multiples qui peut utiliser l'application sur le même périphérique, ce qui signifie qu'ils doivent se connecter dans l'application et ils ont un compte sur une base de données du côté serveur. . Dois-je stocker un identifiant d'enregistrement différent pour chaque utilisateur sur ce périphérique? Ou toujours l'identifiant d'enregistrement fait référence à l'application uniquement?
Et qu'en est-il du même scénario mais distribué sur plusieurs périphériques, car un utilisateur peut avoir plusieurs périphériques?
Merci d'avance. gcm à partir du côté client (Android) et du côté serveur ( asp.net ). J'ai passé un peu de temps à lire toute la documentation Google liée à GCM et j'ai également essayé l'échantillon qu'ils ont fourni.
Parce que j'ai besoin d'intégrer le gcm dans une application déjà existante, j'aimerais connaître certaines choses spécifiques.
3 Réponses :
Ceci concerne beaucoup le contexte de votre application et de ce que vous voulez faire avec les notifications
Avoir un identifiant d'enregistrement par périphérique ira bien.
Je gère mes multiples utilisateurs à l'aide des balises d'abonnement traitées par mon serveur.
Alors prenez le scénario si vous avez une application sport:
utilisateur A & User B Partagez le même périphérique. Chaque utilisateur s'abonne à une balise. Lorsque l'utilisateur A se déconnecte, vous effacez les balises associées à cet utilisateur et lorsque l'utilisateur B se connecte vous chercher à ses balises. Votre serveur connaît des notifications à envoyer au périphérique en fonction des balises que l'utilisateur s'est abonné à. Scénario de périphérique multiple: La même chose se passe, lorsque votre utilisateur se connecte. En vous obtenez leurs tags. L'appareil a également son propre jeton de GCM.
Ok, j'ai eu ton point. Je pensais aussi que cela pourrait être géré que par le serveur. Dans la base de données, je peux stocker une relation entre les utilisateurs et les identifiants d'inscription, avec un champ qui définit un périphérique actif ou inactif pour un utilisateur spécifique. Ainsi, lorsque le serveur doit envoyer un message en aval à un utilisateur spécifique, il récupère tous les identifiants d'enregistrement actifs et associés et envoyez la notification à toutes les personnes dans la multidiffusion. Est-ce que ça pourrait être?
Cela complique plus les choses, pourquoi gérer vos identifiants de base de données localement? Et si l'utilisateur supprime toutes les données, vous avez perdu des données pour plusieurs utilisateurs
Que voulez-vous dire avec si l'utilisateur supprime toutes les données ? Le serveur stockera tous les identifiants d'enregistrement envoyés et créera des relations basées sur des comptes. Comme indiqué dans l'autre réponse, cela pourrait être que lorsqu'un autre utilisateur connecte l'application, des informations doivent être envoyées au serveur afin de mettre à jour qui est associé à un regid spécifique.
L'ID d'enregistrement est l'ID de l'application, il peut être modifié si la version app est mise à jour. Votre notification push sera envoyée sur le périphérique avec votre application, quel que soit le compte d'utilisateur. Donc, chaque utilisateur de chaque périphérique recevra votre notification, vous devez stocker un seul identifiant de référation par périphérique.
Ok, mais si je dois envoyer la notification à un seul utilisateur spécifique? Dans la documentation, il est également signalé que " la demande à votre serveur doit être authentifié si votre application utilise des comptes. " "
Ensuite, vous devez stocker l'utilisateur actuel et l'identifiant d'enregistrement, où l'utilisateur se connecte. La situation avec un périphérique et de nombreux utilisateurs: Si le nouvel utilisateur se connecter, Device Envoyer des informations sur le serveur, que cet utilisateur a cet identifiant d'enregistrement l'utilisateur précédent avec cette inscription. L'identifiant doit être supprimé. Si l'utilisateur utilise plusieurs périphériques - DB doit stocker chaque ID d'enregistrement. Et vous enverrez appuyez sur les identifiants REG connus, qui correspond à votre utilisateur.
Selon votre suggestion, il est préférable de supprimer la relation entre un utilisateur et un regid lorsque un autre utilisateur se connecte à l'application, non?
Je pense que oui, car votre nouvel utilisateur recevra des notifications, que vous souhaitez envoyer à l'utilisateur précédent. Je pense que vous devez stocker uniquement des informations réelles - l'utilisateur de l'enregistrement actuel.
pour plusieurs utilisateurs: Si vos messages sont spécifiques à l'utilisateur, vous souhaitez extraire le jeton de l'utilisateur et vous abonner à celui-ci uniquement pendant qu'ils sont connectés. Lorsque vous changez les utilisateurs, supprimez / désenregistrez le jeton précédent. , puis enregistrez / enregistrez le jeton du nouvel utilisateur.
Vous ne devriez pas seulement faire cela si vous avez plusieurs utilisateurs par périphérique, mais lorsqu'un utilisateur vous indique. Cela empêchera les messages spécifiques à l'utilisateur qui s'affiche à des moments difficiles aux mauvais utilisateurs.
Avec la messagerie de groupe de périphériques, les serveurs d'applications peuvent envoyer un message unique à plusieurs instances d'une application exécutée sur des périphériques appartenant à un groupe. En règle générale, "groupe" désigne un ensemble de différents périphériques appartenant à un seul utilisateur.
Ceci est également agréable à cause du
collapse_key . Lorsque l'un des périphériques sur le même compte ouvre une notification, il renvoie la notification sur les autres appareils.