Google Cloud Messaging is one of the best cloud based services available today for Google’s open source platform, Android. It was first unveiled on June 27, 2012 but it was this year’s I/O Conference which revealed the massive potential of this service and its impact on android applications.
The Google Cloud Messaging Concept
Google Cloud Messaging is like an intermediary information exchange centre that is hosted in the cloud and acts as the connecting point for servers and apps. It was revealed that the latency of information exchange in the service has been brought down to 65 milliseconds from 90 milliseconds (relatively high latency was evident in the initial phases). As a result you can now send out 4000 messages per second from a single channel. Google has the facility for managing up to 10 channels, so you can send up to 40,000 messages in a second. Can you imagine the speed to communication that it offers?
One of the most important uses of such communication services is in the implementation of push notifications where messages from the server are sent to the mobile app. Push notifications need to be delivered on time, sometimes to several people simultaneously. Such capabilities are crucial for creating and maintaining a dynamic yet engaging user experience. This brings us to a crucial aspect of the GCM service. The importance of push notifications has gained such importance that developers need to do anything and everything to ensure the reliability of their messaging service.
Ensuring the Reliability of GCM for Android
Speed and Reliability are the key components of ensuring the implementation of GCM for Android apps that use push notification services. Developers often have to face obstacles because they are either unaware of the origin of the issues or they do not expect it to occur simply because it is not mentioned in the manual.
Here are 3 tips that should help you to overcome these challenges.
Use Exponential Backoff for Resolving Registration Issues
I am sure most of you have faced the registration issue when implementing GCM where the “registration” call fails often and returns an I/O exception containing the message “SERVICE_NOT_AVAILABLE”. The reason that developers have a difficult time resolving this issue is because it never shows up during test runs on test devices. Moreover, nothing is mentioned about this in the setup guide as well. That is why the surfacing of such issues is not expected by anyone and if you do not anticipate this issue before releasing the app into the market, you could garner a lot of negative feedback with respect to the reliability of your messaging service. The root cause of this problem is that the GCM was not able to successfully execute the registration protocol and the only way to resolve it is to keep trying. This is exponential backoff would be a good approach in this situation.
Check the Permissions For Fixing Repetitive Registration Failure on Some Devices
Even after you have managed to correct the “registration” bug using exponential backoff, there is a possibility that the bug would continue to exist for some devices. The technical aspect of this issue states that even if the registration function is returning an exception, the registration ID is being created by the system. The problem lies in the fact that this registration ID is not being returned.
In order to rectify this issue, you need to add a special permission to the Intent Filter of the GCM’s Broadcast Receiver. The following permission needs to be added.
<action android:name=”com.google.android.c2dm.intent.REGISTRATION” />
This will give you the registration ID in the following format
final String registrationId = intent.getStringExtra(“registration_id”);
This should resolve the registration issue for some devices and this permission works only if the value being returned is not null or void. Now that you have the registration ID, you can process it further by saving it and redirecting it to the server. This issue may have been fixed by Google itself, but in case you are experiencing this problem, then you may use this method.
Re-Register Your Device After Every App / OS Updation
Push messaging only works when the registration ID is available with the server. Whenever the destination app or OS is updated, the value for the registration ID changes. So unless the new values are replaced in the GCM, the messages would not come and the device would be reported as unregistered. You need to work fast while responding to any update that has been made to the app. As soon as the app has finished updating, the re-registration processes should be triggered and the new ID should replace the old ID. This will help to maintain the reliability of the push notification service that has been integrated in the app.
Registration IDs are based on the specific Android ID of the device of the user. Whenever the OS is updated or the device is reset to factory settings, the Android ID changes. As soon as this occurs, the new ID needs to be re-registered in order to ensure the maintenance of the communication flow between the device and the server. GCM re-registration needs to be triggered immediately after the OS has updated because there is a delay between the completion of the update and user accessing it.
The best way to achieve this is to get your app registered to receive the Intent Android broadcasts which would return information about the need to re-register the device every time the value changes. This can be done in the following manner
Step 1: Add this permission to your Android Manifest
Step 2: Set up and add a BroadcastReceiver to get intimation about changes in ID values
<action android:name=”android.intent.action.BOOT_COMPLETED” />
By following these simple tips, you should be able to resolve the major challenges and in turn, you would be able to maintain the reliability of the GCM service for your app.