Login/Register
Android device needs to be connected to server - C2DM, polling or something third?
Asked Answered
Solved androidconnectionandroid-c2dmmqtt
Q

2

1

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?

Quantity answered 3/11, 2011 at 21:14 Comment(0)
D
1

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:

Dissected answered 5/11, 2011 at 9:44 Comment(1)
Thank you for a great post with links to more information about MQTT. I accepted your answer for the detailed description which enabled me to move along with my development. – Quantity
W
4

I stumbled upon a new service called Parse.com they seem to offer functionality for easy push-implementation for Android using their backend. It's commercial but they have a free plan too.

If you want to do your own implementation there seems to be a lot of articles about using MQTT which is designed for low-power devices. But I haven't seen any ready-to-use implementations of this yet.

Westphal answered 3/11, 2011 at 22:42 Comment(0)
D
1

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:

Dissected answered 5/11, 2011 at 9:44 Comment(1)
Thank you for a great post with links to more information about MQTT. I accepted your answer for the detailed description which enabled me to move along with my development. – Quantity

© 2022 - 2024 — McMap. All rights reserved.