Adventures after Google I/O-3(GCM).July 07, 2015
2 minutes to read.
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.
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,
Just change your notification json which looks like above json and your iOS application will also receive notification when it is in background. Populating it’s information from
text from notification object. #1
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.
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.
Reference for notification object and other objects are here