Adventures after Google I/O-3(GCM).

• Part 1
• Part 2

It is nice to see Google is giving better tools to iOS alongside android. One of the most exciting announcement is GCM 3.0. Giving us some awesome functionality like topic messaging and device grouping, one of the most awesome thing is native support to iOS and (probably chrome only) browser notifications, making life of web developers team easy.

Now they don’t have to code differently to send notifications to android and iOS. Without worrying which user is registered on which platform, the notification is surely to be delivered. However things are not that straightforward for all the platforms.

Setting up for Android and for iOS is simple and just following guides in Google Cloud Platform will set up GCM in your application(s) in matter of minutes. If you are not familiar with cocoapods it will take almost an hour or two to setup everything.

What is Problematic:

Web developers who have previously had experience to send notifications with GCM or those who just started after watching this session from Google I/O, have started sending notifications with GCM hoping that their notifications are delivered properly, which is true for Android atleast, however notifications on iOS are not delivered when iOS app is in background.

If this is the problem, and everything from iOS (APNS server and Google Cloud Console) configured properly, chances are high that web developer is sending notifications like below.

{
  "to" : "APA91bHun4MxP5egoKMwt2KZFBaFUH-1RYqx...",
  "data" : {
    ...
  },
}

However with such notification, code in andriod is received in NotificationReceiver class which extends GcmListenerService and works fine as usual. Even in iOS we receive notifications when app is in foreground, but not in background, reason? We are missing one more object in above json, notification object.

{
  "to" : "APA91bHun4MxP5egoKMwt2KZFBaFUH-1RYqx...",
   "notification": {
    "title": ...,
    "text": ...
  },
  "data" : {
    ...
  },
}

And your android client will continue working as usual isn’t it? No, If we extend GcmListenerService we won’t get any control on how notifications are displayed. The good thing is that GcmListenerService will take care of many things, like replacing notifications when tag is set in notification object, click handling.

But bad thing for android is that many advanced functionality regarding to displaying notifications are lost. We can’t display images (like avatars) as notification icon, instead server has to provide an icon value in notification object, which must be one of the drawables in our application, and without icon property notifications on android are neither visible, nor can be handled from anywhere. Even I am not sure that right now handling any advanced action button is provided or not.

Even to handle notification click there must be a click_action value in notification which must correspond to an action in one of our activity, if none of these conditions are met, notification will stay there permanently.

If as an android developer you are ok with this backdrops, GCM 3.0 is otherwise nice tool to handle push notifications. With topic messenging and device grouping web development guys can even forget about maintaining a table for notification preferences or mapping or managing multiple keys for same user.

Workaround

Is there any legitimate work around for android? I don’t think so… You can continue using old WakeFulBroadcast receiver or don’t move to GCM 3.0 at all. But going this way can be harmful for long term. Because I have a feeling that Google will catch up with all the things (probably) before next I/O. But overall for me

GCM 3.0 is a nice mess or better say a chaotic beauty.

Next In the series: Concluding this series with Databinding.