cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Deprecation of Config and the embedded use case (4.0.x related)
Date Tue, 10 Mar 2015 00:08:39 GMT
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 <agrieve@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 <bowserj@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 <agrieve@chromium.org>
> wrote:
> >
> > > On Mon, Mar 9, 2015 at 11:56 AM, Joe Bowser <bowserj@gmail.com> wrote:
> > >
> > > > On Mon, Mar 9, 2015 at 7:39 AM Andrew Grieve <agrieve@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.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message