I’m currently in the process of developing an app which has some very demanding needs.
The Project
An application which can communicate with a server is needed.
Small messages has to be send to the app which could display a notification or start an activity.
The Demands
Client needs to be sure that the phone is ‘connected’ at all times.
The client expects that the app can tell when it’s no longer connected (or able to connect) to the server it tells the user.
Client needs to be able to send a message to individual devices
If the client needs to broadcast a message to the connected devices and to the individual devices.
My thougts (or problems)
Currently, the app is polling the server with a http request once a minute – if the app isn’t able to connect to the server the user gets notified. The polling is able to tell which device is calling and telling it if it has a message for it.
But…
IMO this is a terrible design – it generates a lot of excess traffic, uses resources which probably wasn’t necessary and it offers a lot of issues with connectivity (which I’m not sure I’ll ever get past no matter which method is used).
I need your experience to select the right solution for my project.
I’ve been thinking of C2DM, but I’m not sure this could cover my needs?
Is polling for my only real solution?
Is there a third option I haven’t thought about?
I’d consider MQTT as a good solution, although it is what I’m most familiar with. Disclaimer – I write an Open Source MQTT broker. You could achieve what I think you want like this:
Have an MQTT broker running somewhere. The service on the phone connects to the broker and subscribe to a unique topic, e.g. device/23412364, where 23412364 is the per device unique id and referred to as <phone id> below. When your client wants to send a message to a specific phone, the message goes to device/<phone id>. If you want messages to go to all phones, then the phones could also subscribe to device/all for example.
If you make your subscriptions and messages have Quality of Service of 1 or 2 and set the “clean session” option for the clients to false, then messages will be queued up on the broker if the phone disconnects for whatever reason. QoS=1 means “at least once” and QoS=2 means “exactly once”. When the phone reconnects, those messages will be delivered.
You could also have the phone send a message like “register <phone id>” to a fixed topic just after it connected (topic of “register” for example). A feature of MQTT that is very useful is the “Last Will and Testament”. When you connect a client, you have the option of specifying a Will message and the topic that it should be delivered on, in the case that the client disconnects unexpectedly (ie. without telling the broker that it is going to disconnect). So you could set the will message to be “unregister <phone id>” and to be delivered to the same fixed topic as above (“register” in this example). You could then have another MQTT client at the server end sitting subscribed to “register”. When a phone connects, it sends a “register <phone id>” message, when it gets disconnected the broker sends “unregister <phone id>”. The MQTT client can therefore keep track of the connected clients at the server side.
At the phone end of things, you can get notified if the TCP connection goes down through normal network code.
Some relevant links: