- Initialize a message channel for native -> Javascript in the core App plugin
- Change keyboard detection to send events via plugin message channel, instead
using eval() (i.e. webView.sendJavascript())
Tried as hard as possible for this not to be a breaking change (all
symbols were preserved). Planning to remove delegating symbols in 4.0.x
though.
Also for backwards compatability - a copy of the plugin is bundled. It
will likewise be removed in 4.0.x
This, along with the commit to the audio plugin, makes it so that by
default apps control the ringer volume, but when any audio players are
active, the media volume is controlled.
This allows e.g. jsHybugger to create pages with access to Cordova APIs.
We restrict access to content provider URLs which are at subdomains of the application itself, ie, begin with "content://com.your.package.id."
Keep track of the last AlertDialog showed.
The last dialog showed that is rendered while hitting back button it
causes a leaked window.
Instead of perform a full track of all dialogs created, only destroy the
last one showed, this fixes the problem.
close#122
The preference creation actually needs to be before
super.onCreate(savedInstance) in order to avoid the exception
"requestFeature() must be called before adding content". Also ran into an
issue in the native tests "Whitelist" and "User WebView/Client/Chrome" where
it would throw an exception that the CordovaWebView appView already had
a parent and needed to be removed from that parent before the invocation
to root.addView(appView). So I conditionally remove the wrong parent.
Also made a change to the native tests so the menus test would work.
I also put super.init() back into the template, though invoking it is optional
as loadUrl will call it automatically if needed.
Instantiation and storing of the instance should be owned privately by
PluginManager, not exposed via an unprotected public API. That said,
this refactoring does not make any breaking changes to the public API,
except for removing the createPlugin call in PluginEntry, which should
not be called by anyone other than PluginManager anyway.
Thinking here is that we need a while for both initialize and
pluginInitialize to exist before plugin authors would bother not using
the deprecated one anyways. Really, no harm in keeping both for some
time.
