I'm developing android application where users can compete in some kind of battles. On the server side I need to receive requests from user for starting a battle, and then, using some algorithm, choose the most preferable opponent for him. During a battle I also need to send notifications to competitors about their opponent's actions.
So it seems that I need to implement long polling on my server. My questions are:
Server side. I'm using asp.net mvc server. I had a look at SignalR framework and it seems to be just what I need. However, just because I'm new to long polling, I haven't understood its internal principles of work. So I need explanations on how to use this framework, or how to implement long polling some other way.
Client side. As far as I understood, long polling requests model slightly differs from standard "request-response" model, so I'm also wondering how to implement these requests on client side.
I'm looking forward to any explanations on subjects that I've described.
This might not be the answer you are looking for, but why do you want to go for long polling. you can do the "pull" kind of polling for this type of notifications IF you are only polling when the users are engaged in battles. This way battery life will also be saved.
When the battle starts, start a background service, which polls the server every 2-3 seconds(hope a latency of 2-3 seconds is acceptable). And notify the user accordingly. Then stop the service when the battle is over.
This will be far more easier to implement.
But if you need instantaneous notification, you can use Google Cloud Messaging Service(it is a form of long-polling). To know more about how it works, see this
I am not sure, if you have considered WCF.
Take a look onto this, see if it helps you.
http://anthymecaillard.wordpress.com/2012/06/06/wcf-real-time-web-development-with-long-polling/
For client:
Use Jquery, with progress wheel showing till our response is back from the server
Related
I'm currently developing an mobile application and rest service. The mobile application executes lots of calls to the service even if no update is required and data didn't changed. In order to remove this overhead of rest calls I'm planning to implement GCM (Google Cloud Messaging).
My strategy would be the following:
Load all required data on application startup. When data change was recognized on server side a push notification will be sent via GCM to affected devices to make partial refreshes of data (via specific rest calls). Advantages of this would be less overhead at service side, because there are no unnecessary rest calls and a more fluid user experience in my opinion. Disadvantage is that the app is dependent on GCM Messages and that they arrive in time.
I'm unsure if this is the right strategy for this. Could someone maybe point me in the right direction and tell me if this is a good practice?
We could use more information before answering details...
I'm unsure if this is the right strategy for this. Could someone maybe point me in the right direction and tell me if this is a good practise?
I will consider for the sake of giving an overall answer that:
A - User is not always with the application "online", neither has network, not even a desire to have updated info at all times.
B - User is eletronicaly litterate enough to understand difficulties with the program.
With those in mind, then what would be a good approach is:
Poll relevant data, store them locally. At this stage, one would consider the relevant informations that user would have and store them, with a date flag.
Once a flag goes "old" (below your threshold), re-query that data.
Operations follow 2 directives... When observing a data, check its state, show the user if its recent or not, and if its not, poll it. If it is, if the user selects operations on it (POST mostly), re query the data.
This way, you have no static overhead, if users dont have the app on foreground. Also, should they use your "always online app", they understand that network is a necessity.
Currently, I'm working on my new project - a (quite) simple game on Android allowing users to play with each other. One game is divided into few rounds, that users play separately. When one user has finished his round, application should send message to a server, which, in turn, should send notification to the other player with set of actions made by first player.
Beside that, players should be able to send invitations to the game to other players and server, for its own, should be able to send notifications, when, for example, user didn't make a move for a long time. (sort of reminders)
I'm wondering which technology/library/... I can use to make this work. I read a little bit about GCM, but I'm not sure it's good choice. I don't want my app to send some "pings" to server in every second/minute to check if it has something new happened. I want it to be as light and speed as possible.
Can you give me a hint?
Thanks in advance.
#Tomek,
First, probably you will will need to keep a persistent connection while the person is in the game to you server to have a minimal latency.
Second, you know java if you are writing on Android
Third, asynchronous event-driven server model might be a good choice.
I'd like to recommend you to take a look on netty
http://netty.io/
At the same time, Google has a multi-player API, but it is too vendor lock and the general idea behind is different
https://developers.google.com/games/services/common/concepts/realtimeMultiplayer
Based off this is it safe to say that building a real-time news feed type application is better done using polling than with sockets? I'm planning on building a news feed type app for mobile devices and was planning on doing it with sockets but I'm starting to think that it may be better to build a RESTful app instead and just do short-interval polling on the client to get new updates. How have others out there implemented "real-time" mobile apps?
In Android, GCM is your best bet for any real-time notifications. It couldn't be simpler or faster to get the real time notifs, if you have a server than can push the notifs.
On iOS, your better off writing a polling mechanism. The best example I can think of is the new Facebook app for iOS. It seems to poll every 30s or so to check for new data. If there is new data, and the user clicks the new stories bar, it will get the new data and display it.
A simple request and timer would work, but there is also a technique called Long Polling that works well in these situations. This will limit the drain on the battery.
So in short, because of Apples restrictions on Push-Notifications, you will have to work around it. However, in general, push notifs are the way to go, all things considered.
To start of, i should mention that i'm a newbie in Android (Not that much experience in Java at all tbh), so be easy on me.
I am making an app that continuously pulls data from a server, and then returns data through a http post request. The question is, what is the best way to handle the actual pulling from the server? Should i be using AsyncTask or create another thread and let it run on that? Are there better methods for this purpose?
I will be pulling data every 5 minutes. (I am aware that this will drain the battery very fast, and i should definately be using Androids C2DM framework. But i have no experience in it before and i'm on a deadline, so this'll have to do until i have time to learn how to implement it.)
I'm grateful for any advice!
As an alternative to C2DM, you can do the persistent TCP connection between your device and the server. Then every 5 minutes your server can push a tickle to the device. Upon being tickled, the device can request the information via Http post.
Here is some sample code on how to do that.The connection stays open in a background thread even after the app has exited
Creating and Managing a persistent TCP socket: http://openmobster.googlecode.com/svn/trunk/cloud/android/connection/src/main/java/org/openmobster/core/mobileCloud/android/module/connection/NotificationListener.java
Full Disclosure: I am the Chief Engineer of OpenMobster and I wrote this code. Please feel free to use whatever you like or just get an idea if thats what you need
Thanks
Do you need to pull the data in background (even if your app is not "opened" and the android device is sleeping)? I suppose thats what you want because you mentioned C2DM. If so..the buzzwords are AlarmManager (with repeating time)/BroadCastReceiver and maybe NotificationManager to notify the user. With AlarmManager you schedule your events (every 5 minutes) and with BroadcastReceiver you receive those events and do what you want to do every 5 minutes :)
I need to make for school an app that runs on Android. Actually there are two apps, a client and a server. Ther server runs on a PC while the clients run on Android devices. I want to know what is the best technology for this. I know RMI and WebServices are not implemented in Android so what are the alternatives (besides actually communicating with sockets in the traditional way). One alternative that I did not look into is REST, but I will need to be able to notify a client once another client has done something, similar to turn base games where Player A notifies Player B that he made his move.
Like I said, sockets do the trick, but are little low-level compared to RMI and WebServices and only want to use those as a last resort.
Keep it simple. Use REST and have the clients poll for updates.
Also, if you get to a point down the road where you need to scale, this solution is actually fairly easy to scale because your servers do not need to maintain connections. Since there is no shared state between a particular server and the client (there is shared server between the application and the client), you can easily add more servers to handle the polling and put them behind a load balancer.
You can also add in caching so that the polling just gets the exact same response without causing a re-compute of the response. You would then be able to have the back-end game-state servers update the caches when the game state changes. This would let you poll much more frequently and still have a very flexible, scalable architecture.
For a turn-based game you can take a look at XMPP (e.g. Smack) that is traditionally used for instant messaging. It would also be interesting to create a game using C2DM that is used for push notifications.
You can also look into HTTP streaming which is essentially an unending HTTP response in which player moves are fed into.
Alternatively you can look into binary messaging systems that are more suited for real-time games but still applicable such as RabbitMQ (what's wrong with a smooth turn-based game?).