J'ai un service qui utilise Firebase Cloud Messaging pour communiquer avec ses clients Android en utilisant Messages de données FCM avec le collapse_key
ensemble de paramètres. Extrait de la documentation sur les clés rabattables :
Lorsqu'un message plus récent rend un fil plus ancien, le message en question devient sans objet pour l'application cliente et le FCM remplace l'ancien message. Par exemple, les messages de type "send-to-sync" ou les messages de notification périmés.
Voici ce que je recherche. Je n'ai pas besoin de toutes les mises à jour, seule la dernière est nécessaire. Mais, j'en ai besoin ASAP si l'utilisateur est en ligne .
Cependant, j'obtiens une limitation de débit bizarre qui n'entraîne aucun code d'erreur HTTP. C'est assez facilement reproductible, il suffit de faire 20 messages de données consécutifs et de surveiller l'Android. FirebaseMessagingService.onMessageReceived
:
for i in {1..20}; do
curl -v -X POST --header "Authorization: key=$SERVER_KEY" \
--Header "Content-Type: application/json" \
https://fcm.googleapis.com/fcm/send \
-d "{\"to\":\"$CLIENT_TOKEN\", \
\"data\":{\"counter\":\"$i\"}, \
\"priority\":\"high\", \
\"collapse_key\": \"test\" \
}"
done
Le script bash ci-dessus est un peu difficile à lire, mais j'ai un counter
variable qui m'intéresse.
Après quelques messages reçus ( counter=~10
) il s'arrête et vous devez basculer l'état du réseau pour obtenir le dernier message avec counter=20
. Le dernier message apparaît également après quelques minutes (normalement ~10 minutes) lorsqu'un check-in firebase est demandé ( ?).
Suppression de collapse_key
de la commande curl ci-dessus a pour résultat que les 20 messages sont reçus (où counter={1..20}
).
Donc, la question : Est-ce un bug ? Ou est-ce que je suis en train de m'éteindre (/débit limité) parce que j'abuse de l'interface (puisque toutes les requêtes renvoient un 200
réponse, je pensais que j'étais bien).
0 votes
Notez que j'utilise "Messages de données" et non "Messages de notification" si cela fait une différence.
0 votes
Les deux sites
priority
ettime_to_live
sont spécifiés en dehors de lanotification
oudata
de sorte qu'il n'y a pas vraiment de différence entre le type de charge utile que vous utilisez (bien que chacun d'entre eux ait un paramètre de type Valeurs par défaut ). D'après moi, pour ce qui est de la latence, il est préférable de définir simplement le paramètrettl
à0
mais comme vous le savez déjà, le message deviendra une maintenant ou jamais type de message. Mais selon le comportement de FCM (même avant pour GCM), il tentera d'envoyer le message dès que possible, en fonction des paramètres.0 votes
@AL. On dirait que
collapse_key
obtient un taux limité voir ma question éditée.0 votes
Si je comprends bien le scénario que vous avez ajouté, l'ajout du
collapse_key
à votre charge utile traite votre message comme pliable dans lequel si le message précédent avec le mêmecollapse_key
n'a pas encore été envoyée au dispositif, elle sera supprimée et remplacée par la plus récente avec le même numéro d'identification.collapse_key
. Donc le comportement que vous avez vu où pas tous les messages aveccollapse_key
sont reçus est conforme aux attentes.0 votes
@AL. Je pense que c'est un bug. J'ai réécrit ma question une dernière fois.
0 votes
Cela se produit-il à chaque fois ? Après avoir reçu près de 10 messages, il s'arrête ?
0 votes
Je pense que c'est un bug ou peut-être un problème de réseau.
0 votes
@PravinD oui, je dirais environ
10
. Mais pour être sûr, changez le compteur de la boucle ci-dessus en100
et voyez où il cesse de recevoir les mises à jour. Je ne pense pas que ce soit un problème de réseau. La même chose se produit sur le wifi ou le mobile du côté des clients Android et du point de vue des serveurs, toutes les demandes reçoivent une réponse positive.0 votes
Il y a une limite de 100 messages qui peuvent être stockés sans s'effondrer. Si cette limite est atteinte, tous les messages stockés sont rejetés. Lorsque l'appareil est de nouveau en ligne, il reçoit un message spécial indiquant que la limite a été atteinte. L'application peut alors gérer la situation correctement, généralement en demandant une synchronisation complète au serveur de l'application. Cela pourrait être le cas ?
0 votes
@PravinD cela ne s'applique qu'aux messages non collapsables, n'est-ce pas ? J'utilise déjà des messages rétractables.
0 votes
Oui, vous avez raison.
0 votes
Il me semble que c'est un bug et je vous suggère de le poster. firebase.google.com/support