Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of simon.macdonald@gmail.com
 designates 209.85.160.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABiQX1Vw7WGDgDLtOzNNQJO2Es-96QZ1R8d8xJB4bzGbNWE9SQ@mail.gmail.com>
References: 
 <CAM1AYQBStcYM97Mss-j152qGjxN=A1bua5x4G-UaCL5FP3FR4w@mail.gmail.com>
 <CC666BCF.C88A%fil@adobe.com>
 <CABiQX1Vw7WGDgDLtOzNNQJO2Es-96QZ1R8d8xJB4bzGbNWE9SQ@mail.gmail.com>
From: Simon MacDonald <simon.macdonald@gmail.com>
Date: Mon, 3 Sep 2012 13:03:40 -0400
Message-ID: 
 <CAM1AYQAaPTAgubB0WtN=tZd7Ex9g5spnM64m=LWQqOD_67PQRA@mail.gmail.com>
Subject: Re: online events
To: callback-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

This looks like a good thing to add in 2.2. We should get all the
other platforms to add the navigator.connection.network interface to
navigator.network as well to remain consistent.

Simon Mac Donald
http://hi.im/simonmacdonald


On Sat, Sep 1, 2012 at 11: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
>> >> 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?
>> >>
>>
>>