1

I've asked already about collapse key limit and get correct answer here from @ianhanniballake. Now, i want to precise something. The limit on GCM collapse_keys is on a per app level. What does it mean app level? For example, there is two apps installed on two corresponds devices, i.e.

  1. Device1->AppInstance1->Reg1
  2. Device2->AppInstance2->Reg2

Whether the each app's instance can have 4 collapse keys a maximum or 4 collapse keys is on all app instances? What is link between gcm registration id and 4 collapse keys, 4 collapse keys per one registration id or 4 collapse keys per all registrtion ids (per all users of app)? In our app we have user session entity, which can live two mounth, can we use session id as collapse key or collapse key must to be only constant string? Somebody help me please!

Community
  • 1
  • 1
Samik
  • 890
  • 1
  • 8
  • 16

1 Answers1

1

The 4 collapse key maximum is 4 per device, which means 4 per app instance (and since each app instance has a different Registration ID, this also means 4 per one Registration ID).

GCM allows a maximum of 4 different collapse keys to be used by the GCM server per device any given time. In other words, the GCM server can simultaneously store 4 different send-to-sync messages, each with a different collapse key.

(Source)

As for using session id as collapse key, there is nothing stopping you from doing that, but there is really no need. Since messages are collapsed only for the same collapse key and same Registration ID, you can use the same collapse key in all your app instances. I'm assuming this would make your server code simpler.

Eran
  • 387,369
  • 54
  • 702
  • 768
  • Thank you for answer! I hope you are rigth. There is a some problem to use same collapse key for all app instances. For example, when app has a multi account feature that would be desirable that messages in one account didn't collapsed(clear) the message in another. Of course, this can be resolved by changing server business logic, but such changes of the server trouble us :) Maybe you can give me advice how we can achieve a good result with sync-to-load mechanism and multi user feature in the app? @Eran – Samik Nov 08 '14 at 10:29
  • 1
    @Samik If two app instances are sent messages with the same collapse key, the message sent to one app instance (identified by one registration ID) won't collapse the message sent to the other app instance (identified by another registration ID). Or did you mean multiple accounts for the same app instance (on the same device)? In that case, using a different collapse key for each account would quickly exhaust your 4 collapse key limit per device. – Eran Nov 08 '14 at 10:37
  • yes, i mean multiple accounts for the same app instance and i also think that collapse_key limit will be exceeded in this case. Probably this problem sould be resolved on our server side. @Eran – Samik Nov 08 '14 at 10:42
  • May i ask you another question!?) Whether you sometime solved gcm heartbeat problem with tcp connection which good described [here](https://productforums.google.com/forum/#!topic/nexus/fslYqYrULto%5B1-25-false%5D). We have voip feature in our app, and gcm push delay is inadmissible for us. If you can route me to right topic about this problem i will be very appreciate you. Workroun like [this one](http://stackoverflow.com/questions/19560448/how-to-avoid-delay-in-android-gcm-messages-change-heartbeat) looks not very good((( @Eran – Samik Nov 08 '14 at 10:46
  • @Samik I can't help you there. I only worked on server-side GCM implementation. I didn't have to deal with the client side beyond demo apps. – Eran Nov 08 '14 at 10:53