Monday, May 7, 2012

Pushing Messages onto Android Apps


The push model is the concept of a service sending unsolicited or unrequested data to a client. The alternative to the push model is the pull model: a client requests data from a service. The pull model is easy to implement in Android applications. On the other hand, implementing the push model can be quite tricky and it is the subject of today’s post. Here we review two different methods that both have the ability to push data onto Android apps.
Short Message Service (SMS)
Push data is sent by having the server dispatch an SMS to all concerned Android devices. Then, the client application on the device intercepts the SMS and interprets its instructions. The advantage of this technique is that it is relatively easy to implement, well documented, and efficient in its use of resources. The disadvantage of this approach is that costs are usually incurred when sending SMSs. With that said, there are a few free SMS delivery services.
Persistent TCP connection
The Android app establishes a TCP connection with the server, lasting until the mobile device is switched off. The connection is inactive in the sense that no data is exchanged between the server and client, unless the server wants to send data to the client.
This method is not as efficient in the use of resources as SMS because:
  1. Keepalives must be sent periodically from the client to the server which can significantly impact the device’s battery life. Keepalives are necessary as without them, the server or intermediate nodes (e.g., proxy) may think the connection is dead and terminate it. However, there is information out there on how one can obtain infrequent keepalives (up to a keepalive every 30 minutes).
  2. The server must allocate resources for each idle connection so some scalability issues may arise.
There are two ways that you could obtain a persistent TCP connection:
  • Implement the functionality yourself:
    There are existing libraries and sample code out there that facilitate the effort of implementing a persistent TCP connection. Unfortunately, none of these are complete and any solution would require a lot of custom code. Interestingly, there is a blog post that describes in some detail a possible solution using a lightweight protocol called MQ Telemetry Transport.
  • Use a 3rd party service:
    It is possible to outsource the pushing of messages to 3rd parties. Google offers such a service. Although their service is free, the service is still in beta stage and has a serious constraint in that it requires the device user to be logged into one of Google’s services (e.g., Gmail). Xtify and Urban Airship also offer push messaging services. However, they have some restrictions such as the number of users supported and how many messages may be sent per day for each user. Additionally, payment is required for some features.