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?).
Related
I started with a application where you can chat.
Now im in the position to start with the chat.
The problem I'm facing is that I don't want to use
resources from "outside". With outside I mean:
Firebase, Socket.io and so on.
I do simply rent a webspace. And I'm asking you now,
how is it possible to realize an live chat without
using extern services like firebase.
Is it possible with only using an Webspace?
What is required to make an live chat?
And there comes the second question:
How do I realize to stay connected to a server to check if there is a new message without using much battery or network ressources?
I'm not asking without hardly trying by my self.
Two days ago I started with the research of possibility, but I didn't found anything which would work I guess.
Thanks folks...
You need to connect to the Web Server using a Socket and keep that connection open to receive new messages with little delay (see for example http://srchea.com/build-a-real-time-application-using-html5-websockets) This keeps the phone active and uses much battery.
The very purpose of Firebase is to bundle this work for all services which need this type of communication (E-Mail, Push messages of newspapers, Chats) such that the phone only has to query one server. Therefore, I see no way for you to find another solution which uses little battery.
I recently set up a web service using LABVIEW which exhibits a bunch of shared variables which can be changed via buttons in the LABVIEW program itself.
Apart from this I would also like to control the shared variables via my Android phone.
Actually, this works pretty well and I can also see the LABVIEW button's state change when I click the Android buttons within my app.
My question is now: Up to now the LABVIEW buttons' state is only updated but the other way round doesn't hold true. How can I make the Android buttons' state change when using the LABVIEW buttons?
Do I have to employ IntentServices or do I have to use GCM (Google Cloud Messaging) etc.?
I dont know exactly how LABVIEW works but basically you are providing some server-client communication functionality. So there is no magic way of updating your android's application state based on changes happening on the server side. basically you will have to follow polling or pushing approach.
Either your application can ask the server periodically (poll), or your server has to notify the client when the changes occur (push). The first approach is simple but will eventually drain your battery quicker, meanwhile pushing messages from server to client is more elegant but requires greater efforts.
How can I make the Android buttons' state change when using the LABVIEW buttons?
Using poll or push approach.
Do I have to employ IntentServices?
You dont have to. But eventually your notification mechanism will reside on a service. it might happen that IntenService is a good solution but depends on your requirements.
Do I have to use GCM (Google Cloud Messaging)?
You dont have to. There are other solutions as well such as establishing yourself a socket level communication.But GCM might be quicker for your case.
I am looking for options around creating a multi-platform application that will react to a HTTP call made to it. To explain my situation:
I have software running on client machines which is capable of making HTTP requests, specifically passing information via GET;
I can adapt the software to accept a manually inputted IP address and any other information (such as authentication tokens) but not really change the comms method;
The requirement is that this software can pass small amounts of information, on the fly, to an app running on a smartphone;
I'm able to specify networking restrictions, such as being on the same local network etc;
It's not really viable for me to create a server to sit between the app and the client.
My thinking is that I could create a simple app to effectively act as a server, sitting and listening for a HTTP call and acting on the information passed to it.
Phonegap crossed my mind purely for the cross-platform capability; Ultimately, if it needed to be native development, whilst not preferred, it is an option.
Everything I've found on the subject thus far is either specific to a platform, usually with no alternative on competing platforms, or is reliant on the app as a client or an intermediary server handling the connections.
My question is, is such a thing - effectively setting up an iPhone or Android device as a server with a listening port - actually possible in Phonegap, or at all?
I appreciate that there are some (very valid) security concerns with the above approach - additional controls will be put into place to deal with that, right now I'm at the beginning of the search and looking to see which is the most viable way forward.
I would have to say that your approach is a bad idea. You have to keep in mind that the OS can kill your app if it is in the background any time it feels like it. I would look more into using a push service to send the app any updates. That way, even if the app was killed, when the user opens the app it has the latest info. My 2cents.
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
I'm making a mobile app where users should be able to start their own radio broadcast channels from their mobile phone. Other users will then be able to browse broadcasts and connect. It also includes some special perks to make it unique.
I've got the general concept of it thought out.
The thing is, I'm not sure how to implement some kind of "server" for it. I could think of two solutions to my problem currently:
Running a server which manages both the list of broadcasts channels,
and also broadcasts the channel to all users.
Running a server which manages the list. It stores a handle for connecting directly to the broadcasters phone.
Now I'm a total beginner when it comes to how demanding something is. Am I thinking correctly if i say that the first solution would overload the server when there are many users on it?
That would make the second option seem good, although if a channel gets popular enough, wouldn't it require insane amounts of bandwidth for the broadcaster?
Help me out guys, as I said I'm a total beginner when it comes to these kinds of things.
I would just use SHOUTcast or Icecast. It is very easy to start up either of these from another application.
These servers are very simple in their operation. Data comes in (usually encoded in MP3 by the source client [your mobile app]), and the server sends the exact data right out the door to any connected clients. It does implement a small buffer so that receiving clients can be initially flooded with data, to speed up the time before audio is played. You could always implement one of these yourself, but there is no sense in re-inventing the wheel.
You absolutely cannot run a server on the phone itself. Not only won't there be enough bandwidth, but each connection consumes some resources, which are extremely limited on a mobile device. You should host the streams on your own servers, and use the mobile device as a source client.
You're going to have to utilize some off the shelf product here. There's no way you're going to write something yourself that will do what you're hoping (unless your product is a total flop, and no one is using it). People can't broadcast much off their phones (your initial thought), so, you'll *have to be re-broadcasting everything for them, to whoever wants to be listening. It doesn't really matter how popular a specific "station" is, because the point is that you have to be broadcasting to whoever wants to be listening. These sorts of solutions require all sorts of very convoluted server mirroring schemes.
I'm not sure if something like SmartFoxServer can help you or if you want to try to leverage a VOIP server of some kind. I'm sure someone else will pipe in with a more specific and useful suggestion, but I can tell you for certain that this is NOT something you're going to write yourself, if you have no experience with this sort of thing.
And not that you asked, but I'll also note that if the users start broadcasting copyrighted material, then you're liable for pirated distribution of it. So, I'd be VERY careful what you allow people to transmit!