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 Wed, 05 Sep 2012 20:52:58 GMT
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 <agrieve@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 <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