W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2012

Re: Network Information API

From: Niklas Widell <niklas.widell@ericsson.com>
Date: Fri, 7 Dec 2012 11:11:46 +0100
To: "SULLIVAN, BRYAN L" <bs3131@att.com>, Yoav Weiss <yoav@yoav.ws>, Brian Leroux <brianl@adobe.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <CCE77BF8.12B44%niklas.widell@ericsson.com>
There are measurable gains to be made given radio status info, but wouldn't this preferably be done in the browser rather than application? After all, it is the aggregation of all traffic from all web applications that must be well behaved for this scheme to work, and the browser is the aggregation point.

Note, I'm not arguing that radio adaption is a bad thing, just that it is a complex implementation detail that requires wide adoption by all web pages to be useful.


On 2012-12-06 19:47, "SULLIVAN, BRYAN L" <bs3131@att.com<mailto:bs3131@att.com>> wrote:

Another, unrelated property that can be of great help to Web developers is the `radioState` property. What I mean by that is exposing the state of the radio (full power, low power or standby as defined http://developer.android.com/training/efficient-downloads/efficient-network-access.html) to Web developers, giving them the opportunity to pull extra data from the servers only if the radio is already in full-power, thus saving battery life.

Exposing the radio state would be very valuable, certainly provide much more actionable information than navigator.online or connection.bandwidth. Basing network request decisions based upon radio state could go a long way toward improving resource efficiency, at least for requests that can be delayed until an optimal time. We’ve proven this by achieving major reductions in device power usage for some of our lead app developers, through their use of our free ARO (at&t Application Resource Optimizer<http://developer.att.com/developer/legalAgreementPage.jsp?passedItemId=9700312>) tool.

Bryan Sullivan
Received on Friday, 7 December 2012 10:12:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:47 UTC