cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: [cordova-js] Order of internal cordova events and docs
Date Tue, 25 Jun 2013 23:25:11 GMT
The order isn't meant to be serially defined. Many platforms fire
onNativeReady as the first channel fired. Some do have dependencies though,
and you can see them in code by looking for where channel.join() is called.

Your options:
If you want your code to run as soon as possible, you should put it in your
bootstrap.js file.

platform.js is another target, but that won't fire until after

onPluginsReady() is meant to be fired once all the plugin file modules are
available, but before any plugin modules are require()d. Looks like there's
a bug right now in that plugins with <runs/> tags are being run before
onPluginsReady() is fired. This will cause their require()s to possible
fail and we should fix that.

platform.initialize() also waits for onNativeReady. I somewhat doubt that
it needs to, but it does.

On Tue, Jun 25, 2013 at 7:12 PM, Benn Mapes <> wrote:

> Not sure if this is doc'ed anywhere, I looked on the wiki but I didn't see
> anything.
> Currently the order of events for page-load/cordova start-up is this (on
> windows phone):
> 1.) onDOMContentLoaded
> 2.) onPluginsReady
> 3.) onNativeReady
> 4.) onCordovaReady
> 5.) onCordovaInfoReady
> 6.) deviceready
> After digging though some old mailing lists I found this mention about the
> topic [1].
> For plugins on windows phone we need to patch the browser and inject some
> scripts so that the xhr will run, this is hard to do if onPluginsReady gets
> fired before onNativeReady because we have no way to ensure that the xhr is
> patched before the plugins get loaded.
> What do people think about documenting the order of these events firing so
> that it will be consistent across all platforms, as well as waiting for
> onNativeReady to fire before loading the plugins?
> [1]:

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