Batching requests to minimize cell drain

I made some progress on adding the option to $.ajax, started to edit the question, and realized it's better as an answer:

(function($) {    var batches = [];    var oldAjax = $.fn.ajax;    var lastAjax = 0;    var interval = 5*60*1000; // Should be between 2-5 minutes    var runBatches = function() {        var now = new Date().getTime();        var batched;        if (lastAjax + interval < now) {            while (batched = batches.pop()) {                oldAjax.apply(null, batched);            }        }    }    setInterval(runBatches, interval);    $.fn.ajax = function(url, options) {        if (options.batchable) {            batches.push(arguments);            return;        }        runBatches();        oldAjax.apply(null, arguments);        lastAjax = now;    };})(jQuery);

That was actually fairly straightforward. Is love to see a better answer though.

• Does setInterval also keep the phone awake all the time? Is that a bad thing to do? Is there a better way to not do that?

From an iPhone 4, iOS 6.1.0 Safari environment:

A wrote an app with a countdown timer that updated an element's text on one-second intervals. The DOM tree had about medium complexity. The app was a relatively-simple calculator that didn't do any AJAX. However, I always had a sneaking suspicion that those once-per-second reflows were killing me. My battery sure seemed to deplete rather quickly, whenever I left it turned-on on a table, with Safari on the app's webpage.

And there were only two timeouts in that app. Now, I don't have any quantifiable proof that the timeouts were draining my battery, but losing about 10% every 45 minutes from this dopey calculator was a little unnerving. (Who knows though, maybe it was the backlight.)

On that note: You may want to build a test app that does AJAX on intervals, other things on intervals, etc, and compare how each function drains your battery under similar conditions. Getting a controlled environment might be tricky, but if there is a big enough difference in drain, then even "imperfect" testing conditions will yield noticeable-enough results for you to draw a conclusion.

However, I found out an interesting thing about how iOS 6.1.0 Safari handles timeouts:

• The timeouts don't run their callbacks if you turn off the screen.
• Consequentially, long-term timeouts will "miss their mark."

If my app's timer was to display the correct time (even after I closed and reopened the screen), then I couldn't go the easy route and do secondsLeft -= 1. If I turned off the screen, then the secondsLeft (relative to my starting time) would have been "behind," and thus incorrect. (The setTimeout callback did not run while the screen was turned off.)

The solution was that I had to recalculate timeLeft = fortyMinutes - (new Date().getTime() - startTime) on each interval.

Also, the timer in my app was supposed to change from green, to lime, to yellow, to red, as it got closer to expiry. Since, at this point, I was worried about the efficiency of my interval-code, I suspected that it would be better to "schedule" my color changes for their appropriate time (lime: 20 minutes after starting time, yellow: 30 mins, red: 35) (this seemed preferable to a quadruple-inequality-check on every interval, which would be futile 99% of the time).

However, if I scheduled such a color change, and my phone's screen was turned off at the target time, then that color change would never happen.

The solution was to check, on each interval, if the time elapsed since the last 1-second timer update had been ">= 2 seconds". (This way, the app could know if my phone had had its screen turned off; it was able to realize when it had "fallen behind.") At that point, if necessary, I would "forcibly" apply a color change and schedule the next one.

(Needless to say, I later removed the color-changer...)

So, I believe this confirms my claim that

iOS 6.1.0 Safari does not execute setTimeout callback functions if the screen is turned off.

So keep this in mind when "scheduling" your AJAX calls, because you will probably be affected by this behavior as well.

And, using my proposition, I can answer your question:

• At least for iOS, we know that setTimeout sleeps while the screen is off.
• Thus setTimeout won't give your phone "nightmares" ("keep it awake").

• Is this kind of approach even worthwhile? There are so many things going on at once in a modern smartphone, that if my app isn't using the cell, surely some other app is. Javascript can't detect if the cell is on or not, so why bother? Is it worth bothering?

If you can get this implementation to work correctly then it seems like it would be worthwhile.

You will incur latency for every AJAX request you make, which will slow down your app to some degree. (Latency is the bane of page loading time, after all.) So you will definitely achieve some gain by "bundling" requests. Extending $.ajax such that you can "batch" requests will definitely have some merit.

The article you've linked clearly focuses on optimizing power consumption for apps (yes, the weather widget example is horrifying). Actively using a browser is, by definition, a foreground task; plus something like ApplicationCache is already available to reduce the need for network requests. You can then programmatically update the cache as required and avoid DIY.

Sceptical side note: if you are using jQuery as part of your HTML5 app (perhaps wrapped in Sencha or similar), perhaps the mobile app framework has more to do with request optimization than the code itself. I have no proof whatsoever, but goddammit this sounds about right :)

• How can I make this a true modification of just the ajax method, by adding a {batchable:true} option to the method? I haven't quite figured that out either.

A perfectly valid approach but to me this sounds like duck punching gone wrong. I wouldn't. Even if you correctly default batchable to false, personally I would rather use a facade (perhaps even in its own namespace?)

var gQuery = {}; //gQuery = green jQuery, patent pending :)gQuery.ajax = function(options,callback){  //your own .ajax with blackjack and hooking timeouts, ultimately just calling  $.ajax(options);}

• Does setInterval also keep the phone awake all the time? Is that a bad thing to do? Is there a better way to not do that?

Native implementations of setInterval and setTimeout are very similar afaik; think of the latter not firing while the website is in the background for online banking inactivity prompts; when a page is not in the foreground its execution is basically halted. If an API is available for such "deferrals" (the article mentions of some relevant iOS7 capabilities) then it's likely a preferable approach, otherwise I see no reason to avoid setInterval.

• Are there other things here that would cause a battery to drain faster?

I'd speculate that any heavy load would (from calculating pi to pretty 3d transitions perhaps). But this sounds like premature optimization to me and reminds me of an e-reader with battery-saving mode that turned the LCD screen completely off :)

• Is this kind of approach even worthwhile? There are so many things going on at once in a modern smartphone, that if my app isn't using the cell, surely some other app is. Javascript can't detect if the cell is on or not, so why bother? Is it worth bothering?

The article pointed out a weather app being unreasonably greedy, and that would concern me. It seems to be a development oversight though more than anything else, as in fetching data more often than it's really needed. In an ideal world, this should be nicely handled on OS level, otherwise you'd end up with an array of competing workarounds. IMO: don't bother until highscalability posts another article telling you to :)