Here's an example:
ConfigXmlParser parser = new ConfigXmlParser();
parser.parse(activity);
webView.init(cordova, parser.getPluginEntries(), parser.getPreferences());
Feel free to iterate if you think the API is too obtuse, but I think it's
good to allow a file-less mode, and to allow different WebViews to have
different settings.
On Mon, Mar 9, 2015 at 8:08 PM, Joe Bowser <bows...@gmail.com> wrote:
> Do you have an example of how this would work? This seems to be a lot more
> complex than it needs to be.
>
> On Mon, Mar 9, 2015 at 5:05 PM Andrew Grieve <agri...@chromium.org> wrote:
>
> > 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.
> > > >
> > >
> >
>
