Re: Network Information API

Hi Marcos,

On 20 January 2014 20:47, Marcos Caceres <w3c@marcosc.com> wrote:

>
>
> 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.
>

Here is the first draft of the article:

https://developer.mozilla.org/en-US/Apps/Developing/gather_and_modify_data/Optimizing_for_high_and_low_network_speeds

(in need of a technical review)


>
> >
> > 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


Here is the github repository: https://github.com/franciov/net-pics


>
> >
> > 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.
>

In my opinion the 'bandwidth' property is not useful in this use case: I
had to use it only because the spec implemented by Firefox does not provide
a 'type' property.


>
> 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; }
>


In the isCarrieNetwork function it should be:

if (this.netInfo.connection === 'cellular') { return true; }


Fixed ;)

I think that the values 'wifi' and 'cellular' are enough for this use case.
The value 'disabled' is also a good idea in general.


> > 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.
>

The new proposed API works very well to meet the use case of synchronizing
media data, because in my opinion what drives the user choice is the data
plan she/he subscribed to (i.e. how many MBs/GBs per day/week/month are
included in the plan), not the real speed of the network, so the 'type'
property is enough for this use case.

Further properties, such as 'speed', can be easily added to the netInfo
interface, as soon as a valid use case is found: 'speed' values might be
'high' and 'low' for example. I would leave to the browser (not to the app)
to find the best way to calculate those values.


>
> Kind regards,
> Marcos
>
>
>
Francesco <https://developer.mozilla.org/en-US/profiles/franciov>


On 20 January 2014 20:47, Marcos Caceres <w3c@marcosc.com> wrote:

>
>
> 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
>
>
>