Re: Network Information API

On Friday, January 17, 2014 at 1:57 PM, Francesco Iovine wrote:

> Hi Marcos,
> 
> On 17 January 2014 10:44, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
> > 
> > 
> > 
> > On Thursday, January 16, 2014 at 11:06 PM, Francesco Iovine wrote:
> > 
> > > > Unfortunately we ship this under the name navigator.mozConnection everywhere, but on desktop we just have a default implementation returning infinity for bandwidth and false for metered unconditionally.
> > > 
> > > 
> > > Yes, navigator.mozConnection works quite well in Firefox for Android and Firefox OS.
> > 
> > Can you clarify by what you mean by "works quite well"? Do you know of any example applications that are making use of this API in FxOS or Android?
> 
> Yes! I have written a demo application for the Network Information API: is a photo-sharing Web Application that enables users to take pictures and sync them with online services. It covers the use case of synchronizing media data (photos in this case) in order to give the user control to whether large uploads should happen over cellular. This demo will be part of a MDN page explaining how to optimize a Open Web App for high and low network speeds.
Excellent! this is a very value input. 
 
> 
> Live demo: http://goo.gl/0wP7Gm
> Source: soon on github, anyway the most interesting part of the demo is inside the NetworkManager
> 
> http://www.francesco.iovine.name/mdn/net-pics/public_html/scripts/utils/NetworkManager.js 
> 
> When I say that the Network Information API "works quite well" on Firefox for Android or FxOS I mean:
> navigator.mozConnection exists
> navigator.mozConnection.bandwidth returns different values for wifi and cellular networks, so I can retrieve the type

The question is, how reliable can this bandwidth value be? What if another browser calculates things differently? 

like, you have the "isCarrierNetwork" function: 

if (this.connection.bandwidth === Infinity || this.connection.bandwidth >= 20) {
      return true;
 }
 

That seems inherently unreliable. It also leaves speculation up to the developer about what the bandwidth means. 

The following is also telling:

                if (this.connectionTypes[this.connection.type] === '2g'
                        || this.connectionTypes[this.connection.type] === '3g'
                        || this.connectionTypes[this.connection.type] === '4g') {
                    return true;
                }
            }


When all you really wanted was "isCarrierNetwork"? There doesn't appear to be any value, at least in this application, in knowing if the connection is 2g, 3g, or 4g. 

It also shows how much cleaner this is with the new proposed API:

if (this.netInfo.connection === 'wifi') { return true; }
 
> navigator.mozConnection.onchange works, even if it is not fired immediately
> I tested the demo on Firefox Beta for Android 4 and on my ZTE Open FxOS 1.1
> 
> 
> The demo supports the current W3C Specification (navigator.connection.bandwidth), the previous specification (navigator.connection.type) and the hypothetical upcoming specification (navigator.netInfo), so it works in Firefox, Android browser and BB10 browser. It also combines the Network Information APIs with the Battery Status APIs in order to sync only when the battery is charging or fully charged, for instance. A feedback on the demo would be much appreciated.

I think this demo is really great at showing how multiple APIs can be used together to compose a synchronization  solution. It underscores the point I've been trying to make about making smart use of the primitives (e.g., battery status) that we've managed to expose on the platform.  

It also shows the fundamental issues with "bandwidth" guessing and types that are overly specific ("2g", "3g", etc.). 

The question is, could the new proposed API also work well to meet the use cases that the demo attempts to demonstrate? It appears it can - but I'm biased. It would be great if you could confirm that. 
 
Kind regards,
Marcos

Received on Monday, 20 January 2014 19:47:15 UTC