I am developing an Android app that needs to communicate bi-directionally with a server. By that, I mean either the server or the device can send a message at any time, with an arbitrary amount of time in between messages. Sending data from the device to the server is a common and I think well understood task, but I’m not as sure what the best approach is to go in the opposite direction from the server to the device.
I think having the device periodically poll the server may be a bad idea due to latency and the drain on the battery, but I’d be willing to consider this option. My plan at the moment is to send text messages from the server via an email-to-SMS bridge, and to have my app run a service to receive and handle these messages.
The question I have is if there are any best practices for this scenario, and if using text messages has some downsides that I have failed to consider. For the sake of this question, I want to assume that users have an unlimited text data plan, so paying per text won’t be an issue.
This is what XMPP excels at. 🙂
See the Smack Java library, or asmack for an Android-customised version.
And for an Android app that is using asmack for long-lived bidirectional communications, see BuddyDroid.
Edit, in reply to comment below:
The advantage of this approach in your case is that you can push unlimited amounts of to the client immediately, without the latency (or non-guaranteed delivery) of SMS. XMPP also gives you connection security, compression and the ability to layer your own extensions on top of it.
In addition — and I don’t know who you’re targeting or whether this applies — this way you don’t need to rely on the user having an unlimited text plan (but of course you need a data plan).
However, having re-read your question, you seem to imply a low rate of activity so perhaps it’s not worth maintaining (login, detecting connection loss, reconnecting) an XMPP session for whatever your application is.
Finally.. while you can intercept incoming SMS messages on an Android device, you cannot prevent them from showing up in the user’s messaging inbox. So you can process the incoming SMS, but you can’t then tell the system to discard the message.
I recently discovered this isn’t true: if you define an
android:priority attribute on your SMS-listening
intent-filter, you will then receive an “ordered broadcast” which allows you to cancel the incoming SMS broadcast before it’s propagated to other apps, like the SMS inbox. Note that this only works on Android 1.6 and above.