Have time at the airport to do some work. On Mon Dec 08 2014 at 7:03:16 AM Ian Clelland <[email protected]> wrote:
> On Sun Dec 07 2014 at 11:54:29 PM Joe Bowser <[email protected]> wrote: > > > Hey > > > > After messing with the JS for a week, I decided for now to stop work on > > MozillaView. I think I've managed to prove that the concept is at least > > possible, but I really feel that it's still too unstable to actually show > > past a demo/POC at this time. We've definitely learned some lessons, and > > I'll probably write a blog post on them soon, and pick up work in the new > > year. > > > > I'm glad that it's at least possible, even if it's not trivial. Do you > think there are any other changes we'll need to make -- hooks that we'll > need to provide -- before that project can be called a success? If so, I'd > want to at least consider making those changes for 4.0, so we don't have to > make another major version bump for MozillaView. > > > The work is mostly done. The problems are that GeckoView is still a moving target, and annoying things break. For example, the stupid simple fetch_libs script broke when I tried to fetch the libs because they're doing a new sort based on all the different Android attributes (API 10, x86 vs arm6, etc). That said, the most annoying part was trying to figure out how a plugin could override exec. That's something that I couldn't figure out at all last week. Writing basic plugins, and even changing cordova-js is fairly easy, but this seemed next to impossible. I found that our own stuff slowed me down more than changes Mozilla did. > > > > That said, we should really concentrate on shipping 4.0 in January, we > > should do the following: > > > > 1. Bump up the targeted version to 5.0 > > 2. Allow for users to target KitKat for Quirks Mode (I'm not kidding, > > Quirks mode is back. Chrome is the new IE! WTF MAN!) > > > > Hasn't Android always done that? I thought that was the whole point of > targetSdkVersion (maybe not webview specifically, but device quirks in > general). Anyway, +1 to letting the developer set it if necessary. > > > Yes, it has. > > 3. Get the gradle work in. MUCH FASTER! LESS SPAM! WOW! > > > > It's pretty much all in, and should be the default in 4.0 (I'll check that > to make sure it's true). The last piece is the AAR library support, which > I'm going to test and merge this week. > > 4. Get the JUnit tests working with Gradle/Android Studio. I don't think > > this is a 4.0 task per-se, but we should do it right after 4.0 is > released. > > 5. Stare at the pie chart wishing that 9 was 5. (Anyone who knows our > > deprecation policies knows EXACTLY what I'm talking about). > > > > I do have one API change I want to make. I want to rename the > > CordovaWebView interface CordovaWebInterface so that it's obvious that > it's > > an interface. Since people using the old CordovaWebView embedded feature > > are going to have to do a find/replace on the XML, this doesn't really > > matter. > > > If you're convinced that it's not going to cause any additional pain for > the developers, then I say go for it. It makes more sense as a name (It's > messed me up more than once, looking for the *actual* view class) > > Well, I'm not 100% convinced, but the people who use the feature need to speak up now. > > > Of course, the people using this feature may beg to differ. If > > you're using this feature, and you care about it still working with your > > current code, PLEASE TEST 4.0 NOW. > > > > Strongly agreed. > > > > > > > Thoughts? > > > > Joe > > >
