Ugh... so I finally managed to get back to this, and spent a day and a half refactoring the AndroidWebView class.
I've pushed the results to a branch of cordova-android called "backwards_compat". (See https://github.com/apache/cordova-android/tree/backwards_compat) It passes all of the mobile spec tests that 3.5.0 passes, for me (I get a couple of fails on contacts, because my test device has too many contacts, and there is a battery-status test which has been failing recently). It's kind of ugly, but it's what we'll need to do to maintain backwards compatibility with existing plugins. The question now is "is it worth it?". Or do we just delay all of this until we want to break backwards-compatibility, say with Cordova 4.0? On Fri, May 2, 2014 at 11:17 AM, Leo Yang <leoyang.web...@gmail.com> wrote: > Since you talked about plugin so do you plan to introduce/merge xwalk > extension mechanism to Cordova plugin mechanism? > > Thanks, > Leo > > > On Wed, Apr 30, 2014 at 12:23 PM, Joe Bowser <bows...@gmail.com> wrote: > > > Hey > > > > So, once again, we're dealing with some major API changes once we > > introduce pluggable webview. The first change that was done for > > sanity was finally deprecating setProperty. This was slated to be > > removed by 3.5 or in six months from the deprecation date, but we kept > > it in too long. While I would like to assume that everyone has moved > > over to setting their preferences in config.xml, which is the much > > more sane way of doing things, we can't do that. We need to publicize > > this in some blog posts, as well as in our documentation somehow. > > There will obviously be some pissed off users, as we've seen in past > > posts, but I think having the ability to use a WebView other than > > Chrome 30 is worth these changes. > > > > The other change, which says more about our design is adding a getter > > method for pluginManager. We need to access the pluginManager to get > > plugins, and it's expected that everyone who implements a > > CordovaWebView will have this method produce a pluginManager. In the > > past, it was just publicly exposed, which was not the greatest idea > > and was kinda sloppy. > > > > So, how do people want to handle these changes? We constantly get > > shit for changing our API when we do development, but I do think these > > improvements are extremely important, especially given how much flak > > we get for relying on Android's WebView. > > > > Thoughts? > > > > Joe > > >
