For Android, I also don't see how we could separate out the network plugin
without breaking navigator.onLine. However, I think it still may be worth
doing.
1. By default, set navigator.onLine to undefined
2. If they install the network plugin, then have it override the property
so that it works.
The issue is with the javascript code related to the network-information
plugin and affects ios + android (probably others) from my initial testing.
If it is doable, we should definitely rip it out.
We could always package up the network-information plugin without any JS
code and leave the network
Wait, aren't all the plugins already broken out on Android now? I
don't remember this code being dependent on the plugin itself, just
the online/offline event.
On Thu, Jun 6, 2013 at 3:30 PM, Brian LeRoux wrote:
> sgtm
>
> On Thu, Jun 6, 2013 at 5:19 PM, Joe Bowser wrote:
>> The thing is that th
agree to this, but also agree w/ joe that we should try and remove
completely (if testing the browser handles correctly 2.3+)
On Thu, Jun 6, 2013 at 5:25 PM, Steven Gill wrote:
> We should leave network code in core. Maybe this is something we revisit
> later on if we want to make network informa
sgtm
On Thu, Jun 6, 2013 at 5:19 PM, Joe Bowser wrote:
> The thing is that this may be for the browser, and not for our plugin.
> The event is being hijacked and used to trigger the JS to check the
> queue to see whether or not it should be firing a JS event off in the
> browser when we do a send
We should leave network code in core. Maybe this is something we revisit
later on if we want to make network information its own plugin and are
willing to do the changes required to do so (No idea what that would
involve).
If we aren't ripping it out of Android, we shouldn't rip it out for the
oth
Oh yeah, Test 2.3, 4.0 and 4.1.
On Thu, Jun 6, 2013 at 3:19 PM, Joe Bowser wrote:
> The thing is that this may be for the browser, and not for our plugin.
> The event is being hijacked and used to trigger the JS to check the
> queue to see whether or not it should be firing a JS event off in the
The thing is that this may be for the browser, and not for our plugin.
The event is being hijacked and used to trigger the JS to check the
queue to see whether or not it should be firing a JS event off in the
browser when we do a sendJavascript("foo()"); call in Java. If this
is the case, then we
Seems simple enough. I find online/offline/pause/resume and other
events of the app lifecycle to be plausibly core for all platforms.
On Thu, Jun 6, 2013 at 4:44 PM, Joe Bowser wrote:
> Actually, online/offline has to be core, because it's part of the
> bridge. We can't rip that out because some
>
> How is this not a problem for the rest of the platforms? That's the
> first thing that I'm wondering right now.
I think ios' deviceready event also doesn't fire, but I'm not sure if it's
for the same reasons - haven't gone down that rabbit hole yet.
As for bb10, I'm not sure anymore since it
Actually, online/offline has to be core, because it's part of the
bridge. We can't rip that out because some platform may need the
Online/Offline event bridge. That's a pretty serious gotcha. It's
also why it's a problem on Android and not on other platforms.
Sorry, I don't have any easy answer
How is this not a problem for the rest of the platforms? That's the
first thing that I'm wondering right now.
On Thu, Jun 6, 2013 at 2:37 PM, Tim Kim wrote:
> Hey gang,
>
> So I'm trying to rip out the android network plugin, but it appears the
> android exec relies on the network plugin for onl
Hey gang,
So I'm trying to rip out the android network plugin, but it appears the
android exec relies on the network plugin for online/offline events.
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=blob;f=lib/android/exec.js;h=206c09acb6d939b91e28b8813fa7fe318c2a4483;hb=0a5fa1fa255e12
13 matches
Mail list logo
