Conference Season

It’s May, and that means it’s the start of Conference season. I’m going to be speaking at OSCON this year, and this will be my third year officially speaking at OSCON, which is cool. I’ll also be attending the following events this year:

  • Google IO: May 15 to 17th – I’ll be hanging out nearby the Android Office Hours and checking out the Glass Sessions.
  • SF MakerFaire 2013: May 18th and 19th – I’ll be attending this and wandering around on Saturday only. After the direction that O’Reilly took last year with having large corporations get more floor space than people like AdaFruit and SparkFun, I’m not going to stay for both days.
  • JSConf 2013: May 29th to 31st – I’ll be attending this conference for the first time. I’ve heard that this conference is good, but I’ve never been able to attend until this year
  • PhoneGap Day 2013: July 19, 2013 – PhoneGap 3.0. I’ll be here.

There’s probably other events that I’ll be attending, but here are the next few coming up. It should be fun times!

Froyo and the Deprecation Policy

I am pleased to announce that in Apache Cordova 3.0, we will no longer be supporting Android 2.2 Froyo. While this probably doesn’t actually affect to many people, this does mean that we are going to be able to get rid of our one dependency. We’re already getting rid of support for Android 2.1 and Honeycomb in Cordova 2.7.0 as well.

What does this mean?

This means that things might still work for you, but if something breaks, we will close your ticket as “Won’t fix”. Most Android tablets have upgraded to Ice Cream Sandwich or later, so unless you have that rare Google IO Samsung Galaxy Tab 10.1 that you didn’t bother rooting, you’re probably not running this version of Android. Now, since Honeycomb and later versions of Android share a lot of the same properties, chances are that things may still work, but I wouldn’t bet on it. As far as Android 2.2 and lower, we plan on actually removing the commons-codec library. Right now, because we’re an Apache project, we have to have a script fetch that Apache project’s binary separately so that our image handling would work. Removing the dependency means that it’s one less binary we have to fetch and one less moving part.

Why the change in the Deprecation Policy?

When we decided to drop support for Android 2.1 and 3.x, we did the six month wait. This basically meant maintaining code that nobody was going to use for another six months because of policy. We felt that this was too limiting, and decided to move to it being released based instead. We didn’t feel that it added to the stability of the project, but we wanted to avoid the breakage that happened when we introduced CordovaWebView.

When will you be dropping Gingerbread?

We drop Android versions once they get below 5% of the user base. Gingerbread is still at 45%, and there are still new low-end Android devices that are sold with Gingerbread, so we will be supporting that for quite a while yet.

What’s new for Cordova 2.6.0 on Android

This the first time that I’ve done the “What’s new with Cordova” blog post. This release was mostly a bug fixing release, but we did manage to resolve many issues that were long standing with the Camera. This is mostly based on the GitHub changelog:

  • CB-1700: EXIF information is now preserved on images taken from the Camera and the Gallery
  • CB-1796: captureImage now can save a copy of the photo to the gallery
  • CB-2305: InAppBrowser now has an API for executing scripts and inserting CSS
  • CB-1933: Changed button labels to an array for notifications!
  • New Native to JS bridge for Binary Strings!

Also, this is the last release that will be supporting Android 2.1 and the Honeycomb releases. Cordova may still work with these versions of Android, but we will be closing all issues related to Android 2.1 and Android 3.x as “Won’t Fix”. We have first announced this change six months ago, and this shouldn’t affect most users since is currently only 1.8% of all Android devices currently in the wild. We are currently discussing deprecating Froyo as well, since it is only 4% of all Android devices, but any future changes to support will be discussed on the Apache Cordova developer list, and will be subject to our deprecation policy.

Speaking at OSCON 2013

Once again I’m going to be speaking at OSCON in Portland this year. This will be my third time speaking officially, and my fourth year at OSCON. This year, I’m going to be talking about testing Hybrid Android Applications, and going through the basic techniques. Of course, I’ll already be down in Portland for PhoneGap Day 2013 the week before, and I do plan on being in the Portland area sooner.

Of course, as usual, I will be posting this year’s slides online. This will cover things like Selenium, and also how to use something other than selenium to do functional testing of mobile applications on Android. There will probably be a little bit of a refresher about pixels, and yes, I will probably use more icons from the Noun Project because they are truly awesome.

Overall, this should be fun times if everything works out as planned.

What else is new in Cordova Android 2.4.0

Normally, Simon Macdonald, who also works on Apache Cordova, writes a blog post listing the new features that landed. However, there’s a feature that should be added to that post that I’ll explain below.

Additional Preferences in config.xml:

Certain features, such as the splashscreen, the error URL and timeouts in the past were undocumented, and would have to be added to the activity at the beginning of the class before we load the URL in the Java file, like this:

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

Since the whole point of Cordova is so that you don’t have to write Java, and to promote web standards, we added these preferences to the config.xml, which should look like this:

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

The new project settings in config.xml can be found here.

Functional Testing of the Android Webview using Java: How purity was invented

A long while ago, we decided to start doing native testing of Android, mostly because we found that we were fixing the same things over and over again on Android in Java.  While the Javascript quality was higher, the Java code was generally the same as when I first wrote PhoneGap back in 2008.  So, we started with manual tests.  Then I got creative and threw in some JUnit tests back when I started working on CordovaWebView.

However, there was something that was nagging us about the manual tests.  Many of these tests required us to click on user interfaces that were implemented in HTML and Javascript.  First we tried to adapt things such as WebDriver to test this, but we found that this was extremely complex to get working on Cordova, and we only ever managed to get an abandoned branch to work with the custom CordovaWebView.  At the end this was completely unmanageable, and we abandoned this work.

However, the tickets remained, such as ones like “Automate JQTouch Tab test” or “Automate iFrame Test”.  The JQTouch one was abandoned because of these develpments, but along the way we discovered how to test the Android WebView using Java and JUnit.

The Android Test Framework gives you some very limited UI functionality tools.  These tools are designed for the Android UI and, they mostly consist of things like TouchUtils.  TouchUtils allows you to click in the middle of view like this:

touch.clickView(this, testView);

This may be super awesome for Android applications, but this sucks for things like Cordova, which is one giant view.  To prove this point, I ressurected some Canvas code that I wrote three years ago and I do some tests on it.


Above, you can see the click happen in the middle. It will always happen in the middle.  There is nothing that I can do to make it not happen in the middle.  This sucks.

I then googled around to see if I can get per-pixel support, and I found a blog post that showed this code:

long downTime = SystemClock.uptimeMillis();
// event time MUST be retrieved only by this way!
long eventTime = SystemClock.uptimeMillis();
Instrumentation inst = getInstrumentation();
MotionEvent event = MotionEvent.obtain(downTime, eventTime, MotionEvent.ACTION_DOWN, 300, 300, 0);

Now, this code is great, except that anyone who has done any Mobile Web Development knows that a pixel is not a pixel.  We have to factor in the screen density.  This is where purity comes in.

In purity, instead of giving the real pixels in Java, you pass in the WebKit pixels, and purity does the calculation required to do the touch where you want it.  The reason it’s called purity is because it’s simple, and it doesn’t clutter up your Javascript with event handlers and injection code.  Eventually, this may be adapted to be a plugin so that purity code can be written in Javascript, but entirely run in Java.

For example, in purity, you would call this to do a touch event:

touchTool = new Purity(testActivity, getInstrumentation());
touchTool.touch(50, 200);

OK, where is the code:

The code is in the Cordova Android test directory on my personal branch here, and it is under org.apache.cordova.test.util. It’d be awesome if someone wanted to make this a third-party plugin, especially those people who have extreme pain with UI interaction on Android.

New Place, No Cash: Why I (probably) won’t be attending OHM 2013 or Burning Man

The issues with the neighbours and the landlord have recently come to a head.  I’m not going to go too heavy into details, but we’re moving to a newer, much larger place in the next few days.  While the new place is awesome, the rent is double what I am paying now, so my plans for heading off to OHM 2013 are on hold.

OHM2013 is the next in a series of Dutch Hacker Camps such as What The Hack and Hacking At Random.  HAR2009 is the one that I went to, and I remember camping on a hill next to the GSM tent, mixing Maple Syrup with Club Mate and realizing that this is a bad idea, and haggling with Julian Assange over the cost my white Wikileaks T-Shirt.  OHM2013 is a fun time and is similar to the Chaos Communications Camp and Toorcamp in the US.

The big downside of OHM2013 is that it is located in the Netherlands, which is expensive to go to.  Unlike Toorcamp, where I was able to just hop in my car, drive across the border and take a ferry, OHM is going to require plain, train and probably a strange car to get into, and will require some European Backpacking, which gets expensive very quickly.  Unlike in Germany, where things are relatively inexpensive, the only thing that seems cheap in the Netherlands is the 3G Data Plans (no showing a passport, and only 50 EUR for unilmited!)

I also won’t be going to Burning Man, mostly because it’s too expensive to rent an RV to head to Burning Man, and my lease expires in September, and I need to be back in town for that in case I have to move again.

The good news is that it frees up my vacation time.  So, I have to decide what to do with this vacation time.  It’s pretty clear that the vacation will probably have these constraints:

  • Camping > Hotel – Camping is cheaper and more fun than staying at a hotel.  I stay at hotels enough for work, so staying at a hotel isn’t a huge vacation.  Hotels are also more expensive.
  • No Flying – I have a kid, and she’s not old enough to go through airport security
  • Kid-Friendly – Most trips should be kid-friendly
  • Be somewhere where I won’t go during the weekend – So, anything on Highway 99 is out, because I will probably do weekend camping trips there

This basically limits me to how far I’m willing to drive.  This also were the constraints of my parents when they went on vacation.  The main difference here is that I’m willing to cross the border with my kid in the car.

So, right now the options are as follows:

  • Yukon trip: Go way up north because we can – This trip does have some serious highlights, such as Liard River Hot Springs, but there’s also a few major downsides to this trip as well, such as 8 hours plus in the car to get from campground to campground.  Of course, since this is the summer, there will be more hours of daylight the further north we go, which is a plus.
  • Drumheller: My kid loves Dinosaurs.  The Royal Tyrell Museum was awesome when I was a kid and it’d be interesting to go there.  The downside is that this would mean booking a hotel in Drumheller while we are there.
  • Kootenay trip: Go through the Kootenays and check out various hot springs, waterfalls and other things.  This is the winner so far, since the distance is the shortest, and there’s lots of camping opportunities
  • Yellowstone: Go through the US to Yellowstone Park.  Traditional US Road Trip, similar to the road trip I did on US 101 last year.  Gas is cheaper in the US, so this may be a real contender as well.

I know that I could just stay home, but that would be boring.  Ideally, I’m looking for a family vacation where I can get the biggest bang for my buck, but also go on an adventure.  The big thing about road trips is that nobody really does this anymore, and you get to find some really weird and interesting things on the highway.  Also, not being bound to a conference or an event schedule like with festivals is a nice touch as well.  I’ll have to narrow it down and figure out when to go, but this should be interesting.

Self-Respect Matters

Yesterday, I had the misfortune of entering a discussion with Asher Wolf right before she quit CryptoParty.  Here’s the backstory that I was operating with when I checked in on something on Twitter.

A few days ago, Asher was tweeting about how she was unable to attend #29c3 because her talk was rejected.  I heard claims that the CCC was sexist, and having known people who are female, feminists, and parents who have talked at past congresses and camps, I knew that this couldn’t be the case unless things went way off the rails.  I posted an open tweet because this just seemed bizzare, and I got some feedback.  I came to the conclusion that there was something else wrong with the submission, and that things were lost in translation and forgot about it.  I’m fiercely loyal to the CCC, since they flew me to Camp back in 2011 and allowed me to talk about the RCMP and State Surveillance, and since they have a history of doing extremely important work.

Then, earlier today, I saw yet another tweet by Asher about CCC being sexist.  She shared a link to the blog, which seems to be documentation of the sexism that happens at CCC.  I feel that this is disingenuous since it just shows that sexism happened.  Even though I’m a white male, I still believe that sexism happens everywhere, and that the world and even the CCC isn’t a vacuum.  The question should be how does the CCC handle the sexism, namely how is the policy enforced.  The CCC has an Anti-Harassment Policy, and this Anti-Harassment Policy can also extend to the web by sending an e-mail to CCC.  This isn’t the be all and end all, but given that people have fought for that Anti-Harassment Policy, it’s important to actually give the conference a fighting chance to enforce this policy to see if it’s not just bullshit, otherwise what is the point of having this policy to begin with.

At any rate, I suggested these solutions, and of course I was then told by Asher that it wasn’t her problem.  I personally believe that it’s everyone’s department to deal with harassment, especially if you’re the party that is offended.  I’m irritated that some of the attendees of #29c3 sunk to the level that DEFCON. However, to just throw mud at the CCC instead of actually sending a e-mail that takes a minute so that the administrators could lock a wiki article is stupid.  If they do nothing, than by all means.

Of course, since I didn’t know the massive backstory about how shitty the CryptoParty organizers were to Asher, and how bullying and bullshit were what really caused Asher to not make it to #29c3, not the strength of the presentation.  The thing is that if I knew this earlier, I wouldn’t have called Asher petty for what I thought was just someone smearing the CCC because their talk wasn’t accepted.  It’s very easy for something to sound like sour grapes without knowing all of the facts, and I apologize for calling that out when that wasn’t the case.  However, I still stand behind my statement that harassment should be reported.

Now, as for my thoughts on Asher Wolf leaving Cryptoparty, I think it’s a good thing.  The reason I believe it’s a good thing is because it’s a wake up call as to who is being served by having these CryptoParties.  I’ve been at two CryptoParties so far, and it so often feels like preaching to the converted.  I don’t like teaching GPG/PGP because it sucks and is hard for people to use, and often the talks diverge to non-practical solutions, such as BitCoin.

My main motivation to host CryptoParty comes from the what got me spied on by the RCMP, which is teaching activists cryptographic tools to allow them to resist the state.  These activists recently do things like participate in #IdleNoMore, fight the Enbridge Pipeline, or engage in other actions that directly confront the state.  However, I personally don’t think that I’ve helped anyone in these causes by sitting in the Vancouver Hack Space and talking about Wikileaks or Anonymous or BitCoin.  The fact is that there are real people on the ground who need these tools, and they don’t have them, and based on this, I consider CryptoParty a failed model for these people to get these tools, because they have to want to go to CryptoParty and have to deal with people who care more about Silk Road than about what happens when the cops come knocking on the door.  I may be wrong and the next CryptoParty may be better, but so far from my experience this isn’t the case.

But the reason I think it’s good that Asher is leaving is that she’s finally standing up to all the bullies.  While I disagree with her being in control of something decentralized, I still think that it’s shitty that she was bullied out of going to #29c3 by people who helped write a talk and that people don’t think that she is qualified to talk about CryptoParty, since they seemed to have missed the point as to what CryptoParty was supposed to be about in the first place.  I just wish I knew who more of these people were, but I can understand the reluctance to name names.

tldr; everyone needs to step up and say that this behaviour isn’t acceptable.  We’re  adults, and we should all act like it.

Chrome Content View: Compilation, Comparison and Thoughts

One thing that we get asked a lot is whether Cordova should bring along its own WebKit when running on Android. The reason for this is pretty obvious to everyone at this point, especially those poor users stuck on Android 2.x. If you’re an Android 2.x user and you went to, you would see something like this:

Yeah, that’s pretty bad, and it doesn’t get a lot better when we go to Android 4.1.

Of course, those are the WebViews that we have access to. If you compare them to Chrome:

Or you compare it with Silk on the Amazon Kindle Fire HD:

It just gets depressing. We know that it’s possible to have Webkit not suck on Android, but since the Android Team neglected the browser, we have to get desperate and do crazy things like build our own. The most reasonable candidate for us is to hack on Chromium, and the only thing that I can get building was the Chromium content view. So, I took my personal Ubuntu 12.10 machine, followed these instructions here, and after fixing a header I got this installed on my phone.

Now, that’s a good score. Sadly, this is a debug build so the performance on it is rather slow, but it does show what’s possible on mobile.  It’s actually comparable to what’s on a desktop version of Chrome minus WebGL according to this test.

However, the reality of the matter is something different.  Currently if you took the Chrome ContentView to and tried to use any of the Adobe examples, the application would currently crash.

As far as us getting Cordova working on it, that’s going to take a lot of time, since the ContentView is structured very differently than the Android SDK’s WebView, and it’s not ready for primetime. Anything that we do will be a hack, and not suitable for the Android Market or anywhere else right now. Hopefully in a few month’s time, we can get something more solid and be able to have better WebViews on Android.

Advanced Tutorial: Using CordovaWebView on Android

Back on the lead-up to Cordova 2.0, we pushed for the implementation of Cordova WebView.  While this broke a lot of things, and irritated a lot of people, it seems that people are actually starting to use this new functionality.  Unfortunately, we also accidentally made a change to it in Cordova 2.2.0. In this post we step through an example that I wrote up using the existing example of the Action Bar from the Android SDK. It should be noted that this guide assumes that you are comfortable with working with Java.

You can find the example of how to use this on a GitHub repository:

Even though CordovaWebView does its best to try to encapsulate all the methods that are required for a working PhoneGap project, there’s still a few things that the activity that holds it has to maintain.  This is why we created the CordovaInterface. In this example, we take the default example of the ActionBar application, and we implement CordovaInterface on it.  When we start dissecting it, we see the following:

public class MainActivity extends ActionBarActivity implements CordovaInterface{
    private final ExecutorService threadPool = Executors.newCachedThreadPool();

This has to be here for the plugins to actually work. Following this, we have our typical variables both from the app, and what you’d normally find in a Cordova Activity:

    private boolean mAlternateTitle = false;
    private boolean bound;
    private boolean volumeupBound;
    private boolean volumedownBound;

    String TAG = "MainActivity-ActionBarTest";
    private CordovaPlugin activityResultCallback;
    private Object activityResultKeepRunning;
    private Object keepRunning;

    CordovaWebView mainView;

This is primarily to maintain the view, then in the create method, we basically do exactly what the old Android WebView example code does, and we find the view, and load our app:

    public void onCreate(Bundle savedInstanceState) {

        mainView =  (CordovaWebView) findViewById(;

Meanwhile, if you look at the XML file, you will see the FrameLayout for the main application. The ActionBar in this case is handled separately by the Android Application:

<FrameLayout xmlns:android=""
        android:id = "@+id/mainView"/>

When using custom widgets, you have to include the full name of the object that you want to include. It should be noted that I made a mistake here and that “match_parent” should be used instead of “fill_parent”, since “fill_parent” will be deprecated. Back in the code, we add the following methods to implement the CordovaInterface.  The first that we add is getActivity.  This is expected to get the activity that actually contains the CordovaWebView so that we can handle intents that are passed to the application.  This is pretty self-explanatory:

    public Activity getActivity() {
        return this;

After this, we implement onMessage, which deals when a message is sent from a plugin to the activity itself.  This currently exists in DroidGap, and facilitates the app plugin functionality, such as the splashscreen, the spinner, and whether the application exists.  This is not entirely necessary to implement, so in this example we simply ignore everything but exit.

     * Called when a message is sent to plugin.
     * @param id            The message id
     * @param data          The message data
     * @return              Object or null
    public Object onMessage(String id, Object data) {
        LOG.d(TAG, "onMessage(" + id + "," + data + ")");
        if ("exit".equals(id)) {
        return null;

Next is the most important, which is the setActivityResultCallback code and startActivityForResult. This facilitates the passing of information from activities such as the Gallery and the Camera back to Cordova. Without this the capture API will not work, nor will any plugin that relies on another activity to start. This does the majority of the Android housekeeping:

    public void setActivityResultCallback(CordovaPlugin plugin) {
        this.activityResultCallback = plugin;        
     * Launch an activity for which you would like a result when it finished. When this activity exits, 
     * your onActivityResult() method will be called.
     * @param command           The command object
     * @param intent            The intent to start
     * @param requestCode       The request code that is passed to callback to identify the activity
    public void startActivityForResult(CordovaPlugin command, Intent intent, int requestCode) {
        this.activityResultCallback = command;
        this.activityResultKeepRunning = this.keepRunning;

        // If multitasking turned on, then disable it for activities that return results
        if (command != null) {
            this.keepRunning = false;

        // Start activity
        super.startActivityForResult(intent, requestCode);

Next is cancelLoadUrl, which was once supposed to cancel the loading of a URL. We decided to get rid of this functionality, but this operation still exists on the CordovaInterface, and will hopefully be deprecated soon. However, we still have to have it.

    public void cancelLoadUrl() {
        // This is a no-op.

The last required method are the following two at the bottom. This is the thread pool and getContext(). Both of these are expected to exist for plugins to function, however one is deprecated, and this is getContext(). Initially the CordovaInterface was once the DroidGap activity, and since an Activity inherits the properties of the context, people would just use the activity, since we can’t assume that we’re using a DroidGap activity, we need to provide an Activity. We do this with getActivity, but some people still use the old getContext() API, which is why this is still here. Eventually we will be dropping this because having two methods that return the same thing is silly.

    public ExecutorService getThreadPool() {
        return threadPool;

    public Context getContext() {
        return this;

Android Lifecycle and Results:

Now, back to actually handling the result that comes back. This is where we use the stored callback and send the result to the proper plugin. This is pretty self-explanatory as well when you look at this code. The thing is that this isn’t a part of the CordovaInterface, but instead is a part of Android. This has to be implemented if you want your Camera, Gallery and other Activity-based plugins to work.

     * Called when an activity you launched exits, giving you the requestCode you started it with,
     * the resultCode it returned, and any additional data from it.
     * @param requestCode       The request code originally supplied to startActivityForResult(),
     *                          allowing you to identify who this result came from.
     * @param resultCode        The integer result code returned by the child activity through its setResult().
     * @param data              An Intent, which can return result data to the caller (various data can be attached to Intent "extras").
    protected void onActivityResult(int requestCode, int resultCode, Intent intent) {
        super.onActivityResult(requestCode, resultCode, intent);
        CordovaPlugin callback = this.activityResultCallback;
        if (callback != null) {
            callback.onActivityResult(requestCode, resultCode, intent);

The other big thing is pause and resume. One of the things that we have to keep in mind is what happens to Cordova and the plugins when they pause and resume. Many of them will save their current state, and these events need to be handled. This is the most barebones code to deal with pause and resume. This does not pause any WebKit timers, so your JS will still run in the background thread, but this will handle Java states.

     * Called when the system is about to start resuming a previous activity.
    protected void onPause() {

         // Send pause event to JavaScript
        this.mainView.loadUrl("javascript:try{cordova.fireDocumentEvent('pause');}catch(e){console.log('exception firing pause event from native');};");

        // Forward to plugins
        if (this.mainView.pluginManager != null) {

     * Called when the activity will start interacting with the user.
    protected void onResume() {

        if (this.mainView == null) {

        // Send resume event to JavaScript
        this.mainView.loadUrl("javascript:try{cordova.fireDocumentEvent('resume');}catch(e){console.log('exception firing resume event from native');};");

        // Forward to plugins
        if (this.mainView.pluginManager != null) {


     * The final call you receive before your activity is destroyed.
    public void onDestroy() {
        LOG.d(TAG, "onDestroy()");

        if (this.mainView != null) {

            // Send destroy event to JavaScript
            this.mainView.loadUrl("javascript:try{cordova.require('cordova/channel');}catch(e){console.log('exception firing destroy event from native');};");

            // Load blank page so that JavaScript onunload is called

Finally, it’s important to handle any new event that appears to the application, which is what we do here with onNewIntent:

     * Called when the activity receives a new intent
    protected void onNewIntent(Intent intent) {

        //Forward to plugins
        if ((this.mainView != null) &amp;&amp; (this.mainView.pluginManager != null)) {

The final result of all this is the following UI that works on Gingerbread, Honeycomb, ICS and Jellybean.

At this point, you could use fragments to have multiple CordovaWebViews, or add plugin code to manipulate the CordovaWebView so that it runs Javascript through a plugin. The reason you would want to do this is for further integration with the platform. This is clearly not for the average Cordova user, but instead for people who are comfortable with Java but still want the APIs that Cordova offers.