I'm writing a bingo application for android.
bingo game has alerts and notifications that supposed to go from the server to the client on real time.
the client also needs to notify the server in real time whenever he yells bingo or any other events.
now.. my question is, what's the recommended method for two ways communication between server and android client?
should I use websockets? regular sockets? long polling ? anything else ?
if I use sockets as the method of choice, what happens when the cellular phone is changing wan networks ? do i need to detect such a thing and reconnect the socket?
any information regarding the issue would be greatly appreciated.
The easiest method is to use Android GCM for server to client communication, and a RESTful API for client to server communication.
You can even try Parse library, that comes with their own SDK and solves most of the configuration.
Related
I have a very basic design of my entire application, where several users with my app on there android devices commits data to the server (I have used REST web services(java) + postgresql as my server) through HTTP post request from the android application. I am successful in achieving this and app runs absolutely fine. Now i want to implement a scenario where any change(CRUD operations) on my db on server should create a notification on my users android device. How should i achieve this with my server design unchanged? I have looked into Google Cloud Messaging, but could figure out the server implementation.
For now i have implemented db triggers on postgresql and able to get control back into java code using Notify/Listen feature of postgresql. From here i need to connect to android device. How can this be achieved. Is Google Cloud Messaging the only way? I have not seen any insert/update statements in there server implementation. Could anyone please guide me on this?
either you can use GCM or implement a Socket at server end and open a socket connection from mobile but this approach may add some additional processing overhead because it will create a daemon thread to listen socket port from mobile device.
You should use native library (NotificationManager etc.), here you can find a great tutorial.
My Advice is for you to use GCM. GCM normally takes a maximum of 4kb, so you could have your own defined "commands". You could use them to determine the requests on both ends, ie on android app and the server end. A php script on the server would help you in this.
I am working on an app where by the android app sends messages to the server via POST and the server forwards the message to the appropriate user via GCM. In my case I have very many things to share so in that case I am using commands, for example if it is a new incoming message I send a GCM to the app with one variable as the command and the rest as the data. On the android app I use the command variable to determine what to do with the data.
Kindly avoid that socket advice, it will have your app drain the battery to sustain the open socket , besides you don't have to re-invent the wheel while Google servers already has it
In my knowledge, most of android tutorials and examples out there rely on use of GCM for sending data from server to android device; and use php scripts along with post/get methods to send data from device to server.
A friend of mine(someone who doesn't have any knowledge of android programming) simply asked me, why can't we use Socket class in java? In traditional java programming, you use sockets (IP adress + port no.) to achieve functionality similar to GCM (single server multiple clients - using proper techniques you can ensure messages are not lost, just like gcm).
Can this traditional socket approach be implemented in android as well? If so, what are the pros and cons of GCM and Sockets? In which situations would the use of sockets be appropriate?
Whatsapp and lot of other apps, to my knowledge, use GCM. Are there apps which use sockets?
P.S: I'm just a C.S. student; apologies if I've got my concepts wrong somewhere
GCM uses sockets too. However, they are managed by the system and thus can do things a regular app cannot do. Generally, for any type of 'push' notifications, the system needs to have a long-lived socket, and a 'notification' is just some data received on that socket. All of this is not too hard to implement on an always connected machine, such as a desktop or a server, but there are additional challenges on mobile. For example, switching networks (3G<->WiFi), going out of range, maintaining a connection without keeping the device awake all the time (and killing the battery in the process). So yes, you could implement something similar using a service , sockets and your own server, but it's not trivial on mobile.
Check out http://mqtt.org/ for an open-source implementation.
I want to make a two player turn based game (think of tic tac toe) for android. I am not sure how to implement the communication between the mobile and the server. Should I use sockets or http client ? Can anybody guide.
Issue with http client is I have to regularly poll the server to see if any data has arrived. Is there any other way to push the data from server if I am using http client ?
Have you considered HTTP requests + push notifications? Depending on the particular kind of game this might be the best solution I guess...
You can use App Engine's Channel API
https://developers.google.com/appengine/docs/java/channel/
Even though there is no official Android library you can use this WebView wrapper
https://github.com/burcu/android-channel-api
but I haven't tested it yet.
This is an old question but if you are still looking for a solution you could try the new Google Play Game Services.
I am developing an Android App that communicates with a server.
How can I send a notification from my server to my Android App without the use of C2DM?
Are Sockets a good solution? What are other alternatives?
I'd suggest you to develop a webservice preferably with JSON which is easy to handle. This server client architecture will hellp you to send and receive any kind of data (ranges from raw text to images or even video)
Check out C# webservices. That are very easy to start than the PHP services IMHO.
Depends on what you want to do.
have you thought on how does the server identifies the client to send the message ? In this case the android phone ?
With http you would need the client to "request" this notification.
The closest thing to an actual notification would be to have a socket connection, which the client would connect to the server. But then would require an existent connection between the two. If this is ok for what you are doing, then go ahead if you really want to avoid C2DM.
But, using C2DM allows your server to send notification to devices without a need for a request or direct connection from the client. The only thing you need to do is pass the identification of the device to your third-party server given when you authenticate with google's C2DM. After that, you just push notification data to C2DM and google delivers the notification for you.
I've used MQTT for providing push notifications on Android and it's proved to be a good, reliable, low power solution.
Some links to support my case / get you started:
http://mqtt.org/
Power Profiling: MQTT on Android
Basic Steps for Using MQTT in android
I'm programming an Android multi-player game, which basically consist of a server where the clients connect and exchange messages. When the player connects to a server, a player list is return to him/her. A player can then select a user to challenge - of course he must select a player from the player list, which only contains connected users.
When a player1 challenges player2, a message needs to be transmitted from player1 to the server, which in turn must send a message to the player2, notifying him about the challenge. The player2 can then accept/decline the challenge.
I can use the following techniques to make this happen:
Use custom server/client with Java socket programming. The server basically accepts a connection from the client, spawning a new thread for each connected client. The problem with this are:
There needs to be a persistent connection open from client to server wasting battery life of the android phone. This is not really big limitation since the battery isn't consumed that much.
When I'll want to develop another game I'll have to rewrite the client/server code from the scratch - also choosing another port to listen for incoming connections - the whole concept gets rather difficult to maintain.
I'm also worried if this is the way to do it. Spawning another thread for each clients sound quite a lot if thousands clients are connecting at the same time. But I'm guessing the PC games do it like this. Not sure about android.
Use Java REST jersey to build the client-server on top of HTTP. This would be a perfect solution if the server could easily send notifications to clients. There are actually multiple design decisions here:
the client pulls the server for any new data/notifications every few seconds - this is really bad, since we're stuck with non responsiveness, delay, etc.
the client can send a waiting request to server, so the client receives the response only after some data becomes available. This is better, but can still produce a delay when two notifications one after another need to be sent to the user. The first notification is sent instantly, since the client already has a connection open, waiting for data to receive. But we would have to wait for the client to initiate another long http request to receive the second notification. The problem gets bigger as there are multiple notifications that need to be send in a row to a specific client.
the client can initiate a http streaming, where the communication is left open when the request is handled, so the server can also send multiple messages to client whenever it wishes. The problem here is that I don't know how well this works on Android. I've looked at several implementations:
Java jersey + atmosphere: didn't succeed in actually making it work. This seems the most promising, but I don't want to spend too much time on it, since I'm not even sure if it does what I want.
Deacon: seems pretty neat, but after seen the video tutorial on their official web page, I'm not sure that it can do what I need. When a player1 challenges player2, can it send a notification to player2 letting it know about the match request?
I would be glad to know how other multi-player games handle the network communications, if the two players are playing the game over the network.
I'm also open to a totally new suggestion how to achieve what I want. I can pretty much code anything, so don't hesitate to let me know of some more difficult way to achieve the network communication.
Let me also mention that I'll be glad to implement a totally specific method to work in my case, so it can be anything that will do the job done, but I'm also looking at more general way for communication between clients and server. So that I can program an interface/whatever and reuse the code in other android games, android applications.
I hope I presented the problem allright and that I'll receive some valuable answers.
Thank you
You should take a look at XMPP. It's a protocol (originally created for chat programs) that allows sending of xml data between users.
It has a separated client-server relationship, so that you can focus on developing a client application fit for phones, and a different server depending on your needs.
There are loads of information available on the protocol (I should know, I wrote a thesis about using the protocol in game applications), but you can start by looking it up on wikipedia to see if it is what you want.
aSmack is a library for creating android xmpp-clients. It takes some tweaking to set it up and get everything to work, but once you do, it's neat.
EDIT: relating to the answer suggesting using the C2DM:
from the c2dm docs "Sending large numbers of C2DM messages":
Are you sending C2DM messages too frequently? If you need to communicate with your application frequently over a short period of
time, C2DM is probably not the best solution. Instead, consider
implemeting XMPP or your own protocol to exchange messages, and use
C2DM only to send the initial notification.
It sounds like Android Cloud-to-Device-Messaging might be what you need
Push notifications without the app having to keep a connection open
I would vote in favor of some message passing technique - like activeMQ, rabbitMQ, zeroMQ eor something like it. On the server side you may stick with java , or javascript ( like
node.js ) - such solution would provide most performance and minimal latencies.
If latency is not that critical, you may as well use REST calls with JSON