The old API supported authentication with a username and password, but that’s not allowed in the new API. Instead, you need to use OAuth for access.

If you want to have server-to-server authentication, without user interaction, you need a “two-legged” OAuth process, where a token is obtained with an encrypted request and then used for future service requests.

One library that used the Documents List API is the Google Drive gem – the gem used to support user/password authentication, but after the switch-off, it’ll only support OAuth.

The parameters and their defaults are the same as those for the to_sentence method (apart from the locale parameter, which I haven’t got round to).

The code replaces the last word connector and the two word connector with the simple word connector, then splits the string on that connector, and trims the leading or trailing whitespace from the resultant array items.

Disclaimer: In reality, I suspect that if you’re trying to convert human-readable sentences – which should be purely for presentation – back into arrays, then your design has gone wrong somewhere, and you should start by reassessing what you’re doing here..!

To allow a new version of Android to be installed, the handset first needs a new “recovery” to be installed. The “recovery” is the low-level utility that just has a few functions, such as update, backup and restore.

To get the recovery onto the handset, you need a utility on your laptop – I used Heimdall, which runs on Ubuntu.

Download the Android sdk from http://developer.android.com/sdk/index.html, and unpack it somewhere (I had problems with file permissions when I put it under /opt, so I ended up putting it under my home directory, as ~/android):

and then ‘source ~/.bashrc’ to make sure you’ve got the new path setup.

Create an app

Create a phonegap app (I use a “projects” subdirectoy):

cd ~/projects
phonegap create my-app
cd my-app

Run the app

Before you run the app, you’ll need to set up an emulator – run the android tool:

android

You may need to select a target (e.g. “Android 4.2.2 (API 17)”), and click the “Install 8 packages..” button (may need several clicks to accept all the licences)

Now setup and start an emulator – in the ‘android’ util, go to Tools -> Manage AVDs, go to the “Device Definitions”, select a device, and use the “Create AVD” button to create a new AVD. Then use the “Start..” button to start the AVD (it may take a surprisingly long time to start fully).

Run the app:

phonegap local run android

You should see the app compile and install on the emulator.

You can do the compile and install steps separately:

phonegap local build android
phonegap install android

Deploying to a real phone

The emulator seems to run very slowly, and not give much sense of what the app will actually be like on the phone.

So, deploy the app – plug in Android phone via USB, select “USB debugging” in the Developer section of the settings on the phone, and the app will be installed on the phone when you next do “phonegap install…”

The QUnit tests run in the browser, as shown – so you normally have to load the test page manually.

PhantomJS

Loading a webpage in a browser is no good for automated testing, which is wherePhantomJS comes in. It’s a headless webkit, which allows the QUnit tests to be run as a command line task rather than in the browser.

To run the QUnit tests, you invoke the PhantomJS with a Javascript utility called run-qunit.js that evaluates the page as if it were in a browser:

phantomjs run-qunit.js file://`pwd`/test.html

If any tests fail, you’ll get an error exit code, which you’ll need for automated builds.

There are some prerequisites for running PhantomJS on some platforms (looking at you, Centos 5) – it needs the extra package fontconfig installed:

yum install fontconfig

Download the latest version of PhantomJS from the PhantomJS downloads page, unpack it, and make sure it’s command-line accessible by symlinking from the /usr/bin directory to the exe, e.g.:

ln -s /opt/phantomjs/bin/phantomjs /usr/bin/phantomjs

(this is for Ubuntu, and assumes that you’ve unpacked the downloaded archive into /opt/phantomjs)

JSCover

The final piece is JSCover, a tool that show you how much of your Javascript code is actually being exercised when your test suite runs.

JSCover works by instrumenting the Javascript and recording which lines are called during the tests. To do this, it needs to run a minimal server that serves the QUnit page that contains the tests.

Download the JSCover files and unpack them to somewhere like /opt/JSCover.

JSCover will load the page, instrument the Javascript, excecute the tests, and write out a coverage report.

The web report looks like this:

Putting it all together

To run the whole thing as part of a build, you need a build target that will start the JSCover server, execute the QUnit test suite using PhantomJS, write the coverage report to a specified directory, and shutdown the JSCover server.