I wanted to make sure that I didn't break the old way of doing things.
On Tue, Mar 10, 2015 at 2:24 PM, Joe Bowser <bows...@gmail.com> wrote:
> The main issue is that this isn't documented anywhere, and this is
> necessary for people to use a Third Party WebView. Also, why didn't you
> bother updating the test with the new API?
>
> On Mon, Mar 9, 2015 at 5:19 PM Andrew Grieve <agri...@chromium.org> wrote:
>
> > 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.
> > > > > >
> > > > >
> > > >
> > >
> >
>
