Tag Info

Hot answers tagged

11

You were correct the first time, polling is the correct term to use in this situation. Whether you are polling at 1 mHz or at 1 MHz, it is still polling. Note milli Hertz is not a unit I've ever see used, a poll rate of once every million seconds (11.6 days) having limited use. *8') From the wikipedia polling page: Polling, or polled operation, in ...


8

Immediately show some feedback: change the visual state of button, display an animated throbber. If the app logic allows, disable the button once it has been pressed, enable it back when the answer arrives. Once the answer has arrived, show the real feedback: update the controls, remove the throbber.


8

Polling is always acceptable when real-time isn't a necessity. What you have to ask yourself is why would you use one instead of the other? The purpose of a push service is a couple things; it can be considerably less traffic for you to deal with if your pushes are broadcasts and a 3rd party provider does the broadcast - this allows you to send one message ...


4

If the server can give a rough estimate of how long a job will take, then I would return that estimate in the first response (the one indicating that the job was received/accepted). The client can then wait at least that time before it starts polling for results. To avoid flooding a server with unsuccessful polling requests, you might also use a scheme that ...


2

This really depends on how much time it takes on average to perform the job and the standard deviation of this time. Once you know this, you have a good idea about what your minimum and maximum waiting times are for 95% of jobs (2 standard deviations). So I would plan for a minimum polling time somewhere in the vicinity of 2 standard deviation (so that ...


1

Polling should be fine in your case. And you won't have to integrate with yet another system (or multiple systems for multiple platforms). Device specifics may be an issue, though. Can you reliably poll when the app isn't front and center on the device? (may or may not be an issue for you). Your ability to do so may depend on the techonolgy you are ...


1

Of course. It's also easier (just beware of pull spikes if everyone is pulling on the same schedule). That said, I would challenge the assumption that 'a large delay is acceptable', considering mobile users expectations. ('Maps are not updated in real time! Unacceptable!' - or - 'I know it's the weather service, but I'm going to keep pushing that refresh ...


1

One way of handling this is to use PubNub. It is a paid service, but well worth it since it basically handles the entire messaging portion of what you describe, and wouldn't have any scale issues. Its very easy to implement. The clients would connect to the service using long polling (if you roll your own) or one of their client libraries. Messages are ...


1

You might want to check out Comet or BOSH Which are two methods to simulate sockets over HTTP, they are way more efficient than polling, and technically could scale to the 10k if you use a light weight server such as Nginx which is alot better at handling concurent connections than apache. As for the server with more than 100 connections you could get a ...



Only top voted, non community-wiki answers of a minimum length are eligible