incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: online events
Date Tue, 04 Sep 2012 19:05:08 GMT
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 <fil@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 <agrieve@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 <fil@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.macdonald@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
> >>><agrieve@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>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message