If that's the intention of the code, then I think we could probably change
it since...
When you navigate via HTML (e.g. click a link or set window.location), we
don't reset the plugin manager, instead, this triggers the onReset() method
on all plugins.
pluginManager.init() is called *only* when you navigate via Java.
On Mon, Feb 24, 2014 at 7:19 PM, Joe Bowser <bows...@gmail.com> wrote:
> Right, this calls pause and destroy on all the existing plugins, and
> clears the objects until they're called again.
>
> So, for example. Let's say you had the Camera plugin, which is
> probably our nastiest plugin w.r.t memory usage, and you took a
> picture. Then you wish to go back to what is basically a HTML app
> that doesn't have any need for any plugins. It doesn't make sense for
> that Camera plugin to keep holding onto the memory if you're
> navigating to another URI where that plugin isn't needed. So, we
> destroy the plugins that were instantiated and wait for that document
> to make a call to another plugin.
>
> I think this behaviour does make sense, although I'm worried that we
> may be missing a delete/destroy somewhere.
>
> On Mon, Feb 24, 2014 at 4:04 PM, Naik, Archana <na...@lab126.com> wrote:
> > Oh I see.
> >
> > Here, by recreating I meant calling pluginManager->init() method.
> > loadUrl(string url) in CordovaWebView calls loadUrlIntoView(final String
> > url, boolean recreatePlugins)
> > With second argument as true. Which does this
> >
> > if (recreatePlugins) {
> > this.url = url;
> > this.pluginManager.init();
> > }
> >
> >
> > I am wondering why calling init() here every time we load a new url.
> >
> > Thanks
> > Archana
> >
> >
> > On 2/24/14 3:57 PM, "Joe Bowser" <bows...@gmail.com> wrote:
> >
> >>On Mon, Feb 24, 2014 at 3:45 PM, Naik, Archana <na...@lab126.com> wrote:
> >>> History stack reset? I thought loading url will add to the navigation
> >>> history.
> >>>
> >>
> >>Which history are we referring to? We have some old legacy methods
> >>from the bad old days when we maintained our own history, because we
> >>thought the browser history was broken (Android 3.x, 4.0.x).
> >>
> >>> Yes, overload helps to by pass this recreation but default call is with
> >>> this flag set to true so internally when you use loadUrl() it will
> >>> recreate plugins.
> >>
> >>We should only create plugins when we invoke them unless we're setting
> >>plugins to be instantiated onload. There also could be some security
> >>reasons to destroy and recreate the plugins, although none are coming
> >>to mind now.
> >>
> >>
> >>
> >>>
> >>> Archana
> >>>
> >>> On 2/24/14 11:13 AM, "Andrew Grieve" <agri...@chromium.org> wrote:
> >>>
> >>>>I think the history stack is reset when you use that API, so it
> somewhat
> >>>>does make sense to recreate the plugins. Not sure if there is a better
> >>>>answer than that...
> >>>>
> >>>>I added the overload to allow not resetting the plugins, because I
> think
> >>>>that is a useful thing to want to do as well.
> >>>>
> >>>>
> >>>>On Fri, Feb 21, 2014 at 5:24 PM, Naik, Archana <na...@lab126.com>
> wrote:
> >>>>
> >>>>> Hi, Devs,
> >>>>>
> >>>>> Why do we recreate plugin every time an url is loaded? I am referring
> >>>>>to
> >>>>> loadUrlIntoView(url,bool) method.
> >>>>> Other override which take only string(url), has this recreatePlugins
> >>>>> boolean as true.
> >>>>>
> >>>>> Thanks
> >>>>> Archana
> >>>>>
> >>>
> >
>
