Eight months ago, I demonstrated the power of using a WebView at OSCON 2014, and Today I can say that we're finally releasing the ability to use Third Party WebViews such as Crosswalk and MozillaView. This means that if you decide that you don't like the default WebView on Android, whether it be the frankenchrome, or the current modular Chromium-based WebView, you can switch it out for something else. The only one that is really ready for production right now is Crosswalk, but I'm hoping that others will release their own WebViews over time, and that we can hopefully see this become a regular thing that developers do when they need that certain HTML feature that's not working correctly, or is just plain missing from the browser.
After concentrating on the core platform for a year, there will probably be more work revolving around the most popular plugins that are used. Some of the stuff I'll be working on will be Cordova, but I'll also be working on stuff for Adobe, as well as personal projects that aren't related to Cordova that I'll probably write about here.
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.
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.
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
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.
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.