Brief overview

As part of a recent hackathon, myself and my teammate were struck by a 2am peril. We realised that we needed to run some JavaScript in our Cordova app for a very short period after the app was suspended and screen switched off.

Fortunately, I figured out a way before we lost too much time (or our minds). Today, I’m open sourcing the plugin for all to use.

Background task plugin

Allows you to run JavaScript when the app is active and for 3 minutes after the app is suspended.

Add the plugin with the CLI

Latest version:

cordova plugin add

You do not need to reference any JavaScript, the Cordova plugin architecture will add a backgroundtask object to your root automatically when you build.



It’s really simple, pass the JavaScript function you’d like to execute to backgroundtask.start() and your function will continue to run, even if the app is suspended for at least 3 minutes:


Future development

This plugin is for iOS only and was designed specifically for iOS 8. Issues and pull requests welcome on the git repo.

Core Motion SDK

Since the introduction of iOS 8 and devices such as the iPhone 5s and iPhone 6/Plus, it’s been possible to write a native Objective-C applications to receive core motion data from device hardware and to process that data.


As an advocate of Cordova / PhoneGap, I wanted to bring this functionality to the WebView.

Pedometer plugin for Cordova

I have implemented a Core Motion Pedometer Plugin to facilitate the fetching of pedestrian-related pedometer data, such as step counts and other information about the distance travelled. It really is much more than your average “step counter”.

Add the plugin with the CLI

Latest version:

cordova plugin add

Last published version (note, I’m a often little lazy on this):

cordova plugin add

You do not need to reference any JavaScript, the Cordova plugin architecture will add a pedometer object to your root automatically.

Check feature support

Some capabilities are not supported on all iOS devices, even with iOS 8, so please ensure you use the check feature support functions.


pedometer.isStepCountingAvailable(successCallback, failureCallback);
  • => successCallback is called with true if the feature is supported, otherwise false
  • => failureCallback is called if there was an error determining if the feature is supported


pedometer.isDistanceAvailable(successCallback, failureCallback);

Distance estimation indicates the ability to use step information to supply the approximate distance travelled by the user.

This capability is not supported on all devices, even with iOS 8.


pedometer.isFloorCountingAvailable(successCallback, failureCallback);

Floor counting indicates the ability to count the number of floors the user walks up or down using stairs.

This capability is not supported on all devices, even with iOS 8.

Live pedometer data


Starts the delivery of recent pedestrian-related data to your Cordova app.

var successHandler = function (pedometerData) {
// pedometerData.numberOfSteps;
// pedometerData.distance;
// pedometerData.floorsAscended;
// pedometerData.floorsDescended;
pedometer.startPedometerUpdates(successHandler, onError);

The success handler is executed when data is available and is called repeatedly from a background thread as new data arrives.

When the app is suspended, the delivery of updates stops temporarily. Upon returning to foreground or background execution, the pedometer object begins updates again.


Stops the delivery of recent pedestrian data updates to your Cordova app.

pedometer.stopPedometerUpdates(successCallback, failureCallback);

More framework features

Not all features of the framework are implemented. If you’d like me to add something else that is available, let me know. Issues and pull requests welcome as always on the git repo.

iOS jailbreaking

Jailbreaking is a form of privilege escalation to grant root access to the iOS file system, allowing addition and modification of apps.

This week saw the release of iOS 8, anyone updating to the latest release will see their devices “un-jailbroken” (locked up, I guess). Although the PanguTeam have released a statement announcing that they are working on an iOS 8 jailbreak.

Unfortunately, there are still 10s of millions of jailbroken iOS devices, so preventing your app from running on a jailbroken device could lead to a limited userbase and/or bad App Store reviews.

Cordova / PhoneGap plugin

There are many reasons why you might not want certain features of your app to run on jailbroken devices, so I have written a handy little plugin to add an extra layer of security, to detect if the device running the app is jailbroken - right from your JavaScript.

I recommend you use this plugin to block certain features in your app rather than prevent it from running entirely.

Add the plugin with the CLI

cordova plugin add

You do not need to reference any JavaScript, the Cordova plugin architecture will add a jailbreakdetection object to your root automatically.



jailbreakdetection.isJailbroken(successCallback, failureCallback);
  • successCallback is called with true if the device is Jailbroken, otherwise false
  • failureCallback is called if there was an error determining if the device is Jailbroken

Further development

Issues and pull requests welcome on the git repo.

The Android emulator

I’ve always hated the Android emulator, it actually puts me off developing for versions of Android that I don’t have a real device for (fortunately, I have a lot).

It’s always better to test on real devices anyway, especially since not all versions of Android are the same, despite the Android version number being the same. This is thanks to the hardware manufacturers enhancing Android “with Samsung Touchwiz” or “with HTC Sense” etc, that are neither wizzy nor sensible.

What’s the main reason why I hate the emulator? Because I have time to make and drink a coffee before it loads. There is is only so much coffee one man can drink.

How to speed it up!

That’s right, it is possible to speed up the emulator (drastically) if you have an Intel VT enabled machine and you’re targeting Android 4.0.3 (API version 15) or greater. This solution doesn’t even touch eclipse, I promise.

Step 1

Find out what you’re missing. Run $ android update sdk to launch the Android SDK manager. You’ll notice that each Android version with an API entry of version 15 or greater has an Intel x86 Atom System Image option alongside the ARM system image. You need to install these Intel x86 Atom System Images for each API version you plan to target (you’ll also need each SDK platform if you haven’t installed them already).

Now when you run android list targets you should see Tag/ABIs : default/x86 at the bottom of each target entry (and default/armeabi-v7a if you have that installed too).

Step 2

Download the Intel Hardware Accelerated Execution Manager or HAX(M) for short. This is a hardware-assisted virtualisation engine (hypervisor) that speeds up Android app emulation on a host machine. In combination with Android x86 emulator images it allows for faster Android emulation on Intel VT enabled systems.

Step 3

Create your new Android Virtual Devices (AVDs), (more info here). The key is to specify which ABI to use, which is missed out from the documentation. e.g:

$ android create avd -n <NAME> -t <id> --abi default/x86

You’ll still have time to make a coffee but perhaps not to drink it :)

Screen size and density

Android devices come in a vast array of different screen sizes and screen densities. This makes it tricky to say “this app should only be available to phones” on the Google Play store.

Here is the most concise way I can find to achieve the desired result. Include the <compatible-screens> element in the AndroidManifest.xml file like this (my original gist here):


<screen android:screenSize="small" android:screenDensity="ldpi" />
<screen android:screenSize="small" android:screenDensity="mdpi" />
<screen android:screenSize="small" android:screenDensity="hdpi" />
<screen android:screenSize="small" android:screenDensity="xhdpi" />
<screen android:screenSize="small" android:screenDensity="480" />
<screen android:screenSize="normal" android:screenDensity="ldpi" />
<screen android:screenSize="normal" android:screenDensity="mdpi" />
<screen android:screenSize="normal" android:screenDensity="hdpi" />
<screen android:screenSize="normal" android:screenDensity="xhdpi" />
<screen android:screenSize="normal" android:screenDensity="480" />
<!-- ... -->
<!-- ... -->

480 vs xxhdpi

The android:screenDensity="480" can also be written as android:screenDensity="xxhdpi" but depending on the min SDK version you are targeting, the xxhdpi may be unrecognised and cause a build failure. Fortunately, 480 has the same result because the standard quantised dpi for xxhdpi is 480.


I’ve seen xxxhdpi in the Android source but I’ve not seen a phone with the capability yet. I imagine this will have a standard quantised dpi of 640, so you will able to use this similar trick in future.

Now all you have to do is create the 100s of assets you need to actually support these screen densities.

What’s next? CastlemaineHDPI? (XXXX).

The Cordova CLI

Since the Cordova CLI was introduced about a year ago, building and deploying Cordova apps for development has become incredibly simple and automatable. E.g. for Android:

$ cordova build android

and you can also run the app directly on the device / emulator

$ cordova run android
$ cordova emulate android

If you want to build a release version of an APK from the command line for production, this is also possible. However, this does not sign your release:

$ cordova build android --release

Here are the 2 methods I use / have used to achieve API signing for production / distribution. Don’t worry, neither of them use Eclipse!:

Android signing

Note: Before you can use either of these methods, you must have generated a private key, see Obtain a suitable private key on the Android Developer website.

Method 1

Use jarsigner directly

This is the method I used to use and it isn’t Cordova CLI specific (it’s part of the Java SDK build tools and this method is part of their standard documentation). After you have created your APK (cordova build android --release) you can run the following command:

$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore release_key_name.keystore app_name.apk alias_name

Jarsigner will prompt for the password and sign the APK.

Method 2 (best)

Part of the CLI workflow

This is now my preferred method and hooks directly into the cordova build android --release command.

Create an file in platforms/android/ with a keystore path and alias name:


The standard Cordova CLI release build process will now prompt for the password and automatically sign the APK, ready for upload to Google Play, or other distribution method. The APK will be created at platforms/android/ant-build/app_name-release.apk.

Happy release automation.

iOS 8 Beta and Cordova <= 3.5.0

If you’ve had a play around with iOS 8 beta (like me), you’ll probably have noticed there’s an issue.

Cordova / PhoneGap iOS 8

WebKit iOS 8

If you take a look at the WebKit iOS 8 release notes you’ll see it makes specific mention of Cordova / PhoneGap:

Applications that use Apache Cordova / PhoneGap are broken due to a bug that causes the window.navigator.userAgent object to become undefined when window.navigator is replaced by a pure JavaScript wrapper object.

Essentially, what happens is Cordova / PhoneGap replaces the window.navigator, as you can see here.

The solution

Although this will be fixed in Cordova 3.6.0 when support for the new Cordova bridge under iOS 8 WKWebView is implemented, Eddy Verbruggen has come up with a neat little fix to check if the navigator.userAgent is undefined and assign a return value to it:

if (navigator.userAgent === undefined) {
navigator.__defineGetter__('userAgent', function() {
return("Mozilla/5.0 (iPhone; CPU iPhone OS 8_0 like Mac OS X) AppleWebKit");

Also, targeting 7.0 (which I doubt you’re doing if you’re playing with iOS 8 beta) should also still work.

iPhone fingerprint recognition

In August 2013 (before Touch ID or the iPhone 5s were released) I wrote a blog post guessing that the hardware and software capabilities of fingerprint recognition could be just around the corner and might become available to app developers.

Apple, to much disappointment, kept the API private with iOS 7 but this has all changed with the (beta) release of iOS 8. Now, you got the touch

The local authentication framework

The moment Xcode 6 beta had finished downloading, the first thing I did was create a dummy project with the newly available “Local Authentication” framework. It took me quite some time to realise that adding the reference (either #import <LocalAuthentication/LocalAuthentication.h> or as a module @import LocalAuthentication) broke the build if you don’t target a real device (learn from me here and save yourself some time!).

Cordova / PhoneGap plugin

The next logical step for me was to create a plugin from my test code, so that I could launch Touch ID authentication right from within my JavaScript.

The plugin is now in beta release (as is the API and subject to change etc). I have added this to plugreg and you can also view the full source code on Github.

Add the plugin with the CLI

cordova plugin add

Using the plugin

Ensure you use the plugin after your deviceready event has been fired and you are targeting a real device.


Pass the following arguments to the authenticate() function, to prompt the user to authenticate via TouchID:

  1. Success callback (called on successful authentication)
  2. Failure callback (called on error or if authentication fails)
  3. Localised text explaining why the app needs authentication. This should be localised and provide a clear reason for why you are requesting that the user performs the authentication, and what action you will be taking.
window.touchid.authenticate(successCallback, failureCallback, "text");


Although the authenticate() function will return an error if the user is unable to authenticate via Touch ID, you may wish to check support without prompting the user to authenticate. This can be done by passing following arguments to the checkSupport() function:

  1. Success callback (called if authentication is possible)
  2. Not supported callback (called if policy can not be evaluated, with error message)
window.touchid.checkSupport(successCallback, notSupportedCallback);


Probably. Issues and pull request on the git repo please. Remember this is still beta.

Adds is a simple mobile and tablet game, created by myself with Cordova / PhoneGap. It’s been several months in development and I have been sharing most of my experiences as I’ve been going along, but I think it’s time to sum up.

Yesterday, I finally released version 1. The app landing (promo) page can be found here.

iPhone teaser

The concept

To play, you swipe over numbers in a grid to add up to a total at the top. It’s very easy to play, but difficult to master.

You can swipe in any combination of directions (up, down, left or right) but you can’t go back on yourself (use the same number twice) or move diagonally.

It was tricky to implement the main game grid in JavaScript (especially with the touch interactions) but now, it’s exceptionally stable, testable and portable. I wrote about some of the early logic here last November.

The game

The game is broken up into 3 main sections:

1. Endless play

This is where players battle it out to reach the highest score and the sky is the limit! The core concept is that you start off with 10 seconds on the clock and for each number in your answer, you gain a point and an extra second.

There are 3 different difficulty modes available for selection, Easy, Medium and Hard. You must score 50 or more in Easy mode to unlock Medium and 50 or more in Medium to unlock Hard. There are no in app purchases to shortcut this. The difference between these difficulties is the grid size. Easy is a 3x3 grid, Medium 4x4 and Hard 5x5.

What people might not realise about the endless mode is that all the difficulties do get progressively harder (every 50 points you score to be exact). What I mean by harder this time is both the numbers in the grid and the totals get bigger.

The trick is to store up as much time right at the start and pass if it’s not immediately obvious.

2. Levels

There are currently 15 unique levels. 5 branded “Cadet”, 5 branded “Lieutenant” and 5 branded “Captain”. All Cadet levels are on a 3x3 grid, Lieutenant 4x4 and Captain 5x5.

Each level has it’s own “theme”, such as only odd numbers on the grid or even negative numbers… but I don’t want to spoil too much for you :)

The levels start off easy and get progressively harder. 3-5 (the fifth Captain level) is exceptionally hard and I have only completed it once myself! Although you will be satisfied with the gratification of beating level 3-5, you are also rewarded by having the time trial mode unlocked for free.

3. Time trial mode

Accessible after completion of all 15 levels, or via in app purchase, time trial mode does exactly what it says on the tin. Choose your grid size (3x3, 4x4, 5x5) and your duration (90s or 180s) and you’re off.

Hints and tips

  • Remember to pass. Don’t waste time if a solution isn’t immediately obvious. You do lose a point for passing, but it’s worth it in time gained. There’s also a “Gold Pass” in app purchase that allows you to pass without ever losing a point.

  • Use the smallest numbers. You get a point for every number in your answer, so it makes sense to use the longest answer (most numbers).

  • Don’t guess. Five wrong guesses in a row will lose you 5 points. Epic fail.


There’s a leaderboard for everything. I didn’t want simply passing a level to be enough, I wanted players to complete to see how fast they could complete a level. Thanks to my game center plugin friends and family can compare scores and times. They can also battle against everyone else in the world.


The game is currently optimised for iOS 7 devices (iPhone, iPod touch and iPad). Thanks to Cordova / PhoneGap and the way I have developed it, it’s considerably easier to port to other platforms, such as Android and WP8. This is currently a work in progress dependant on demand.

Device sizes

There were several different screen sizes to consider while developing the interface, such as the shorter iPhone 4 screen (320×480 or 640×960 retina), the taller iPhone 5 resolution (640×1136) and of course the various iPads. I wanted to ensure I used exactly the same code for each.

By utilising clever media queries and base font sizes, I was able to adjust sizes relatively easily keeping the same game play. I still had to create the million splash screens and icons though :). Essentially, the numbers grid itself is 1.5x bigger on tablets and things become a little more spaced out. The flip transitions are omitted from tablets (replaced with a quick quick fade), as they just didn’t feel right on the larger screen, even the iPad mini.


Naturally, I’ve had to use/write some Cordova plugins to achieve the games required functionality, here’s a list (excluding any core plugins):


None. No CSS/UI frameworks. No JavaScript frameworks.

I refuse to use frameworks, it’s the best way to create a fluid, light weight, performant app.

Number puzzle games

There has been a increase in number based puzzle games recently, such as “Threes” and “2048”.

I actually started the development for Adds back in October 2013 and I’m hoping to follow in similar footsteps to other number games released during my development. I do believe that my app is unique in its approach and not just another “numbers on a grid” game.

Final notes

I hope you enjoy my little game and become an add-ict too. I can now add like a boss.

If you’re a developer and want a free promo code because you don’t want to pay the 69p, I have a couple left - DM me on twitter.

Please send your feedback to me, it’s the only way I can improve, even if I bite your head off and go defensive :)

CSS transition performance

When I started out developing apps with Cordova / PhoneGap, there were several performance hacks I used to help CSS animations become smoother, i.e. force GPU acceleration.

The CSS transform hacks

Depending on the scenario, I’d usually adopt one of the following (and I’d be careful about which elements they were applied to):

.class {
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
-webkit-transform: translate3d(0,0,0);
/* or */
-webkit-transform: translateZ(0);
.class {
-webkit-transform: rotateZ(360deg);
/* yep, this worked for me in the past! */

Memory allocation

These hacks were never a hard and fast rule, and as developers don’t have control over browser memory, it was easy to create memory issues.


After applying various permutations of these hacks to a game I’m developing with Cordova / PhoneGap, it appears that even using the hacks sparingly and with caution, the performance of the transitions are degraded.

Transitions are jerkier than without the hacks and it hits the performance of the native code when used in parallel (e.g. native transitions). It also forces font rendering to GPU control instead of the operating system rendering scheme, making text appear slightly pixellated on occasion.


In my opinion, with well developed apps and the latest browsers / hardware, these hacks are now redundant (and are likely to make things worse). The chances are, you probably don’t need to use them anymore.

To combat performance issues, you should look at other contributing factors, like the number of elements and use of intensive styles, such as box shadow.