I think the call is used too frequently to have a short deprecation period. Might be one of those leave it @Deprecated forever kind of things.
On Mon, May 26, 2014 at 1:36 PM, Marc Weiner <mhweiner...@gmail.com> wrote: > +1 for deprecation sooner and removal in 4.0. Might as well break > everything at once. Doesn't sound like it's in the spirit of Cordova. > > > On Mon, May 26, 2014 at 1:16 PM, Michal Mocny <mmo...@chromium.org> wrote: > > > Should we write a plugin that must be installed along with > cordova-android > > that does the suggested "sendJavascript via PluginResults" and swap the > > implementation on native-side? > > > > -Michal > > > > > > On Mon, May 26, 2014 at 1:02 PM, Ian Clelland <iclell...@chromium.org > > >wrote: > > > > > It's probably a good candidate for removal in the 4.0 branch, if we > > really > > > don't want to support it > > > > > > > > > On Mon, May 26, 2014 at 12:59 PM, Andrew Grieve <agri...@chromium.org> > > > wrote: > > > > > > > From: https://issues.apache.org/jira/browse/CB-6746 > > > > > > > > It's a fairly common anti-pattern to use sendJavascript() to > > communicate > > > > with native side. Not sure if deprecating the call is the right move, > > but > > > > wanted to pitch the idea. > > > > > > > > There are multiple pitfalls: > > > > 1. As in the bug, it doesn't work if cordova.js isn't loaded yet > > > > 2. It's ripe for escaping bugs > > > > 3. It's less performant than using PluginResults > > > > > > > > Given that you can implement sendJavascript via PluginResults by just > > > > eval()ing the results, maybe we could just deprecate the function? > > > > > > > > > >
