+1
ya.
On Tue, Sep 4, 2012 at 10:53 AM, Filip Maj <f...@adobe.com> wrote:
> Sorry replied to the wrong thread.
>
> Can we make sure to keep the old navigator.network.connection API and
> introduce the new one?
>
> ALSO: add a deprecation message to any functions tacked on to the
> `connection` object?
>
> On 9/4/12 8:51 AM, "Brian LeRoux" <b...@brian.io> wrote:
>
>>Right...can't believe we didn't try duck punching all of navigator before.
>>I remember everyone collectively trying to hack this. Anyhow: awesome. Thx
>>Andrew!
>>
>>On Tuesday, September 4, 2012, Andrew Grieve wrote:
>>
>>> __proto__ just sets the prototype of an object. It's non-standard and IE
>>> doesn't support it, but the following is equivalent:
>>>
>>> function ClassWithNavigatorAsPrototype() {}
>>> ClassWithNavigatorAsPrototype.prototype = navigator;
>>> var newNavigator = new ClassWithNavigatorAsPrototype();
>>>
>>> The idea is that we're not trying to overwrite onLine or connection.
>>>We're
>>> overwriting window.navigator with an object that has the old navigator
>>>in
>>> it's prototype chain.
>>>
>>> I'll make a bug to put this into bootstrap.js post 2.1.
>>>
>>>
>>> On Mon, Sep 3, 2012 at 4:29 PM, Brian LeRoux <b...@brian.io> wrote:
>>>
>>> > waaaaaat! how is this working?
>>> >
>>> > does the __proto__ allow to hack around writable data descriptor?
>>> >
>>> > (awesome stuff andrew)
>>> >
>>> >
>>> > On Sat, Sep 1, 2012 at 8:26 AM, Andrew Grieve <agri...@chromium.org>
>>> > wrote:
>>> > > Figured out a work-around for clobbering things on navigator on
>>>Android
>>> > > (tested on 2.1 and 2.3):
>>> > >
>>> > > var newNavigator = {};
>>> > > newNavigator.__proto__ = navigator;
>>> > > newNavigator.__defineGetter__('onLine', function() {
>>> > > return network.type != 'none';
>>> > > });
>>> > > newNavigator.connection = {type: 'wifi'};
>>> > > window.navigator = newNavigator;
>>> > >
>>> > > I'll hook this up so that connection and onLine will work properly
>>> > (woohoo!)
>>> > >
>>> > > As for events, I don't think document.body is common, but I think
>>> > > window.addEventListener is quite common since it works on both
>>>mobile
>>> > > safari and android browser. I'll add this to the API review list on
>>>the
>>> > > wiki, but I do need to do something here in the short term since I
>>>need
>>> > to
>>> > > listen to the browser-fired window online/offline events to
>>>implement
>>> the
>>> > > ONLINE_EVENTS exec bridge. How about just put in an android
>>> > > only work-around for now:
>>> > >
>>> > > cordova.addWindowEventHandler('online');
>>> > > cordova.addWindowEventHandler('offline');
>>> > > function proxyEvent(e) { cordova.fireWindowEvent(e.type); }
>>> > > document.addEventListener('online', proxyEvent, false);
>>> > > document.addEventListener('offline', proxyEvent, false);
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > On Fri, Aug 31, 2012 at 4:27 PM, Filip Maj <f...@adobe.com> wrote:
>>> > >
>>> > >> My vote is to keep what we currently document
>>> > (document.addEventListener)
>>> > >> - for now.
>>> > >>
>>> > >> We should be compiling an "API Review List" on the wiki or
>>>something
>>> and
>>> > >> taking notes of all these spec changes, and recommended
>>>implementation
>>> > >> routes for the project.
>>> > >>
>>> > >> On 8/31/12 1:21 PM, "Simon MacDonald" <simon.macdon...@gmail.com>
>>> > wrote:
>>> > >>
>>> > >> >Yeah, specs change. Here is the one we originally implemented:
>>> > >> >
>>> > >> >http://www.w3.org/TR/netinfo-api/
>>> > >> >
>>> > >> >sharp eyes will note they are using navigator.connection.type and
>>>we
>>> > are
>>> > >> >using navigator.network.connection.type. That's because the
>>>Android
>>> web
>>> > >> >view would not allow us to over-ride navigator.connection. It
>>>seems
>>> to
>>> > be
>>> > >> >a
>>> > >> >read only object.
>>> > >> >
>>> > >> >Simon Mac Donald
>>> > >> >http://hi.im/simonmacdonald
>>> > >> >
>>> > >> >
>>> > >> >On Fri, Aug 31, 2012 at 3:49 PM, Andrew Grieve
>>><agri...@google.com>
>>> > >> wrote:
>>> > >> >
>>> > >> >> It looks like there is code in network.js that fire online &
>>> offline
>>> > >> >>events
>>> > >> >> when the network status changes. On any platform that already
>>> > supports
>>> > >> >> online events, the browser will fire an event, and then the
>>>network
>>> > >> >>plugin
>>> > >> >> will also fire an event.
>>> > >> >>
>>> > >> >> There is also the fact that the event is fired only on document.
>>> The
>>> > >> >>spec
>>> > >> >> says that listening on window should work as well (as well as
>>> > >> >> document.body):
>>>http://www.whatwg.org/specs/web-apps/current-work/
>>> > >> >>
>>> > >> >> I made a test page:
>>> > >> >> <https://dl.dropbox.com/u/6648754/webtests/online_events.html>
>
