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

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.

The tour was a lot of fun with a lot of great feedback from designers and developers. The main challenge of the event was to fit so much content into a short two-hour session. But it was a good challenge! It forced us to be laser focused, and clearly communicate the essence of each product in 5 to 10 minutes.

Since 5 minutes is also a good length for a video, I thought it would be a good idea to capture that succinct message in a series of screencasts. I posted the first one (Synchronized Browsing and Remote Inspection with Adobe Edge Inspect) last week. Here is the second one: “PhoneGap and PhoneGap Build in 5 minutes”.

A couple of weeks ago, I delivered a full day PhoneGap workshop at QCon San Francisco. The workshop went very well, and I thought the materials could be useful to a larger audience. So I turned the workshop instructions into more detailed tutorial instructions. This is a lot more than the usual Getting Started tutorial: In addition to introducing you to key PhoneGap APIs such as LocalStorage, Database, Notification, Geolocation, Contacts, and Camera, the tutorial focuses on how to architect a real-life PhoneGap application using a Single Page Architecture and HTML templates. Topics include:

• How to use different local data storage strategies.
• How to use several PhoneGap APIs such as Geolocation, Contacts, and Camera.
• How to handle specific mobile problems such as touch events, scrolling, styling, page transitions, etc.
• How to build an application using a single page architecture and HTML templates.
• How to build (compile and package) an application for 6 platforms using PhoneGap Build.

To complete this tutorial, all you need is a code editor, a modern browser, and a connection to the Internet.

The tutorial is available here.

After I published the iOS version on the Apple App Store, a number of people asked for an Android version. I just published it on Google Play.




PhoneGap API Explorer is an API reference application for PhoneGap device integration capabilities. The application clearly presents the syntax for each function, and allows you to provide values for the function’s arguments, invoke the function from within the application, and see immediate results. PhoneGap API Explorer provides a unique and interactive learning experience.

You can read more about the application and watch a video in my initial post about the iOS release.

Source Code

The iOS and the Android versions share the exact same code. Some platform specific CSS styles are dynamically applied through device detection to provide a natural experience on each platform. I will make the source code available on GitHub soon, ready for you to build on PhoneGap Build.

Here are a few more screenshots:

PhoneGap API Explorer itself is of course a PhoneGap application built with Backbone.js and a mix of Twitter Bootstrap and custom skins. Watch a short video here (go full screen for a better viewing experience):

Navigation

This new version introduces a new navigation system described in the following illustration:

In-App Experience

Also new in this version is the ability to provide argument values directly inside the function’s syntax reference, and invoke the function “in context” to see immediate results as shown in the following screenshots:

The goal is not to provide yet another UI framework, but rather to document the basic/raw approach (or different approaches) to implement a specific UI pattern using HTML, CSS, and JavaScript. The code is intentionally simplistic so that it can easily be integrated in your own libraries using your own conventions.

I created a GitHub repository called “mobile-ui-patterns” where I’ll try to publish the patterns I come across in the apps I’m building.

I just pushed a first example of the “Page Swipe” pattern that is pretty common in tablet layouts.

Watch a short video here:

In this implementation, I used the swipe gesture event available in Zepto.js (a lighter weight jQuery compatible DOM library).

In my next post, I will share another version of the same pattern implemented with iScroll and its “snap” feature that provides a slightly different user experience.