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. >
