Calculate propotion of task that's complete in AJAX Progress Indicator

For longer delays, you need to help the user understand how much has been achieved so far, typically using a progress meter that shows percent complete. Sometimes, a long delay can come from a single XMLHttpRequest Call, because although the network transfer may be quick, the back-end processing might not be. For example, the call might trigger a major database operation.

You probably won't get any useful information about its progress by monitoring the responseText component. The responseText tends not to populate in a linear fashion, for two reasons. Firstly, there are usually back-end calculations involved, during which no output can occur. Thus, output tends to happen in bursts, or all at the end. Secondly, the output is often compressed using the standard HTTP content encoding facility, and the compression algorithm will force data to be outputted in bursts. The XMLHttpRequest's readyState also won't tell you very much. For reasons described in Call Tracking, you can only rely on states 0 and 4, and maybe 1.

So if you can't monitor the progress of an XMLHttpRequest Call, how can you help the user understand how much progress has been made? One thing you can do is Guesstimate: predict the total time, and start running a timer to monitor how long since the call began. The prediction of total duration need not be hard-coded every time; you could have the application track download times and reflect them in the estimates next time round. It's possible the actual time will exceed your estimate, and you wouldn't want to show a progress of 120% while the download's still in progress. You also don't want to suddenly drop the progress percentage by increasing the time estimate. So you need to treat the 100% figure as asymptotic - always approaching it, but never getting there. The details are beyond the scope of this pattern, but what you need is a formula which transforms time so far into a value that starts at 0 and approaches 100. An additional constraint is that it must fit with your estimate, so you might perhaps ensure your estimate is reached at the 80% point, allowing room for the progress meter to grow past it if the transfer takes longer. One last thing: no matter what the figure ends up at, be sure to drive it up to 100% at the end, to maintain the illusion that this is a real progress meter.

Another way to deal with long XMLHttpRequest Calls is to explicitly introduce a second monitoring channel. While the primary request takes place, a sequence of monitoring requests are issued to ask the server for a progress estimates. For example, the server might be looping through 1000 records, running a transformation on each of those and saving it to the database. The loop variable can be exposed so that a monitoring service can convert it into a percentage remaining figure.

Not all Progress Indicators concern a single XMLHttpRequest Call. Indeed, those requiring a progress meter are longer processes, likely incorporating several XMLHttpRequest Calls. There, you do have much better scope for real-time progress monitoring - each time a call returns, further progress has occurred. In a simple model, you can show progress is 50% complete when 2 of 4 calls have returned.

Visit this link for more information

Tags: ajax, progress indicator, ajax applications, xmlhttprequest, http request

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com