Google Cloud Messaging with Payload

google cloud messaging (or gcm) sends two types of messages:

1. collapsible, “send-to-sync” messages, where  new messages replace older ones  in the sending queue. (i.e. the older messages are “collapsed”).
2. non-collapsible messages with payload, where  every single message is delivere  d.

each payload in non-collapsible messages is a unique content that has to be delivered and can’t be just replaced with a more recent message in the server sending queue. on the other hand, a  collapsible message can be a simple  ping  from the server to ask its mobile clients to sync their data.

when to use messages with payload? instant messaging (im) applications come to mind. another use case is when we need to include data into our push notifications to save our clients a round-trip to the server. an example use case would be sending daily/monthy online game rankings of top players. instead of just notifying the android clients to go to the server to get the information (  send-to-sync  ), the data is included in the multicast messages themselves so that they can be directly consumed by the clients. we can easily see why collapsible messaging wouldn’t make much sense here, since we want our users to receive every single ranking we send them at the end of every week/month.

let’s now jump into coding. as suggested in the two previous article, these code examples are modifications of the  gcm demo application  available for download (client + server) and using the  gcm helper library for java  .

server code

creating a message with payload in server code is  similar to the process  for the collapsible type, except that we simply omit the collapse_key parameter.

// in imports
import com.google.android.gcm.server.message;

// inside send method, construct a message with payload
message message = new message.builder()
 .delaywhileidle(true) // wait for device to become active before sending.
 .adddata( "rankings", "top 5 high game scorers" )
 .adddata( "1", "1. yankeedoodle (15 trophies)" )
 .adddata( "2", "2. billy_the_kid (13 trophies)" )
 .adddata( "3", "3. viper (10 trophies)" )
 .adddata( "4", "4. silversurfer (9 trophies)" )
 .adddata( "5", "5. gypsy (8 trophies)" )
 .build();

client code

the client just retrieves the data by its keys:

// inside gcmintentservice
@override
protected void onmessage(context context, intent intent) {
  // message with payload
  string message = intent.getstringextra("rankings")  + "\n"
                 + intent.getstringextra("1")+ "\n"
                 + intent.getstringextra("2")+ "\n"
                 + intent.getstringextra("3")+ "\n"
                 + intent.getstringextra("4")+ "\n"
                 + intent.getstringextra("5");

  displaymessage(context, message);
  // notifies user
  generatenotification(context, message);
}

this is how it looks like on an android device:

these messages can contain a payload limit of  4k  of data so they are not indicated for applications that need to send more than that, although it is theoretically possible to get around that limit with multiple messages and some assembly work  on the receiving android client application. another aspect to consider would be performance and impact on the handset’s batteries, since messages with payload are not as lightweight as their collapsible cousins. regardless of the message type,  all payload data must be string values  .  so if we need to send some other type, it is up to our application to properly encode/decode the content.