infil00p.org

Personal Blog for Joe Bowser

Introducing MozillaView - GeckoView Proof of Concept

Over the past couple of months, I've been working on making the Pluggable Webviews a feature with more than one webview, which led me down the path of adding GeckoView to Cordova. The thing with GeckoView is that it is not a Chromium-based webview like the default Android WebView, the WebView in Android 5.0, the WebView used in Amazon FireOS, or the Crosswalk WebView that I demoed at OSCON and PhoneGap Day US. Instead, this is based on Gecko, which is the core technology behind Firefox, Firefox OS and Firefox for Android.

There were a lot of technical challenges involved, but this blog is going to talk mostly about the general architecture of the Multiple WebView featue as it exists today, and how we managed to shoehorn in GeckoView.

The Architecture

Right now we have an interface called CordovaWebView, which will most likely be renamed CordovaWebInterface. This provides the basic surface that is required for the view to operate as a view. It would be great if mulitple inheritance was a thing, then it would be possible to guarantee that every CordovaWebInterface implemented the View class and could be used as a stand-alone component, but we are not at that point today. I recommend that this be the case, as it is with MozillaView and the default Android WebView but this is not the case with Crosswalk.

At any rate, any class that implemnts the WebInterface will be able to be loaded by the CordovaActivity based on a setting in config.xml which specifies the class that will be loaded. If no class is loaded, then the default Android WebView is loaded, and Cordova works now like it has in the past.

However, if you do load the class, then the class is loaded instead, and the basic methods are run so that the class can intialize itself and display on the screen. In this case, this means that MozillaView, which extends the GeckoView, has to create a browser to associate itself with, and create a Chrome object and a content object. These objects are what are required to run the bridge.

We requested a bridge from the Chrome team to allow us to get our Cordova plugins to work with GeckoView, and we have something that's prety cool. Instead of blindly bolting on Java objects, GeckoView allows messages to be passed through the Chrome object via a registered JS file which unlike most of the code that Cordova currently runs has modern Javascript features such as promises. I know that I wasn't a big beliver in promises when I encountered this, but as an alternative to the synchronous nature of the addJavascriptInterface method, this is a much better way to handle this. Because, even if you're polling the object to get a result, you can handle the result asynchronously and there's less cahnce of blocking if the plugin implementer does something stupid like not use a thread from the thread pool to do non-trivial work.

Overall, I really think this approach works better and has less code overall than the hacky approaches that we've had to do in the past with Chrome, such as use timeouts because of the brittleness of addJavscriptInterface. This has definitely been a learing experience and I hope other people look at this code as well, since there's some interesting things to be found here.

What's this work on?

MozillaView works on Android 2.3 all the way up to Android 5.0. We obviously can't guarantee that things will work at that point. This code does require a special version of cordova-js that can be found on my Github repo. Of course this relies on Nightlies so it can break at any time.

Of course, the actual plugin can be found in my repository here

What's next

I'm interested in adding other PoC webviews in the new year, such as the new library that's used in the Krypton Browser (BTW: Please stop calling everything Krypton! Every second tool that I look at using is called Krypton! It's confusing me.), or play with Servo and try to shoehorn it in. That said, I might take a break from the WebView stuff and do work I can't blog about. In that case, I'll probably just fill this with my open hardware and radio hobbies.

Written By

City of Vancouver Fails at Privacy

So, there's a municipal election coming up. I don't blame you for not knowing about it, since it's a very boring affair where the party with the most developer dollars manages to convince the electorate to stay home by being boring and bland. Each side claims to be from the community and talks about the environment or transparency. Anyway, as a renter in Vancouver who has no hope of owning, I decided to see about updating my voting registration. I then went to the City of Vancouver website and found the following:

Seriously? No crypto? This is 2014, I can't expect this to be real. Turns out there is crypto, but it's going to a non CoV owned website called voterview.ca.

So, who is voterview.ca, I just get a login page when I go here. But I do notice that I can go to another website, datafix.com and see that this is hosted by DataFix, a company out of Toronto, and the servers themselves are in New York on Peer1. This leads to more questions than answers, like why is VoterView.ca gatehring Social Insurance Numbers and does this violate BC Privacy Law. I know that it doesn't violate federal privacy law, but this definitely leads to a lot of questions about data security during an election period. What's amazing is how fast I was able to find this out.

Even if DataFix is totally lawful and above board (which they probably are in most provinces), I really think there needs to be a little more transparency with how the data is being collected, namely whether there's SSL. Right now this could easily be hijacked and used for identity theft as it currently is setup.

Written By

Wear and Chromium

At OSCON this year, I did a demo of something that I just hacked up hours prior, and it worked...while I was on stage.

During the presentaion about Third-Party WebViews, I showed the power of a third-party webview by deploying Cordova 4.x on the Samsung Gear Live watch running Android Wear. This initially worked, and I was able to do Chrome Debugging on the watch itself without any ill effects. However, since I presented on the last day of the conference, I had to quickly grab my stuff, hop into my car in the basement of the Oregon Convention Centre and head back to Vancouver. That's where we start running into problems.

I've been dogfooding the Samsung Gear Live for a week, and I have to say that Android Wear is alpha at best. Apparently this is what they said at Google IO, but they didn't say this to anyone who actually purchased one. Luckily, this was purchased to see if we could get Cordova on the device, so it served its purpose. So, when stuck in traffic on the I5 in Seattle, I check my watch, and the screen is dead.

WTF? What Happened

Turns out that running a WebView or anything else that takes a lot of memory causes Android Wear itself to force quit. I got a notification saying that Android Wear had stopped and a "Cancel" and "OK" screen when I tapped the screen. I eventually was able to restart the watch at a rest stop, but it's clear the reason that Google removed WebView from Android for Android Wear was the huge memory footprint. The question now is, what has a bigger footprint? Chromium or ANT? I'm certain that Crosswalk was never meant to be put on a phone, but if there was a stripped-down version of Chromium that made sense, or even better, a way to run a watch that's based on a Web-Only OS, we could do some interesting things.

So, no Cordova on Wear?

The demo was literally that, just a demo. Good demos exist to show what's possible, to get people to think about new things and to get people excited about working on cool stuff. I'm hoping that my demo did that, but that was in no way any production code. I do not recommend shoving Crosswalk onto a watch. I also think that Android Wear is extremely buggy, and hard to develop for, but is still the most interesting thing to happen in the Wearable Space since FitBit first started tracking steps. Actually being able to develop software for wearables is much better than just buying a closed microcontroller encased in epoxy and rubber and strapping it to a body part.

Written By

Older ›