3

I'd like to implement two way communication between a cross platform mobile client (Android, PC - written in Java and iOS written in Objective-C) and my Google AppEngine (Java) server. It should:

  1. Allow each side to initiate the communication (after the client connects).
  2. Have relatively short latency (polling every X seconds is problematic, and to my understanding, since it's on AppEngine, long polling an http request is not an option).
  3. Support messages that are at most few KB of text, and usually much smaller.

I have considered using the Channel API with some reverse engineered Java client, but this seems like taking a chance (since it isn't officially supported). Also, I'm not even sure there is a solution for Objective-C, and I prefer not to dive in and implement it myself.

I then considered using XMPP. However, I'm not sure how this is possible without having my users enter a Jabber account, which I cannot (the communication is in the background). Is there a way to create a temporary user for my client?

C2DM doesn't seem like a good option either. It's not cross platform, it seems very focused on "notification" and not communication, and makes no guarantees on the success of message transfer.

Or perhaps there is a completely different approach I haven't thought of? This type of communication is relatively new to me.

Thanks!

EDIT:

Since I'm looking for background communication, a new option came to mind: A single XMPP user, with resources as client identifiers. Meaning, I'll create a single XMPP user for my app once (something like: "AppBackgroundUser@domain.com"), and have the clients connect with their own unique ID as a resource ("AppBackgroundUser@domain.com/UNIQUEID"). Are there any drawbacks or severe security flaws to this method?

DannyA
  • 1,571
  • 2
  • 17
  • 28
  • For the communication from server to client, have you considered a third-party push solutions such as http://beaconpush.com/ ? – Ibrahim Arief Jan 31 '12 at 09:30
  • Thanks. I haven't found solutions that meet all the requirements stated above. Specifically, correct me if I'm wrong, but beaconpush aims for web pages (using javascript, etc.), while I need communication with my native applications. – DannyA Jan 31 '12 at 09:59
  • I admit I haven't use beaconpush from native clients as per your question, but I got the impression that their underlying API is a REST API and writing a client that communicates with their API should be feasible for native environment that allows HTTP requests. I saw one lightweight C# client on their open source contributions page http://beaconpush.com/guide/contributions/ so I thought a port of the client to Objective-C and Java is possible. – Ibrahim Arief Jan 31 '12 at 10:12
  • I'm not sure how a REST API can help here... the server can't access my client application using an http request. I can only use long polling on the server from the app, and here it isn't even on my own server. It seems like a too complicated and inefficient approach, doesn't it? – DannyA Jan 31 '12 at 10:19
  • From your requirements, I'd had thought to XMMP, too. Google app engine natively supports XMPP. On the Android this shouldn't be too difficult (a service has a `XmppConnectionAdapter`, get the degault gmail account with `manager.getAccountsByType("com.google")`). On iOS, I don't know. – rds Jan 31 '12 at 14:22

2 Answers2

2

Two options I can think of:

  • You could embed an HTML page in your Java app and use the Channel API for its anonymous endpoints. Then signal out to your app when you get a message. This won't be subject to vagaries of changes in the Channel API's implementation.
  • You're correct that you need an XMPP account of some sort if you want to use the XMPP API. You could consider running a very simple XMPP server on AWS or elsewhere and connecting your clients to that; then you can send messages from your App Engine app to addresses on your own server. ejabberd seems to be the service of choice.
Moishe Lettvin
  • 8,462
  • 1
  • 26
  • 40
  • The OP was on Google app engine, that natively supports XMPP. – rds Jan 31 '12 at 14:23
  • The issue is that, if you use XMPP from App Engine, you need an account to send the XMPP messages _to_. He said that he didn't want to use a user's existing Jabber account because the messages should be sent in the background (and presumably not show up in other clients, or require Jabber login from the app, etc.). So a way around this would be to run a very simple XMPP service that handles anonymous endpoints that the clients can connect to and that can be addressed from App Engine's XMPP API. – Moishe Lettvin Jan 31 '12 at 14:59
  • I now understand the problem. I don't get how an intermediate ejabberd helps, though. I'm disappointed to see that XMPP doesn't have "invisible" messages (the closest is type="headline", but a compliant client SHOULD present the message) – rds Jan 31 '12 at 15:10
  • XMPP does have stanzas, but App Engine doesn't support them. You could still use stanzas, and address them to the resource of the client app, but that still doesn't get at the primary problem, which is that the OP wants an endpoint to address messages to which isn't tied to a user account and so doesn't require login. That's the piece the ejabberd intermediate server would fix. – Moishe Lettvin Jan 31 '12 at 15:41
  • Thanks for your useful responses. I see there is no "trivial" solution, where I admit I expected one to exist... I'm tending towards the second solution. The reason is that it implies a "dumber" client (just use an existing xmpp lib). Since I aim for cross-platformness, for some more work on the server, this removes the need to create different wraps for each platform's javascript client (PC, iOS, Android, etc.). If you have any more tips on this direction, or other alternatives, I'd love to hear them. – DannyA Feb 01 '12 at 11:11
  • On the other hand, the extra hop may be a bit expensive on latency, wouldn't it? I'm not that knowledgable on how xmpp works. How are the messages routed using the xmpp server? Thanks. – DannyA Feb 01 '12 at 11:14
0

XMPP seems like your best bet, but you need to configure your server to allow anonymous clients to get around your registration issue.

I am not sure what you mean by either side initiating communication though. XMPP will require the client to initiate by connecting to the server, but after that it can receive messages unprompted. Of course, if the intent is for the server to send unprompted messages to a client, how do you know what client without some sort of client identity (which means some form of registration)?

Robin
  • 24,062
  • 5
  • 49
  • 58
  • Sorry for confusing regarding the "initiating communication". You're completely right. It was just meant to emphasize that I need a two way communication method as opposed to "push notification" or just client side http request. I'll clarify the question. Thanks! – DannyA Feb 01 '12 at 10:58