Changes made and tested on Android + iOS. Will wait for 2.1.0 before merging.
https://github.com/agrieve/incubator-cordova-js/commits/navigatorconn On Tue, Sep 4, 2012 at 3:05 PM, Andrew Grieve <agri...@chromium.org> wrote: > Definitely. Will add this detail to the bug so it's explicit. > > > On Tue, Sep 4, 2012 at 2:03 PM, Brian LeRoux <b...@brian.io> wrote: > >> +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 >> > >> > >> > >
