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 Sat, 01 Sep 2012 15:26:17 GMT
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
> >> Running it on android browser shows that the only two listener methods
> >>that
> >> work are:
> >>  -window.addEventListener
> >>  -document.body.ononline =
> >>
> >> So, clearly it's a bit broken. I'm wondering though, if we should do
> >>some
> >> clean-up with these events.
> >>
> >> Options:
> >>
> >> 1. Live with duplicate events for browsers that support them, but also
> >>fire
> >> them on document.body and window.
> >> 2. Don't fire online/offline events from this plugin. Fire a custom
> >> "networktypechange" event
> >> 3. Intercept all event registration an window/document/body so that the
> >> browser's native events don't take effect. Have the only source of these
> >> events be the network plugin.
> >>
> >>
> >> Votes? Comments?
> >>
>
>

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