The slides are available here.

The Problem

In tightly coupled applications, the presentation logic is intertwined with data access logic (for example, $.ajax() calls), and it leads to some of the problems below:

1. Slows down the development process. Client side developers often have to wait for services to be built. The back and forth between client side and server side development hampers fast iterations.
2. Hard to test. It’s hard to unit test a client application that is hard-wired to server components.
3. Hampers the designer or developer creativity. It can be hard for the designer or client side developer to think creatively about the User Experience if he or she is constrained by a set of pre-existing data services.
4. Hard to change. Changing the data access strategy requires major changes in the client code.
5. Hard to switch the data access strategy on the fly. For example when the application connectivity status changes from online to offline.

The Solution: Pluggable Data Adapters

The solution is of course to decouple the client code from a specific data access strategy. Practically, this goal can be achieved by using pluggable data adapters.

I often start with an in-memory (or mock data) adapter that allows me to iterate quickly at the client side while the server side may not even exist yet. Later on, I can unplug the in-memory adapter and plug in an Ajax adapter to run my application against actual server data, or a WebSQL (or IndexedDB) adapter to run it against an embedded database.

There are many strategies to implement data adapters, and a complete review of these strategies is beyond the scope of this article. Here is a basic approach…

Define a Common Interface

To be interchangeable, your adapters have to expose a common API. Here is a simple example for an Employee Directory use case:

function initialize() {}; // Some adapters may require initialization.  

function findByName(key) {};

function findById(id) {};

Assume Asynchronous

In addition to defining methods with the same name, part of defining a common interface is also to use a common method invocation approach. For example, your in-memory and Ajax adapters wouldn’t be interchangeable if the in-memory adapter assumed synchronous method invocation and the Ajax adapter assumed asynchronous invocation. A good approach is to provide all your adapters with an asynchronous API. Fortunately, Deferred Objects and Promises make it really easy to work with asynchronous operations. There are different implementations of Deferred Objects and Promises. In the example below, we will use the jQuery implementation.

In-Memory Adapter Example

In this adapter, we work with mock data held in a private array. The public API methods return a promise that is resolved immediately (since looping through an array is a synchronous operation).

JSONP Adapter Example

In this adapter, we get the data from RESTful services using JSONP. The $.ajax() method returns a jqXHR object which implements the Promise interface.

The Client Application

Depending on the adapter you want to use, you import either memory-adapter.js or jsonp-adpater.js in index.html. You then instantiate the appropriate adapter on line 16 and you don’t have to change anything else in the application.

Source Code and Additional Adapters

The source code for this simple implementation of data adapters is available in this GitHub repository. The repository includes the following adapters:

• In-Memory Adapter
• LocalStorage Adapter
• WebSQL Adapter
• JSONP Adapter

A couple of days ago, I shared a new version of the Employee Directory sample application. By default, the application uses an in-memory data store to provide a “download and run” experience (no need to set up a server or a database). In this post, I’ll show how to replace the in-memory data store with a database hosted on Parse.com.

Step 1: Sign Up for Parse.com

Go to http://parse.com and sign up for Parse.

Step 2: Create an Application

On the next screen, create an application as follows:

Step 3: Get your Application Keys

In the dashboard, go to Settings and grab the Application ID and the JavaScript key.

Step 4: Populate the Database

There are two ways to populate the database:

1. Import a .json, .csv, .xls, or .txt file from the Data Browser interface. This approach works well for simple data structures.
2. Programmatically, using the the Parse SDK.

For the employee directory application I wrote the quick script below to populate the database:

Step 5: Run the Employee Directory App using the Parse.com Cloud Data

1. Download the source code for the Employee Directory client application available in this repository.
2. Extract the application files to a directory you can reach using a local or hosted web server.
   
   Because the templates of this application are loaded using XMLHTTPRequest, you will get a cross domain error (Access-Control-Allow-Origin) if you load index.html from the file system (with the file:// protocol). Make sure you load the application from a web server. For example: http://localhost/directory-backbone-bootstrap.
   
3. Open index.html in your code editor.
4. Comment out the “model-in-memory.js” script, and uncomment the “parse-1.2.2.min.js” and “model-parse-com.js” scripts.
5. Open index.html in a Browser and test the application.

Step 6: Secure the Database

Parse.com offers different security options. A complete discussion of these options is beyond the scope of this article. Since Employee Directory is a read-only and public application, we will simply:

1. Prevent client class creation (In Settings > General Settings):

2. Disable create, update, delete operations (In Data Browser > More > Set Permissions):

Step 1: Install Node.js

If it’s not already installed on your system, follow the steps below to install Node.js:

1. Go to http://nodejs.org, and click the Install button.
2. Run the installer that you just downloaded. When the installer completes, a message indicates that Node was installed at /usr/local/bin/node and npm was installed at /usr/local/bin/npm. At this point node.js is ready to use.

Step 2: Install MongoDB

If MongoDB is not already installed on your system, refer to the MongoDB QuickStart for platform-specific installation instructions. Here are some quick steps to install MongoDB on a Mac:

1. Go to http://www.mongodb.org/downloads and download the latest OS X 64-bit production release (2.4.2 at the time of this writing).
2. In Finder, double-click mongodb-osx-x86_64-2.4.2.tgz to extract its contents. (Alternatively you can use: tar -zxvf mongodb-osx-x86_64-2.4.2.tgz)
3. Move the mongodb-osx-x86_64-2.4.2 folder to /usr/local (or another folder according to your personal preferences):

   sudo mv -n mongodb-osx-x86_64-2.4.2/ /usr/local/
   

4. (Optional) Create a symbolic link to make it easier to access:

   sudo ln -s /usr/local/mongodb-osx-x86_64-2.4.2 /usr/local/mongodb
   

5. Create a folder for MongoDB’s data and set the appropriate permissions:

   sudo mkdir -p /data/db
   sudo chown `id -u` /data/db
   

6. Start mongodb

   cd /usr/local/mongodb
   ./bin/mongod
   

Step 3: Download the Code

The Node.js code for the Employee Directory RESTful services is available in this GitHub repository. Download it here and unzip the file anywhere on your file system.

Open server.js and routes/employee.js in a code editor. The RESTFul API is defined as follows:

Step 4: Install dependencies (Express Framework and MongoDB driver)

Open package.json in a code editor and note that the application has two dependencies: the Express framework and the MongoDB driver. To install these dependencies, open a command line (terminal window), cd to the directory where you extracted the source code, and type:

npm install

Step 5: Start the server

Make sure MongoDB is started (Step 2 point 6 above) before you start your Node.js server as follows:

node server.js

Step 6: Testing the API in your Browser

• Retrieve all employees

  http://localhost:3000/employees

• Retrieve all employees whose name includes the letter “j”

  http://localhost:3000/employees?name=j

• Retrieve employee with id == 1

  http://localhost:3000/employees/1

• Retrieve employees that are direct reports of employee number 1

  http://localhost:3000/employees/1/reports

Step 7: Test the API with the Employee Directory Client Application

1. Download the source code for the Employee Directory client application available in this repository.
2. Unzip the file anywhere on your file system.
3. Open index.html in your code editor.
4. Comment out the “model-in-memory.js” script, and uncomment the “model-jsonp.js” script to use the JSONP adapter that connects to your Node.js server.
5. Make sure the MongoDB and Node.js servers are started
6. Open index.html in a Browser and test the application

Related Post

Check out this post for another Node.js example with a more complete RESTful API including the ability to add, modify and delete items (POST, PUT, and DELETE HTTP methods).

A year ago, I blogged Employee Directory, a sample application that demonstrates how to build modern web apps with Backbone.js and Twitter Bootstrap. With 1200+ stars and 300+ forks on GitHub, it has been my most popular sample application to date.

Because of the continued interest in the application as a starting point and a reference for Backbone.js and Twitter Bootstrap, I decided to give it a well deserved update.

New in this version:

• Latest version of Backbone.js (1.0)
• Latest version of Twitter Bootstrap (2.3.1)
• Layout is now responsive
• Data persistence layer is now abstracted (see below)
• Additional data persistence options: In-memory datastore, Node.js/MongoDB, Parse.com (In addition to PHP and Java)
• New GitHub repository organization (see below)
• Bug fixes and cleaner code

Running the Application

You can test the hosted version of the application here, or you can download the code (see GitHub repository information below) and test the application locally.

Data Persistence Abstraction

Among the great feedback I received, a number of you mentioned you wanted a self-contained version of the app with no dependency on a specific back end to be able to “download and run” without having to set up a server and a database. So I rearchitected the persistence layer with simple and pluggable data adapters. By default the application now uses an in-memory data store, but other adapters are available. To change the data persistence strategy, just comment out model-in-memory.js in index.html and uncomment one of the other data adapters using the table below as a reference.

I initially published the application with two implementations of a RESTful back end: A Java version using Jersey, and a PHP version using Slim. A year later, I’m adding the long overdue Node.js/MongoDB back end.

The Node.js, Java, and PHP RESTful back ends work with both JSON and JSONP. If the request includes a query parameter named “callback”, a JSONP response is returned, otherwise, a regular JSON response is returned.

New GitHub Repositories

The original repository (backbone-directory) grew somewhat chaotically as I kept adding different versions and different data persistence options. So I decided to start fresh with new repositories.

The client code for the application is available in the new directory-backbone-bootstrap repository. In the future, this new repository naming scheme will allow me to add different versions of the app (for example, directory-backbone-foundation or directory-angular-bootstrap) while keeping each repository clean and focused.

If you want to go beyond the in-memory datastore, you can download the REST services in the following repositories:

directory-rest-nodejs (Node.js/MongoDB implementation)
directory-rest-php (PHP implementation)
directory-rest-java (Java implementation coming soon)

Specifically, the application demonstrates:

• How to login and request permisssions
• How to access your profile, friends, and feed
• How to access a list of friends
• How to access a friend’s profile, friends, mutual friends, and feed
• How to post a message to your feed using a custom UI or using the Facebook native dialogs
• How to revoke the permissions granted to the application (useful during development)

Here are a few screenshots:

Source Code

The source code is available in this GitHub repository. This is still work in progress and I’ve only tested the app on iOS at this point. I’ll continue to update the code: there are things that can be polished and things that can be added.

Libraries

The application is buil using the following libraries:

• The Facebook plugin for PhoneGap
• Backbone.js
• Ratchet
• Fastclick
• jQuery
• PageSlider

These dependencies (except the first one) can easily be removed to work with your own stack.

Basic Infrastructure

Here is a typical set up for sliding pages in an out of the viewport in a mobile app:

The white box in the middle represents the browser viewport (the window through which the visible part of the document is seen): that is where the current page of your app is displayed at the full (100%) width and height of the viewport.

A page can be positioned to the left or to the right of the viewport by setting its “x” coordinate to -100% or 100% respectively (100% representing the viewport width). This can be done using two different approaches as explained below.

To slide a page from the right, you would:

1. Position the page at the starting position of the transition (right)
2. If needed, force a reflow to anchor the page at its starting position.
3. Finally, position the page at the ending position of the transition (center) with the transition-duration style added to the page to indicate that it should be animated to that new position (see style definitions below).

var homePage = document.getElementById("homePage"),
    newPage = document.getElementById("newPage");
// Position the page at the starting position of the animation
newPage.className = "page right";
// Position page at ending position of animation and add transition-duration
newPage.className ="page transition center";
// Simultaneously slide out the current page to the left of the viewport
homePage.className = "page transition left";

And here are two versions of the accompanying CSS: the first version will not hardware accelerate the transition; the second one will.

Non hardware accelerated transition:

Adding transform: translate3d(0,0,0); to the page will hardware accelerate the actual composition (drawing of the element on top of the background). However, it will not hardware accelerate the transition: The “left” property cannot be hardware accelerated. Changing the “left” property will force a layout every time the property changes (every frame).

.page {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    -webkit-transform: translate3d(0, 0, 0);
    transform: translate3d(0, 0, 0);
}

.page.left {
    left: -100%;
}

.page.center {
    left: 0;
}

.page.right {
    left: 100%;
}

.page.transition {
    -webkit-transition-duration: .25s;
    transition-duration: .25s;
}

Hardware accelerated transition:

To hardware accelerate the transition, apply a 3D transform to the page’s x coordinate instead of changing the value of the left property. The version of the style sheet below should hardware accelerate both the actual composition (drawing of the page) and the transition.

.page {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    -webkit-transform: translate3d(0, 0, 0);
    transform: translate3d(0, 0, 0);
}

.page.left {
    -webkit-transform: translate3d(-100%, 0, 0);
    transform: translate3d(-100%, 0, 0);
}

.page.center {
    -webkit-transform: translate3d(0, 0, 0);
    transform: translate3d(0, 0, 0);
}

.page.right {
    -webkit-transform: translate3d(100%, 0, 0);
    transform: translate3d(100%, 0, 0);
}

.page.transition {
    -webkit-transition-duration: .25s;
    transition-duration: .25s;
}

Try the simple example below. The code is self-contained in simplepageslider.html. Right-click the sample and select “View Frame Source” to check it out.

PageSlider.js: A Micro Library for Simple Page Transitions

In a real-life application, you will typically want to generalize the process a little bit. For example, you could:

• Automatically add new pages to the DOM and remove them from the DOM after they are animated out of the viewport.
• Automatically determine the sliding direction based on the page history.
• Provide a hook (using the webkitTransitionEnd event) for adding some logic when the transition completes.

I isolated that logic in pageslider.js, an example of a micro library you could use to provide hardware accelerated page transitions in your mobile apps.

Try the example below, or try it fullscreen here.

Source Code

The pageslider.js source code is available in this GitHub repository.

I will be delivering a talk titled “Modern Tools for the Modern Web” at Skillsmatter in London tonight (Wednesday March 6th) at 6:30pm. It’s free and open to all. Simply register here.

I’ll be going over the new Edge Tools and Services (Edge Animate, Edge Reflow, Edge Inspect, Edge Code, PhoneGap and PhoneGap Build, etc), and discuss how they can be used to build modern content and applications. The Edge Tools and Services are all part of the Creative Cloud.

I hope to see you there if you are in the London area!

Christophe

Detailed abstract:

The next generation of HTML and CSS offer powerful new features for creating graphically rich content and applications. In this session, Christophe will discuss the latest trends of the modern web, and introduce the Adobe Edge Tools: a unique set of tools and services that help designers and developers create content and applications that leverage modern web technologies.

The topics discussed will include:

• Latest trends of the modern web and Adobe recent contributions to web standards
• Edge Reflow: A new tool laser focused on Responsive Web Design (RWD)
• Edge Animate: A new tool that lets you create interactive and animated content using HTML, CSS, and JavaScript
• PhoneGap and PhoneGap Build: An open source solution for building cross-platform mobile apps with standard-based Web technologies, and a cloud-based build service that lets you build and package your application for six different platforms.
• Edge Inspect: A new tool that lets you remotely visualize, inspect, test and debug your HTML content and applications on dozens of mobile devices at the same time.
• Edge Code: A code editor for HTML, JavaScript and CSS built with HTML, JavaScript and CSS.

I’m excited to be speaking at QCon London again this year. The conference is next week, from Wednesday March 6th to Friday March 8th. As always at QCon, the sessions and the speaker lineup look great. I will be speaking in the “Next Generation Mobile Apps” track on Thursday. This year I’ll go well beyond the PhoneGap basics and focus on Architecting PhoneGap Applications. There are many other inspiring tracks and sessions.

I know this is last minute, but if you are interested in attending the conference, you can save £100 off the registration fee by using the promotion code COEN100. Hope to see some of you there!