Reputation: 29122
I may be asking a bit much here but I have faith in the community so it's worth trying. I'm making a game and I'm trying to pick the connection type to use for communicating between a Java mobile client and a Java server backend.
Socket programing in Java is easy - there's a lovely tutorial on the subject and two way communication is trivial.
Trouble is that on a mobile client (Android) it's not guaranteed that the cellular network will let you make TCP connections. That makes me think using an HTTP connection is the way to go.
HTTP connections are request based but I need a way to push notifications from the server to the client. It seems the solution to this problem is to use 'long polling' I have read a bit about it but have yet to see a simple example for what I'm trying to achieve.
Again I might be asking a lot but this seems like a fairly common problem, is there a library or framework I can import / use to wrap a Http connection and provide a two way long standing connection (That reconnects automatically etc). I read a bit about cometD but it doesn't seem to have a Java library that I can just pick up.
The communication I need is not heavy, not constant two way streams of data just occasional updates either way to keep the game going.
Thanks in advance for sifting through my ignorance,
Gavin
Upvotes: 1
Views: 3473
Reputation: 189474
Doing long polling on the device has some disadvantages on a mobile device.
If you want to try a game that shows this problems try Parallel Kingdom Age of Emergence.
I would look into XMMP as proposed by alex. If you can't find a XMMP librarie on Android use Smack. Or have a look at this question.
Upvotes: 1
Reputation: 11446
The Comet model tries to solve this problem when using HTTP. There's some Java examples here.
You'll find examples/articles mostly talking about ajax/XMLHttpRequest on the client side, but all you really need to do is ensure you're using a client library utilizing http/1.1 and http keepalive, and "poll" the URL in a loop.
The idea is the server server blocks and doesn't send you a response until there's actually something worth noting, while http keepalive keeps the connection to the server up between the requests so you don't pay the price of setting up a new TCP connection for every request - I'm assuming android already has a standard http library which should handle all this for you, including reconnects.
On the server side, Tomcat suports Comet processing as mentioned in the developerworks article above - unless you want to do it "manually" in a servlet which is also pretty starightforward until you need to really scale the no.. of client.s, and there's frameworks such as gwt-comet
Upvotes: 0
Reputation: 111565
As Jim Lewis mentions, TCP is entirely possible. Whatever transport you use, you're always going to end up having to deal with working on mobile — i.e. loss of service, reconnecting etc.
Check out this previous question along the same lines:
Best approach to send data from a server to an Android device
Also, you could try taking a look at Ericsson's Android push library, which may encapsulate some of the reconnection stuff you want (not that I've checked):
https://labs.ericsson.com/apis/mobile-java-push/blog/first-version-push-android-available
Upvotes: 0