Third Party WebViews on Android

I’ve gone over the Android WebView numerous times throughout the years, complaining about performance, and about various browser bugs that never seem to be fixed. In addition, there have been numerous people implementing third party WebViews using bundled versions of Chromium, and in Mozilla’s case, a bundled version of Gecko. That being said, until now you would have to use a whole new fork of Apache Cordova, which often were behind existing versions of Chrome.

On the Apache Cordova project, we decided that it’s not a good idea to get into the browser business, and instead that we should allow people to have a choice in web rendering engines so that they can be installable like plugins. We’re not quite there yet, but that was the thought process behind this new proof-of-concept.

Corodva Android:
Crosswalk Example Engine: (requires the crosswalk core library)

Currently only have Crosswalk implemented to work with this, but hopefully GeckoView will soon be added as well, as well as a Chromium view from Google that’s decoupled from the default WebView. There are some downsides to this approach, such as:

  • Third Party Libraries make applications larger – A crosswalk version of Mobile Spec currently weighs in at 54.95 MB
  • Third party webviews aren’t always on – Android WebView is already initalized, and is starts quickly. A third party webview may be slower to start.
  • Third Party webviews have their own bugs

The goal of this change is to promote choice and to allow for users to use whichever rendering engine they feel works best for their project. Despite the flak that the Android WebView currently gets, there are a LOT of projects where it’s far more appropriate than Crosswalk. Ideally, we would like to see more choices for developers.

Thoughts on Glass

So, I’ve been working with Google Glass for a month. I don’t currently own a pair, so I’m borrowing a pair from work to use. Here are my thoughts on Google Glass so far, now that I’ve given them back.

Google Glass is awkward to use for recording

Having to speak commands is not always useful, especially when you wear glass in non-optimum weather conditions, like when it is cold. The alternative is to tap on the touchpad on the side of your head, and this makes it tricky when you are somewhere like Stanley Park, trying to record the Bright Lights Train Ride. Also, it’s ridiculously easy to accidentally record people without their consent, which is why you should only record in public, or if you’re making a DIY video with your hands or something.

Crap Battery is a feature, not a bug

I think there’s nothing wrong with the battery on Google Glass for it’s intended use case. The reason I think this is because it’s not intended to be used as a long-term recording device. I used it to record the Trinity Street Lights, and after less than an hour, I went from 100% to 22%. Recording about an hour of video takes about all your battery life, which I think is a good thing, since this is the only way that someone can record someone without their consent without it looking like a nervous tick.

Glass needs shutters/covers and a recording light

Glass needs a way to indicate that you’re recording. The display does light up but you have to look directly at someone to tell if they’re recording, because the light is dim. There needs to be an attachment to place on and off the camera to indicate whether you’re taking in data or not. You don’t need the camera for 90% of what Glass does right now, you only need it for recording video, and taking pictures.

Content on Glass doesn’t make sense

Reading on Glass is a pain, it’s good for a few notifications, but most of the apps, including things such as Field Trip, are irritating. Ingress on Glass as it exists today would suck. Cordova apps on Glass, while they are possible, need to cater to the platform, because the Web sucks on Glass. It’s still fun to write Cordova Apps on Glass, and I’ll still do it, but the apps are going to be very different than apps on any other platform. Write Once, Run Anywhere isn’t going to happen easily.

So many questions boil down to WHY????

  • Why can’t my Glass device communicate with my Android phone better?
  • Why can’t I see Hangout notifications on Glass?
  • Why is the frame so rigid?
  • Why do these things cost $1600 still?

Right now, I’d say that the Glass software is about as mature as Android 1.0 was. It would be great if Glass was to become open source and if there were multiple vendors. I think that the Glass Developer Kit Preview was awesome, since the Mirror API and the Vendor Lock-In to Google App Services was bullshit. I also think that there are many use cases for Glass, BUT I don’t think that it’s a mainstream device without Google’s other project, Google Helpouts.

Overall, I like Glass, and I’d probably buy a production pair. I wouldn’t pay to join their developer preview if I knew now what I knew then, but I definitely have some uses for Glass. Also, more integration with mobile is a must for this device. I should be able to push what I’m browsing with Glass onto my phone, tablet or laptop. The problem with developing these features ourselves is the same problem that we have with a closed roadmap. We have no idea what Google is actually planning, and that’s why it’s frustrating to solve a lot of these problems.

Starting with HAM Radio in Canada

For years, I’ve been meaning to get my Amateur Radio Licence and back in April, I finally did it.  However, I haven’t done anything with it until recently, and I figure that I should probably start blogging about HAM.  I know that many people at various hacker cons have been convincing people to get their licence, and Make Magazine has featured Amateur Radio numerous times.  The problem with most mainstream guides is that they’re American, and the system the FCC has set up is more complex and isn’t as straightforward as the Canadian system.  In addition to that, the US has more people, and as such has more Amateurs under the age of 40.  That matters, because if there’s not new blood, corporations are going to start grabbing more and more frequency for themselves, and that’s bad for anyone who has an interest in RF.  I think that Rogers, Bell and Telus owns enough spectrum in Canada, IMO.

Why the hell would I want to do that?

Having a HAM Radio opens up a world of possibilities for hackers. There’s something to be said for having one of the only technologies that can communicate with satellites in space.  Yes, REAL SPACE, as in Low Earth Orbit.  That, combined with being able to experiment with voice and data on amateur frequencies makes this a useful licence to have.  For example, in theory, I can now legally run OpenBTS as a secondary user of the ISM band by setting the ID of my tower as my call sign and not running encryption.  As long as I don’t interfere with other users of the band, it’s all good.  (I’m not sure how practical this is, since many phones won’t operate when you use the bands, but it’s legal at that point.)

Also, if you actually go outside a major city, you’ll notice that all the Telco providers suck at providing a network in remote areas.  In BC, I know that I don’t get good signal in the Fraser Canyon, and I also know that Eastern Oregon has bad signal based on my trip to Burning Man last year.  Being able to radio for help while stuck in the heat isn’t exactly radical self-reliance, but it’s a hell of a lot better than going through all your camping supplies in a day and risking dehydration in the summer, or worse.  Being prepared isn’t a bad thing.

At any rate, there’s no guide for people to become HAMs and so I’m blogging about my experiences.  This blog post will now be mostly about getting licenced:

Getting Licensed

The best way to get licensed is to take a course from a local HAM club.  I did my exam at VECTOR, and their main goal is to try and get people licensed so that they can get more people to help them during their field days and other major events, such as the Celebration of Light.  I’m mostly interested in tinkering, but this is a very important aspect of Amateur Radio, and I recommend this course.  The downside is that when I took it, it started at 7:00 AM on Saturday, and most of my friends weren’t as dedicated, which sucks.

That being said, the best way to practice for the exam is to use Exhaminer, and to do it over and over again until you pass the exam.  This is very much memorization, but it does help that you actually read the book.  Most of the answers are common sense, such as questions about having a high-powered antenna near people.  I basically went into University Study Mode when I studied for it, and I got Basic with Honours easily.

(If you use a Mac, you’re kinda SOL, since I couldn’t get WINE to work right on a Mac.  I did all my studing on my Ubuntu box.  One thing that you’ll find in HAM Radio is that most of the easy software tools to use are implemented in Windows.)

The Radio Amateurs of Canada has a list of clubs, but the problem with this is that it hasn’t been updated.  I personally haven’t had any luck contacting the UBC HAM Radio club by e-mail, and many people at VHS who tried contacting them suspect that it may be defunct.


If you have a problems finding a course, ask around the local hackerspace.  I know that Vancouver Hack Space does have some active HAMs, as does and foulab in Montreal.  Chances are that there may be enough interested enough people to form a club at the Hackerspace and offer classes.  This is something that’s been looked at for a while at VHS, and hopefully we’ll do more HAM stuff there in the near future.

Licence Levels – Canadian Style

Unlike the US, where there’s numerous qualifications, Canada only has three main qualifications.  These are the following:

  • Basic (with and without honours)
  • Morse Code (5wpm and 15wpm)
  • Advanced

I have my Basic with Honours, which means that I have access to all the bands.  They assume that if you get over 80% on the basic exam, you can be trusted to study what you need to know to not make a total fool of yourself on the gentleman’s band.  Morse Code isn’t required for using Ham Radio in Canada or the US, but if you go to any other country in the world, you most likely can’t operate there.  Also, if you are a US amateur looking to operate in Canada, you only have Basic without Morse, because the reciprocal treaty is over 50 years old.  I’m probably going to get Advanced and Morse so that I can operate in Europe when I go to the next Chaos Communications Camp.

Anyway, with Basic, you can transmit on the Amateur Radio Bands above 30MHz, and with Honours, Morse Code and Advanced, you can transmit on the Amateur bands below 30MHz.  Advanced also gives you the ability to build your own equipment for your own use, and for use by other people who also have the Advanced qualification.

I think I’ll stop my blog post here for now, but I recommend that people find a club and get licenced.  It’s important to use this band properly, because it helps protect a public resource and privilege that will go away if it is neglected or abused. I’ll have more posts about HAM in the future, mostly about my adventures in HAM.  They can include things such as how to get started on a budget, as well as talking about fun SDR tricks.  I’m thinking that these blog posts would be useful for people in Canada starting out.

Introducing Cordova 3.0.0 for Android

Once again, it’s time for another release of Cordova, this time Cordova 3.0.0.  This is a major update and a major departure from the previous release in that there is only a single built-in plugin, the App plugin, which deals with Android-specific methods such as allowing the user to override the back button and clear the cache.  All the other plugins are now broken out into their own repositories.   More details can be found here.

In addition, the workflow has changed for producing an application.  Instead of downloading the applications, Cordova can now be downloaded using the Node Package Manager (npm).  This is an optional change, since many users who have existing projects, and existing Java code may choose to not use this system.  We’re also using other tools, such as plugman, to help with this task.

To take an existing Cordova-Android project to 3.0.0, you can run the update script to replace the JAR and the Javascript file, but then you also have to install the existing plugins that you may be using, such as geolocation.  Information for plugman can be found here.  This does require checking out the plugins, and this may be extra work, but it does offer the benefit of not having to ship a bunch of extra APIs with your app that you’re not using, such as Device info or Accelerometer.

If you’re not keen on upgrading to 3.0.0, we still are supporting and backporting fixes to 2.9.0.  However, we feel that the ability to control which APIs that you ship with your application is a worthy enough change that you’ll want to upgrade to this new version.

Introducing Cordova 2.9.0 for Android

We just finished the last minor release of the 2.x series of Apache Cordova, Apache Cordova 2.9.0.  This release features the following changes and fixes:

  • No more dependencies on Apache Commons-Codec
  • CB-3902: Market URIs now work every time in the WebView
  • Pre-Honeycomb Devices will no longer get errors with WebResourceResponse
  • Wait for Emulator works with the Android CLI scripts
  • Strange issue with Javascript being improperly executed through loadUrlIntoView causing crashes has been resolved

This was mostly a maintenance release, and no new features were added.  Right now, we’re going to be moving most of our features to 3.0 and beyond, and that this branch will only have bug fixes.  Also, since this is the last 2.x minor release, any future releases on the 2.9 branch will be patch releases only (2.9.1, 2.9.2, etc).

Once again, this is the LAST RELEASE before 3.0.0, and 3.0.0 will be radically different than 2.x.  While we hope that people migrate to the new 3.0 version of Cordova, we do understand that people will want to use this for a while.  I recommend moving all plugins to the new CordovaPlugin API so that they work with 3.0 and beyond.

config.xml changes for iOS and Android

Ever since PhoneGap 2.0, we have been trying to migrate to the W3C Widget Specification so that Apache Cordova’s configuration would be more in line with the configuration found in PhoneGap Build, just to provide one example. The new format that we will be migrating to for PhoneGap 3.0 may be a surprise, but it’s relatively easy to migrate to the new format.

widget vs cordova:

Since we are adopting the widget specification, the document must be a widget document, as specified as this header:

<widget xmlns = ""
id = "io.cordova.helloCordova"
version = "2.0.0">

There are other tags such as description, and author that are mostly ignored by the current Android implementation. The first relevant tag is the access tags for whitelisting:


Currently, we only whitelist http and https sites, and we do not support specifying a port in the whitelist. The whitelist looks like this:

<access origin=""/>


<access origin="*"/>


<access origin="" subdomains="true">


The start page is specified in this document, Cordova Android and iOS supports both local and remote documents:

<content src="index.html" />

<content src="" />


The preferences may or may not be platform-specific, and consist of name/value pairs. More information can be found in our Cordova Documentation:

<preference name="loglevel" value="DEBUG" />


Instead of specifying a plugin, we now specify features and the platforms that they are associated with, for example:

<feature name="Echo">
<param name="android-package" value="org.apache.cordova.Echo"/>
<param name="ios-package" value="CDVEcho"/>

In the above example, we are migrating the Echo plugin over to Android and iOS. The feature is called Echo across all platforms, so this is the feature name. If you have a plugin that has a different name across platforms, each of them will need their own feature tags. The following child tags indicate where each type of package could be found. On Android, Cordova Plugins are Java classes, so the full class name, including the namespace belongs in the value. On iOS, Cordova Plugins are Objective-C classes, so you would only use the class name as the value.

There are additional features in the config.xml, but this should cover the basic ones that you will need when migrating from the old format. More information can be found in our documentation.

Death to setProperties

One pet peeve of mine with Cordova was the fact that to do certain things, you still had to set certain properties such as splashscreen, timeouts and other minor details. These APIs traditionally only had documentation at the top of, which is not a really intuitive place for documentation. Also, having to edit Java code just to do basic things means that we kind of failed at the whole HTML/Javascript based app thing, so we decided to move everything to config.xml and to get rid of this so that things are easier.

So, we replaced things like:

super.setIntegerProperty("splashscreen", R.drawable.splash);


<preference name="splashscreen" value="splash" />

Now, we already did this change, but you may have noticed that setIntegerProperty and the other setProperty methods still work, but if you ever looked at your logcat, you should see this message:

Setting integer properties in CordovaActivity will be deprecated in 3.0 on July 2013, please use config.xml

We’re not kidding. This is one of the things that will break when 3.0 comes out. If you haven’t moved your preferences to config.xml, do so now while you have the chance. We’re not going to do what we did with plugins and create a shim for this. We will have a full write-up about config.xml soon, but this is important, because if this change isn’t made, your application will break and we will close every bug related to this with “Won’t Fix”. Since config.xml is actually documented, we feel that this is a major improvement that’s been out in the wild for a while. setProperty was terrible, and should have been removed a while ago, and I’m really glad today that we’re able to move people over to this new way of setting Cordova properties.

Please keep reading the PhoneGap Blog for new updates about what is coming up for Cordova 3.0. We will have more posts landing there soon.

Introducing Cordova 2.8.1 on Android

A little less than two months ago, we improperly deprecated the Plugin API for Cordova Plugins. The reason for this was to move from the old architecture to the new one. However, it seems that once again that people ran into problems with this because we didn’t publish the changes on the blog, and only put them on our deprecation page in the wiki.

Because this change caught a lot of people by surprise, we’re going to re-introduce back for 2.8.1 and 2.9.0. We will not support these plugins in the upcoming 3.0 release, and we expect that plugin maintainers will update their plugins and conform to the new plugin spec that we are working on if they want users to actually use their plugins with new tools that are appearing in new releases. Currently there are way too many plugins that don’t work with the current version of Cordova. There will be more updates about the new updates to Cordova, but for those people who are unwilling or are unable to write the Java code required to upgrade plugins, we put it back. However, this is temporary and your old plugins WILL NOT WORK with Cordova 3.0.

Furthermore, the 2.9.0 release will be a long-lived release and will be the last release of 2.x Cordova. All versions of Cordova after 2.9 will have their plugins removed, and will depend on the new plugman tool. This is done so that apps that don’t need things like GPS or Accelerometer don’t have that extra code kicking around.

Finally, there is one other change in 2.8.1, which is the update script. The update script was created from the create script, and contained a major bug where it deleted projects that made it not suitable to be used by anyone, and unfortunately we didn’t catch it until now. It’s now been fixed and the update script should work, but I recommend reading the scripts before using them. Fortunately, it only affected Linux and MacOS X users, and Windows is unaffected by this change.

Cordova-Android 2.8.1 will be included in the 2.8 download package from, so I highly recommend downloading and updating to the latest version from 2.8.0 and lower.

What’s new for Cordova 2.8.0 on Android

As we’re ramping up to the 3.0.0 release of Cordova, there haven’t been massive sweeping changes on Cordova, but mostly minor ones. The major change is now that cordova.js no longer has a version, which should make upgrading the js easier. Here’s some more things that are new:

  • config.xml is now much noisier when you use the old tag
  • CordovaActivity is replacing DroidGap. This is actually a minor renaming, but we do plan on getting rid of the empty DroidGap class post-3.0 and this will break things. This is done to further discourage people from putting all the code in DroidGap and to give Android Developers a better idea of what DroidGap actually is.
  • 9-patch Splashscreens once again work on Android

Again, this is a relatively uneventful release, AFAIK. One thing that we didn’t do well was announce the updates to the Plugin API. These were updated earlier in the year, and should have been announced, however I’m having a difficult time finding the announcement. What I do recommend people do is check out Simon’s “Why don’t my plugins work in PhoneGap?” post. We’re getting better announcing what we are deprecating, but occasionally things like this happen, which I apologize for.

What’s new for Cordova 2.7.0 Android

Another month rolls by, and as usual, another release of Cordova happens. Some of the big highlights this month are as follows:

  • Camera.getPicture() is fixed for Picasa images
  • is deprecated for CordovaPlugin, plugins must be updated to support this change. This has followed our deprecation policy.
  • has been removed, since it’s useless on most Android devices, and doesn’t make sense on iOS
  • Plugins can now intercept URLs with question marks, number signs and escaped spaces.
  • URL parsing is now more robust
  • localStorage is once again persistant, this breaks WebSQL on Android 4.x

The last change is the most irritating and is one that we’re currently struggling with. Many people use WebSQL in their applications. The problem with this is that it’s not a supported W3C specification, and as such is something that not every platform supports. On Android 3.x and up, the Android team made it so that file URIs can’t open databases. A workaround from the early days of Cordova was used to get around this issue, but there are numerous design issues, and this isn’t guaranteed to work the same way as WebSQL. This is why, for now, we recommend that people use the WebStorage APIs instead of WebSQL, because it is supported across platforms, and is much less likely to break. And even when WebStorage does break, we will fix WebStorage, even if it means breaking WebSQL.

There is a proposed fix for WebSQL where Cordova applications use a different URI scheme, but that may not be implemented until after 3.0 is released. In the meantime, we recommend that other alternatives be used, but we recommend WebStorage. We apologize for the inconvenience since this is something that is beyond our control.