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.
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'm new to app development and I am soon going to be developing an app for a local charity.
The charity is a dog rescue charity and the app will display information about dogs available for adoption.
The content will obviously need to be updated frequently, even daily, which will obviously not work constantly updating the app via the relevant app stores. What is the most common way to deliver content to an app?
My thoughts on previous experience would be to create a REST API and deliver the content remotely. Would an app allow this? Is there a method more generally used?
Thanks in advance.
You can save all the information to show of each dog available to adoption in a database, then make the app retrieve all the data from it every n time.
I recommend you to use Firebase, it is cross-platform (includes Android and iOS), and I consider it really good when starting using databases.
Here you can find documentation for every supported platform, and easy examples on how to work with it.
Good luck with your project! :)
I see you don't have clear specification on how often to update the app content and technical capability.
Use JobScheduler
Syncing to the backend (via REST API)to fetch the data is a battery drainer & there is no use in syncing data on device which is about to die, I would prefer Jobscheduler which will intelligently act as per various environment criteria met like charging/idle.
There are several facilities available to help your app schedule work. These include:
AlarmManager
JobScheduler
SyncAdapter
Caution: Exponential backoff is enabled on job dispactchers/schedulers
For 24-hour logic check here
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
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 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?).