4

The docs say "C2DM makes no guarantees about delivery or the order of messages. So, for example, while you might use this feature to tell an instant messaging application that the user has new messages, you probably would not use it to pass the actual messages."

I'm building an app where messages will be passed, and where it is important that they are delivered. It's in some ways analogous to an instant-messaging app.

Some options that come to mind...

  • Send the message using C2DM, but have the mobile app do a callback on receive to notify the server (this has the obvious limitation, but the app isn't mission critical)

  • Use C2DM to notify the app that there is a new message, and then read it off an app server - using polling to handle C2DM failing to notify

  • Use C2DM and accept some messages won't get delivered. It's not clear to me why a message wouldn't be delivered. I guess C2DM has a retry limit so if the device is offline, it may never arrive. It's also unclear to me what % to expect to fail.

What approach would you recommend?

Ollie C
  • 28,313
  • 34
  • 134
  • 217
  • What purpose will the C2DM notifications serve? Will they just notify users of new messages when the app is not in the foreground? – Kevin King Jul 26 '11 at 12:18
  • Yes, either through notifications or by firing up the app. The messages are short, so the 1024 char limit shouldn't be an issue. – Ollie C Jul 26 '11 at 12:32

3 Answers3

3

I think C2DM is a good solution for you to implement. As Google recommends, I believe you should have the device contact your server when it receives a notification from C2DM. This way you are sure that messages are being received in the correct order, as Google also does not guarantee the order in which messages will be received. In addition, if one push if lost, that message would be lost, but if you have the phone contact your server on the next push, you can show the whole history and avoid losing any messages.

Kevin King
  • 1,549
  • 11
  • 14
  • 1
    But herein lies a problem, doesn't it? If C2DM doesn't guarantee that notifications will be delivered, this process must be augmented with the device polling for new messages. – Peter Lillevold Jul 27 '11 at 06:52
  • Polling is very unfriendly to batteries, and I have seen reliable results in my application so far. Out of more than 200 pushes, I haven't witnessed a failed delivery, granted we are still in development phase. – Kevin King Jul 27 '11 at 11:55
  • Sure. But as long as there is no guarantee of delivery, my thought is that a combination of c2dm and polling will be required to "fix" that guarantee. Polling should happen only on specific points in the app or at a very low frequency, and also be skipped when notifications have been received. – Peter Lillevold Jul 27 '11 at 12:36
  • Very infrequent polling could work as a failsafe measure then. Maybe if a message hasn't been received in a certain amount of time. – Kevin King Jul 27 '11 at 12:40
1

Why do you need to deliver the payload inside the C2DM message? Send a C2DM message telling the app that there is new content, make the app go to your app server to fetch new content. Use this last call as a confirmation of the delivery of the C2DM message. This way you can implement a timeout in the app server and send again the C2DM message.

Else I would say that C2DM isn't what you are looking for.

aromero
  • 25,681
  • 6
  • 57
  • 79
0

Regarding: "Out of more than 200 pushes, I haven't witnessed a failed delivery"

In my experience the delivery behaves differently when the device is charging v.s. running on battery. I did a lot of initial testing while the device was plugged in and saw different results in the field. Has anyone else seen this? Is there a deeper power save mode that is not entered while charging?

Ayyrk
  • 189
  • 1
  • 10