Get Slips now: http://slips.rareloop.com

We (Rareloop) have just released our first Mac App via the App Store, it’s an easy to use menu bar timer that keeps track on how long you’re spending on tasks. It’s integrated directly with FreeAgent so re-billing your time couldn’t be easier.

We originally wrote Slips for internal use at Rareloop but after having used it everyday for over a year and seeing how much it’s helped our timetracking we’ve decided to make it publicly available.

If you use a Mac & FreeAgent and need to keep track of your hours, I’d highly recommend taking a look at Slips!

Get Slips now: http://slips.rareloop.com

Needless to say, the native apps fared better and more gracefully degraded when no internet connection was available. Offline is a feature and it’s crucial we start to consider it from the start of a project as apposed to adding support later in the development lifecycle. At Rareloop we’ve been focussing on adding offline support to our apps from the start. Most notably the FormAgent mobile clients where designed from the outset to support offline access, to allow for use when no connectivity was possible and to transparently sync up data when internet is available. The following are guidelines I’ve found helpful.

Note, I’m not going to discuss how to cache your app assets (e.g. JavaScript & CSS). Whether you’re using App Cache or a hybrid solution (like PhoneGap) it’s not really important, the guidelines below are more focussed on how to engineer your app to enable sensible offline access and assume your core assets are already readily available via some mechanism.

Basic guidelines

1. Decouple your app from the server

Historically when creating content for the web the server does the majority of the heavy lifting. Data is stored in a database and is accessed via server side code (e.g. PHP or Ruby), the data is then manipulated and rendered to HTML with a series of templates. Many modern frameworks use good Software Engineering principles and separate these tasks in an MVC architecture (Model, View, Controller) but they are still server side. This means that the storing, manipulation & rendering of content all requires a connection to the server.

An offline first approach would be to move the entire MVC stack into client side code (aka our app) and to turn our server side component into a data only JSON API. This keeps the server component largely logic less, lightweight and makes it really easy to write unit tests for.

James Pearce also touched on this at Full Frontal (slides), with a slightly tongue in cheek statement:

no angle brackets on the wire – only curly brackets

Summary:

1. Make sure client side app is not reliant on server side code to produce the minimum viable experience. It should be able to at least render something to say that no data is available.

2. Communicate using JSON

2. Create an API wrapper object in client side code

Don’t litter your app code with Ajax calls and nested callback functions. Create an API object that mirrors the functionality of the API end point you’ve created. This creates a better separation of code within your app which is easier to debug, enables you to write unit tests and crucially allows for mock data to be used if the server side API has yet to be written. The object you create will internally use AJAX but the idea is that from the point of view of the rest of your app, its irrelevant what the implementation details are in order to provide the data requested.

Summary:

1. Abstract JSON API into an object

2. Don’t litter your app code with direct AJAX calls and callbacks

3. Decouple data updates from data storage

It might be tempting to now just request data directly from the API object straight into our view objects for rendering with client side templates. I’d suggest creating a Data object to act as a proxy between the API object and the rest of your app. This new Data object is responsible for making requests to the API for updates and processing the responses. This includes indexing any results received for quick retrieval within the app, synchronising any data stored when no connection was available or just gracefully returning sensible data structures when no data is available.

It’s up to you to decide what triggers the Data object to request an update from the server (maybe when the user presses a refresh button or the browser fires an online event) but by not calling the server directly you’re able to locally cache the data more easily.

The Data object must also be able to serialise itself to persistent storage, be that LocalStorage or WebSQL/IndexDB, it should also know how to re-read this serialised form back into memory.

Summary:

1. Use a data controller object to store and schedule updates

2. Make all requests for data via this proxy object

An example

As way of a trivial example, lets consider a contact card viewing application. The first step would be to create a server based API that lets us retrieve the raw contact data. Lets assume we’ve created a RESTful API with a URI /contacts that returns the complete list of contact records. Each record has an id, firstName, lastName & email field.

Next, we write the API object to wrap our actual end point which might look something like:

var API = function() { };

API.prototype.getContacts = function(success, failure) {
    var win = function(data) {
        if(success)
            success(data);
    };

    var fail = function() {
        if(failure)
            failure()
    };

    $.ajax('http://myserver.com/contacts', {
        success: win,
        failure: fail
    });
};

Then we need to write our Data object, which is the interface between our app and the data store. This might look a little like this:

var Data = function() {
    this.api = new API();
    this.contacts = this.readFromStorage();
    this.indexData();
};

Data.prototype.indexData = function() {
    // Do indexing task (e.g. store contact via email)
};

/* -- API Updating -- */

Data.prototype.updateFromServer = function(callback) {
    var _this = this;

    var win = function(data) {
        _this.contacts = data;
        _this.indexData();

        if(callback)
            callback();
    };

    var fail = function() {
        if(callback)
            callback();
    };

    this.api.getContacts(win, fail);
};

/* -- Data serialisation -- */

Data.prototype.readFromStorage = function() {
    var c = JSON.parse(window.localStorage.getItem('appData'));

    // Ensure a sensible default
    return c || [];
};

Data.prototype.writeToStorage = function() {
    window.localStorage.setItem('appData', JSON.stringify(this.contacts));
};

/* -- Standard getters/setters -- */

Data.prototype.getContacts = function() {
    return this.contacts;
};

// App specific data request
Data.prototype.getContactWithEmail = function(email) {
    // Retrieve the contact from our index datastructure
    return contact;
};

We now have a Data object that can be told to update from the API but that by default serves up data that it has stored locally. We then might have the following code elsewhere in our app:

var App = function() {
    this.data = new Data();
    this.template = '...';

    this.render();
    this.setupListeners();
};

App.prototype.render = function() {
    // Use this.template && this.data.getContacts() to render HTML
    return html;
}

App.prototype.setupListeners = function() {
    var _this = this;

    // Reload the data from the server
    $('button.refresh').on('click', function(event) {
        _this.refresh();
    });
};

App.prototype.refresh = function () {
    _this.showLoadingSpinner();

    _this.data.updateFromServer(function() {
        // We've now got new data to show
        _this.render();
        _this.hideLoadingSpinner();
    });
};

App.prototype.showLoadingSpinner = function() {
    // show spinner
};

App.prototype.hideLoadingSpinner = function() {
    // hide spinner
};

The above is a very simple example and in a real app you’d probably want to make sure the Data object was s singleton but it does illustrate how to structure your code to enable offline access out of the box.

Check our the ‘Offline First’ approach in action in FormAgent

This week my company Rareloop launched a preview of a new product FormAgent. For anyone who’s been reading the blog for a while it might seem familiar, in fact its a technology we’ve been developing for a year and powers quite a few of the projects done at Rareloop.

FormAgent is the simplest way to create and distribute forms/surveys to a range of mobile and tablet devices anywhere in the world. It runs on iOS, Android and BlackBerry PlayBook and even works great in areas of low connectivity.

We’re currently in private beta, so head on over to http://formagenthq.com & sign up for an invite code.

FormAgent: Data collection evolved

Take control of your data collection with FormAgent, an online service for creating and distributing surveys to tablets & smartphones anywhere in the world.

Sign up now for the beta @ http://formagenthq.com

Rareloop teamed up with Gamos to deliver a powerful Android based digital survey for the highly respected UK NGO, Tearfund. Gamos have over 20 years experience providing research and detailed evaluation/analysis to the development sector. Given the enormous amounts of data collected and the complex statistical analysis required, partnering with Gamos ensured that both the right technical & research expertise were available to deliver on the project’s needs.

We’ve done work using Android tablets to perform surveys before, but never to this scale. Its also great to get the opportunity to work with NGO’s & know that, even in a small non-direct way, our skill sets can help make a difference.

Head on over to the Rareloop website for more information on the project and our technology platform.

If you’d like a demo of our technology, please don’t hesitate to get in contact.

Our latest app project at Rareloop has been a digital brochure for Southampton based Clinic Beauty.

Written for the BlackBerry PlayBook (using HTML5/WebWorks) the app combines stunning brochure content and Rareloop’s own data collection framework to aid with the companies sales efforts.

Taking cues from their work with HTML5 magazines for tablets, Rareloop created a rich environment for showcasing Clinic Beauty’s work. Transitions and animations bring the content to life and a simple to use mobile optimised form enables data capture from potential clients: elegance and simplicity.

Head on over to the Rareloop website for more information and to see a video of the app in action.

The tutorial I wrote for the January edition of .net mag is now available to read online.

The tutorial shows how to make a page turn effect, similar to the one found in Flux, with JavaScript and CSS3.

Enjoy!

If you haven’t checked out Weinre, you really ought to!

Weinre is a debugger for web pages, like FireBug (for FireFox) and Web Inspector (for WebKit-based browsers), except it’s designed to work remotely, and in particular, to allow you debug web pages on a mobile device such as a phone.

While not as good as a full remote web inspector (like the one found on the PlayBook), its a great tool to help debug with mobile development. Weinre is part of the PhoneGap project and there is a publicly hosted version run as a service that can be found at debug.phonegap.com. Unfortunately the hosted service appears to be having a few problems & I’ve struggled to get local clients to connect, the good news is that Weinre can be installed and run locally.

Weinre was originally written in Java but has recently been ported to Node.js, these instructions will be for installing the Node version.

Install Homebrew

Homebrew is a package manager for the Mac and is what we’ll use to install Node. Full installation instructions can be found here (including the contents of the following script) but to jump right in run the following in Terminal:

/usr/bin/ruby -e "$(/usr/bin/curl -fsSL https://raw.github.com/mxcl/homebrew/master/Library/Contributions/install_homebrew.rb)"

Note: You’ll need XCode installed to be able to get Homebrew working

Install Node.js

Now Homebrew is installed you should be able to get Node by running:

brew install node

Install NPM

NPM is a package manager for Node.js and makes it easier to install/update/remove discrete Node modules. To install run:

git clone http://github.com/isaacs/npm.git
cd npm
sudo make install

Install Weinre

You should now have everything ready to be able to install Weinre, to do so run:

sudo npm -g install weinre

Running Weinre

Now Weinre is installed you can make a start using it locally. First you need to run the server:

weinre

You should now be able to connect to http://localhost:8080 from your desktop web browser. The page displayed will give instructions on usage.

Working with Real Devices

I recently wrote about my setup for testing web apps/sites on real mobile devices. If you’re also using this kind of a setup then you likely want to be able to run Weinre on something other than localhost. This is easily done by providing an additional startup flag. To use the fictional mywebapp.mobiledev.com domain used in aforementioned blog post, you’d simply run:

weinre --boundHost=mywebapp.mobiledev.com

You would then need to point your browser to http://mywebapp.mobiledev.com:8080.

When developing HTML5 web apps for mobiles and tablets, simulators and emulators can only take you so far. The sooner you can test on real devices the sooner you can catch real life usability issues and vendor implementation quirks.

This post outlines a technique for rapidly testing code changes with real devices.

My desktop development setup

For more traditional desktop web apps my development environment is fairly well established. I run a local web server on my laptop (in my case Apache) which mirrors the setup on my deployment server. I have virtual hosts setup and use the /etc/hosts file of my laptop to ensure each virtual host resolves to my local machine.

So to create a new web app I just have to create a new folder in my sites directory, for example mywebapp.home and then create a corresponding record in my hosts file, e.g.

127.0.0.1   mywebapp.home

This works because the hosts file is checked prior to my laptop making a DNS request further up the chain. So anytime an application on my laptop makes a request for mydomain.home, it is resolved to 127.0.0.1 aka localhost.

Making this work for mobiles/tablets

The above works well for testing in multiple desktop browsers (and the iOS Simulator) but for most emulators and on all physical devices it won’t work as the hosts file isn’t able to intercept the DNS requests.

The aim however is still to enable the devices to be able to view the content served from my laptop. Larger businesses may run their own DNS setup locally which would negate this problem but for more agile working environments we need a different solution.

The easiest solution that I’ve found is to setup a single record on a remote DNS server that points to my local IP address. Then instead of using the mydomain.home nomenclature, switch to something that matches the DNS record you created. As an example, if I owned the domain mobiledev.com then I could setup a wildcard DNS A record as follows:

*.mobiledev.com => 192.168.0.4

And the matching folder in my sites directory might be mywebapp.mobiledev.com.

Then, whenever a lookup for a subdomain is made it maps to the IP address for my laptop on the local network. Any device on the same network as my laptop is then able to resolve to the web server on my machine. The crucial caveat here is that you must be on the same network for this to work. You don’t need to open any ports or setup port forwarding on your router, you’re not allowing remote access to your development server, you’re just creating a replacement for your /etc/hosts file that can be read by other devices.

Taking this mobile

You’re more than likely able to setup your home/office network to always issue you with the same IP address, so whenever you’re on your own network the IP address will resolve to the correct machine.

But what if you travel for work or often work in a number of locations?

For this, Dynamic DNS is a great option. My DNS provider (DNS Made Easy) offers this at no extra cost and they make an API available to programatically update your DNS record. Using the API I wrote a little PHP script that I run each time I arrive at a new location/network. The script works out my new local IP address and updates the DNS record accordingly.

If this would also be of you use to you, then you can download the script from GitHub.

Note: Its worth having a fairly short TTL (time to live) value for the dynamic DNS record so that changes propagate quickly. I’ve got mine set to about 3 minutes.

Extras

Once your devices are able to resolve a domain to your development machine you can start to take advantage of some of the other tools that are springing up around mobile web development:

• Weinre (aka PhoneGap Debug)

  “Weinre is a debugger for web pages, like FireBug (for FireFox) and Web Inspector (for WebKit-based browsers), except it’s designed to work remotely, and in particular, to allow you debug web pages on a mobile device such as a phone.” – via docs

  You can download and run it locally or make use of the PhoneGap Debug service to get up and running as quickly as possible.

• Adobe Shadow

  Shadow is a Chrome extension with companion apps for iOS and Android that essentially slaves all connected devices to the current Chrome window. This enables quick page reloading across many mobile devices from your desktop device. It also has a built in version of Weinre.

Flux Slider has placed third in Mozilla’s March Dev Derby, which was all about CSS 3D Transforms! The quality of the competition was incredibly high so its a real honour to place in the top three.

You can see my demo here, but its also really worth checking out some of the other submissions.

Flux is also a ‘Featured Demo‘ at the moment!

Thanks again to the incredible Nick La for letting me use his awesome illustrations.

Sandbox is a subscription only music industry marketing magazine by Music Ally. They’ve just started a regular feature called ‘Rockstar Developers’ and they kindly ask to interview me for the latest edition (issue 58).

So if you have a subscription and fancy hearing my thoughts on mobile development trends for 2012 head on over to the Music Ally website.

Thanks for Sarah Lewin for asking me to take part.