It's so that you can have multiple CordovaWebViews that use different
configs within one application. It's also so that you don't have to have a
config.xml if you prefer to build up your config in code instead.

I don't think loadConfig() is deprecated. It has
a @SuppressWarnings("deprecation"), which just silences a warning about it
setting the config of the Config class (which is done for backwards
compatibility).


On Mon, Mar 9, 2015 at 3:54 PM, Joe Bowser <bows...@gmail.com> wrote:

> OK, this actually makes using the WebView as a component a lot harder,
> since you now have to have this loadConfig method which you also marked for
> deprecation required to get all of the necessary attributes out of this.
> I'm pretty sure this is a major step backwards in that people looking to
> use Cordova as a component now have to jump through additional hoops to get
> this to work.  What is the benefit of deprecating the Config static class
> and replacing it with the ConfigXmlParser again? I don't remember why this
> was done.
>
> On Mon, Mar 9, 2015 at 9:04 AM Andrew Grieve <agri...@chromium.org> wrote:
>
> > On Mon, Mar 9, 2015 at 11:56 AM, Joe Bowser <bows...@gmail.com> wrote:
> >
> > > On Mon, Mar 9, 2015 at 7:39 AM Andrew Grieve <agri...@chromium.org>
> > wrote:
> > >
> > > > You can now instantiate a CordovaWebView without a config.xml, and
> > > without
> > > > using Config. This happened when I added an "init()" method to
> > > > CordovaWebView. You can pass in a CordovaPreferences object, and a
> list
> > > of
> > > > PluginEntry. Maybe we just need a better comment on Config saying to
> > use
> > > > these instead?
> > > >
> > > >
> > > Where does one get this PluginEntry list when they're embedding a
> > WebView?
> > > This needs to be documented or at least put in the test that tests this
> > use
> > > case.
> > >
> > > >
> > >
> > > > > That has nothing to do with InAppBrowser, this is to do with
> > embedding
> > > a
> > > > > WebView inside an Android application. I don't think you understand
> > > what
> > > > I
> > > > > mean when I say the embedded use case.
> > > > >
> > > > Maybe try explaining a bit more?
> > >
> > >
> > > Even though you edited the test that explicitly covers this use, case,
> > and
> > > even though we've talked about using CordovaWebView as an Android View
> > for
> > > over a year, you need it explained more?
> > >
> > > So, not everyone wants to use all of Cordova, for many reasons.
> Instead,
> > > they really just want to take advantage of the WebView component in
> their
> > > native apps so that they can create hybrid apps that are mostly native
> > with
> > > only some parts that use Cordova.  This is where you would declare your
> > > view in your layout XML like this:
> > >
> > > <org.apache.cordova.engine.SystemWebView
> > >             android:id="@+id/WebViewComponent"
> > >             android:layout_width="match_parent"
> > >             android:layout_height="match_parent">
> > > </org.apache.cordova.engine.SystemWebView>
> > >
> > > And then, in the activity start up your view like this:
> > >
> > >   private CordovaWebView webInterface;
> > >   private CordovaInterfaceImpl systemInterface = new
> > > CordovaInterfaceImpl(this);
> > >
> > > //Set up the webview
> > >         SystemWebView webView = (SystemWebView)
> > > findViewById(R.id.WebViewComponent);
> > >         webInterface = new CordovaWebViewImpl(this, new
> > > SystemWebViewEngine(webView));
> > >
> > >         Config.init();
> > >         webInterface.init(systemInterface, Config.getPluginEntries(),
> > > Config.getPreferences());
> > >         webView.loadUrl(Config.getStartUrl());
> > >
> > > Right now, we're getting the configuration from the Config class,
> because
> > > we at least have access to this.  If we don't have this, how do people
> > get
> > > access to the list of plugin entries specified in Config.xml?  I'm
> pretty
> > > sure we still want to support this feature.
> > >
> > > Does that make sense?
> > >
> >
> > I gotcha. So, I think the answer is to use ConfigXmlParser() to extract
> the
> > information required by init. You shouldn't need the call Config.init()
> at
> > all.
> >
>

Reply via email to