.png)
Building Mobile JavaScript WebApps With Backbone.js & jQuery: Part I
Addy Osmani | August 4, 2011
Welcome to Part 1 of a two-part tutorial on building complete mobile web applications in JavaScript using DocumentCloud's Backbone.js, jQuery Mobile and LABjs.
In Part 1, I'll be covering a complete run-down of Backbone 0.5.2's models, views, collections and routers but also taking you through options for correctly namespacing your Backbone application. I'll also give you some tips including what scaffolding tool that can save time setting up your initial application, the ideal number of routers to use and more.
We'll then build a testable wireframe of our application in jQuery Mobile before we complete building it in Part 2.
Why is this two-part tutorial different from others?
Developers that have attempted to work with Backbone.js and jQuery Mobile in the past will be aware that both solutions have their own approaches to handing routing.
Unfortunately, there are often a number of hacks and workarounds required to get them functioning in unison. I've experienced developers going so far as to edit the jQuery Mobile source to achieve this which is actually unnecessary. In Part 2, you'll find out how to use some (currently undocumented) jQuery Mobile features to solve this issue without resorting to such lengths, so you can spend more time working on your actual application logic.
I'm hopeful there will be something in the tutorial to benefit developers of all skill-levels, so on that note, let's get started!
What is Backbone?
Backbone.js is one of a number of JavaScript frameworks for creating MVC-like web applications. On the front-end, it's my architectural framework of choice as it's both mature, relatively lightweight and can be easily tested using third-party toolkits such as Jasmine or QUnit. Other MVC options you may be familiar with include SproutCore 2.0, Spine and JavaScriptMVC.
Backbone is maintained by a number of contributors, most notably: Jeremy Ashkenas, creator of CoffeeScript, Docco and Underscore.js. As Jeremy is a believer in detailed documentation, there's a level of comfort in knowing you're unlikely to run into issues which are either not explained in the official docs or which can't be nailed down with some assistance from the #documentcloud IRC channel. I strongly recommend using the latter if you find yourself getting stuck.
Why should you consider using Backbone?
Backbone's main benefits, regardless of your target platform or device, include helping:
- Organize the structure to your application
- Simplify server-side persistence
- Decouple the DOM from your page's data
- Model data, views and routers in a succinct manner
- Provide DOM, model and collection syncronization
In ways, the real question is why you should consider applying the MVC-pattern to your JavaScript projects and the one word answer is simply structure.
If opting to use jQuery, zepto or another qSA-based selection library to produce a non-trivial application it can become very easy to produce an unwieldy amount of code; that is - unless you have a plan for how you're going to structure and organize your application. Separating concerns into models, views and controllers (or routers) is one way of solving this.
Remember that if you have experience with structuring applications using the MVVM (Model-View ViewModel) pattern, modules or otherwise, these are also equally as valid but do require you to know what you're doing. For most single-page applications, I find that the MVC pattern works well so Backbone is a perfect fit for our needs.
Understanding Backbone.js
In this section, you'll learn the essentials about Backbone's models, views, collections and routers. Whilst this isn't meant as a replacement for the official documentation, it will help you understand many of the core concepts behind Backbone before we build mobile applications with it. I will also be covering some tips on effective namespacing.
- Models
- Collections
- Routers
- Views
- Namespacing
Models
Backbone models contain interactive data for an application as well as the logic around this data. For example, we can use a model to represent the concept of a photo object including its attributes like tags, titles and a location.
Models are quite straight-forward to create and can be constructed by extending
Backbone.Model as follows:
Photo = Backbone.Model.extend({
defaults: {
src: 'placeholder.jpg',
title: 'an image placeholder,
coordinates: [0,0]
},
initialize: function(){
this.bind("change:src", function(){
var src = this.get("src");
console.log('Image source updated to ' + src)
});
},
changeSrc: function( source ){
this.set({ src: source });
}
});
var somePhoto = new Photo({ src: "test.jpg", title:"testing"});
Initialization
The initialize() method is called when creating a new instance of a model. It's considered optional, however we'll be reviewing some reasons it might come in useful very shortly.
Photo = new Backbone.Model.extend({
initialize: function(){
console.log('this model has been initialized');
}
});
/*We can then create our own instance of a photo as follows:*/
var myPhoto = new Photo;
Getters & Setters
Model.get()
Model.get() provides easy access to a model's attributes. Attributes below which are passed through to the model on instantiation are then instantly available for retrieval.
var myPhoto = new Photo({ title: "My awesome photo",
src:"boston.jpg",
location: "Boston",
tags:['the big game', 'vacation']}),
title = myPhoto.get("title"), //my awesome photo
location = myPhoto.get("location"), //Boston
tags = myPhoto.get("tags"), // ['the big game','vacation']
photoSrc = myPhoto.get("src"); //boston.jpg
Alternatively, if you wish to directly access all of the attributes in an model's instance directly, you can achieve this as follows:
var myAttributes = myPhoto.attributes;
console.log(myAttributes);
Note: It is best practice to use Model.set() or direct instantiation to set the values of a model's attributes. Accessing Model.attributes directly is fine for reading or cloning data, but ideally shouldn't be used to for attribute manipulation.
Finally, if you would like to copy a model's attributes for JSON stringification (e.g. for serialization prior to being passed to a view), this can be achieved using Model.toJSON():
var myAttributes = myPhoto.toJSON();
console.log(myAttributes);
/* this returns { title: "My awesome photo",
src:"boston.jpg",
location: "Boston",
tags:['the big game', 'vacation']}*/
Model.set()
Model.set() allows us to pass parameters into an instance of our model. Attributes can either be set during initialization or later on.
Photo = new Backbone.Model.extend({
initialize: function(){
console.log('this model has been initialized');
}
});
/*Setting the value of attributes via instantiation*/
var myPhoto = new Photo({ title: 'My awesome photo', location: 'Boston' });
var myPhoto2 = new Photo();
/*Setting the value of attributes through Model.set()*/
myPhoto2.set({ title:'Vacation in Florida', location: 'Florida' });
Default values
There are times when you want your model to have a set of default values (e.g. in scenario where a complete set of data isn't provided by the user). This can be set using a property called 'defaults' in your model.
Photo = new Backbone.Model.extend({
defaults:{
title: 'Another photo!',
tags: ['untagged'],
location: 'home',
src: 'placeholder.jpg'
},
initialize: function(){
}
});
var myPhoto = new Photo({ location: "Boston",
tags:['the big game', 'vacation']}),
title = myPhoto.get("title"), //Another photo!
location = myPhoto.get("location"), //Boston
tags = myPhoto.get("tags"), // ['the big game','vacation']
photoSrc = myPhoto.get("src"); //placeholder.jpg
Listening for changes to your model
Any and all of the attributes in a Backbone model can have listeners bound to them which detect when their values change. This can be easily added to the initialize() function as follows:
this.bind('change', function(){
console.log('values for this model have changed');
});
In the following example, we can also log a message whenever a specific attribute (the title of our Photo model) is altered.
Photo = new Backbone.Model.extend({
defaults:{
title: 'Another photo!',
tags: ['untagged'],
location: 'home',
src: 'placeholder.jpg'
},
initialize: function(){
console.log('this model has been initialized');
this.bind("change:title", function(){
var title = this.get("title");
console.log("My title has been changed to.." + title);
});
},
setTitle: function(newTitle){
this.set({ title: newTitle });
}
});
var myPhoto = new Photo({ title "Fishing at the lake", src:"fishing.jpg")});
myPhoto.setTitle('Fishing at sea');
//logs my title has been changed to.. Fishing at sea
Validation
Backbone supports model validation through Model.validate(), which allows checking the attribute values for a model prior to them being set.
It supports including as complex or terse validation rules against attributes and is quite straight-forward to use. If the attributes provided are valid, nothing should be returned from .validate(), however if they are invalid a custom error can be returned instead.
A basic example for validation can be seen below:
Photo = new Backbone.Model.extend({
validate: function(attribs){
if(attribs.src == "placeholder.jpg"){
return "Remember to set a source for your image!";
}
},
initialize: function(){
console.log('this model has been initialized');
this.bind("error", function(model, error){
console.log(error);
});
}
});
var myPhoto = new Photo();
myPhoto.set({ title: "On the beach" });
Collections
Collections are basically sets of models and can be easily created by extending Backbone.Collection.
Normally, when creating a collection you'll also want to pass through a property specifying the model that your collection will contain as well as any instance properties required.
In the following example, we're creating a PhotoCollection containing the Photo models we previously defined.
PhotoCollection = Backbone.Collection.extend({
model: Photo
});
Getters and Setters
There are a few different options for retrieving a model from a collection. The most straight-forward is using Collection.get() which accepts a single id as follows:
var skiingEpicness = PhotoCollection.get(2);
Sometimes you may also want get a model based on something called the client id. This is an id that is internally assigned automatically when creating models that have not yet been saved, should you need to reference them. You can find out what a model's client id is by accessing its .cid property.
var mySkiingCrash = PhotoCollection.getByCid(456);
Backbone Collections don't have setters as such, but do support adding new models via .add() and removing models via .remove().
var a = new Backbone.Model({ title: 'my vacation'}),
b = new Backbone.Model({ title: 'my holiday'});
var photoCollection = new Backbone.Collection([a,b]);
photoCollection.remove([a,b]);
Listening for events
As collections represent a group of items, we're also able to listen for add and remove events for when new models are added or removed from the collection. Here's an example:
PhotoCollection = new Backbone.Collection;
PhotoCollection.bind("add", function(photo) {
console.log("I liked " + photo.get("title") + ' its this one, right? ' + photo.src);
});
PhotoCollection.add([
{title: "My trip to Bali", src: "bali-trip.jpg"},
{title: "The flight home", src: "long-flight-oofta.jpg"},
{title: "Uploading pix", src: "too-many-pics.jpg"}
]);
In addition, we're able to bind a 'change' event to listen for changes to models in the collection.
PhotoCollection.bind("change:title", function(){
console.log('there have been updates made to this collections titles');
});
Fetching models from the server
Collections.fetch() provides you with a simple way to fetch a default set of models from the server in the form of a JSON array. When this data returns, the current collection will refresh.
var PhotoCollection = new Backbone.Collection;
PhotoCollection.url = '/photos';
PhotoCollection.fetch();
Under the covers, Backbone.sync is the function called every time Backbone tries to read (or save) models to the server. It uses jQuery or Zepto's ajax implementations to make these RESTful requests, however this can be overridden as per your needs.
In the above fetch example if we wish to log an event when .sync() gets called, we can simply achieve this as follows:
Backbone.sync = function(method, model) {
console.log("I've been passed " + method + " with " + JSON.stringify(model));
};
Resetting/Refreshing Collections
Rather than adding or removing models individually, you occasionally wish to update an entire collection at once. Collection.reset() allows us to replace an entire collection with new models as follows:
PhotoCollection.reset([
{title: "My trip to Scotland", src: "scotland-trip.jpg"},
{title: "The flight from Scotland", src: "long-flight.jpg"},
{title: "Latest snap of lock-ness", src: "lockness.jpg"}]);
Underscore utility functions
As Backbone requires Underscore as a hard dependency, we're able to use many of the utilities it has to offer to aid with our application development. Here's an example of how Underscore's sortBy() method can be used to sort a collection of photos based on a particular attribute.
var sortedByAlphabet = PhotoCollection.sortBy(function(photo)){
return photo.get("title").toLowerCase();
});
The complete list of what it can do is beyond the scope of this guide, but can be found in the official docs.
Routers
In Backbone, routers are used to handle routing for your application. This is achieved using hash-tags with URL fragments which you can read more about if you wish. Some examples of valid routes may be seen below:
- http://unicorns.com/#/whatsup
- http://unicorns.com/#/search/seasonal-horns/page2
Note: A router will usually have at least one URL route defined as well as a function that maps what happens when you reach that particular route. This type of key/value pair may resemble:
"/route" : "mappedFunction"
Let us now define our first controller by extending Backbone.Router. For the purposes of this guide, we're going to continue pretending we're creating a photo gallery application that requires a GalleryController.
Note the inline comments in the code example below as they continue the rest of the lesson on routers.
GalleryController = Backbone.Router.extend({
/* define the route and function maps for this controller */
routes:{
"/about" : "showAbout",
/*Sample usage: http://unicorns.com/#/about"*/
"/photos/:id" : "getPhoto",
/*This is an example of using a ":param" variable which allows us to match
any of the components between two URL slashes*/
/*Sample usage: http://unicorns.com/#/photos/5*/
"/search/:query" : "searchPhotos"
/*We can also define multiple routes that are bound to the same map function,
in this case searchPhotos(). Note below how we're optionally passing in a
reference to a page number if one is supplied*/
/*Sample usage: http://unicorns.com/#/search/lolcats*/
"/search/:query/p:page" : "searchPhotos",
/*As we can see, URLs may contain as many ":param"s as we wish*/
/*Sample usage: http://unicorns.com/#/search/lolcats/p1*/
"/photos/:id/download/*imagePath" : "downloadPhoto",
/*This is an example of using a *splat. splats are able to match any number of
URL components and can be combined with ":param"s*/
/*Sample usage: http://unicorns.com/#/photos/5/download/files/lolcat-car.jpg*/
/*If you wish to use splats for anything beyond default routing, it's probably a good
idea to leave them at the end of a URL otherwise you may need to apply regular
expression parsing on your fragment*/
"*other" : "defaultRoute"
//This is a default route with that also uses a *splat. Consider the
//default route a wildcard for URLs that are either not matched or where
//the user has incorrectly typed in a route path manually
/*Sample usage: http://unicorns.com/#/anything*/
},
showAbout: function(){
},
getPhoto: function(id){
/*
in this case, the id matched in the above route will be passed through
to our function getPhoto and we can then use this as we please.
*/
console.log("You are trying to reach photo " + id);
},
searchPhotos: function(query, page){
console.log("Page number: " + page + " of the results for " + query);
},
downloadPhoto: function(id, path){
},
defaultRoute(other){
console.log("Invalid. You attempted to reach:" + other);
}
});
/* Now that we have a controller setup, remember to instantiate it*/
var myGalleryController = new GalleryController;
Note: In Backbone 0.5+, it's possible to opt-in for HTML5 pushState support via window.history.pushState. This effectively permits non-hashtag routes such as http://www.scriptjunkie.com/just/an/example to be supported with automatic degradation should your browser not support it. For the purposes of this tutorial, we won't be relying on this newer functionality as there have been reports about issues with it under iOS/Mobile Safari. Backbone's hash-based routes should however suffice for our needs.
Backbone.history
Next, we need to initialize Backbone.history as it handles hashchange events in our application. This will automatically handle routes that have been defined and trigger callbacks when they've been accessed.
The Backbone.history.start() method will simply tell Backbone that it's OK to begin monitoring all hashchange events as follows:
Backbone.history.start();
Controller.saveLocation()
As an aside, if you would like to save application state to the URL at a particular point you can use the .saveLocation() method to achieve this. It simply updates your URL fragment without the need to trigger the hashchange event.
/*Lets imagine we would like a specific fragment for when a user zooms into a photo*/
zoomPhoto: function(factor){
this.zoom(factor); //imagine this zooms into the image
this.saveLocation("zoom/" + factor); //updates the fragment for us
}
Views
Views in Backbone don't contain the markup for your application, but rather are there to support models by defining how they should be visually represented to the user. This is usually achieved using JavaScript templating (e.g. Mustache, jQuery tmpl etc). When a model updates, rather than the entire page needing to be refreshed, we can simply bind a view's render() function to a model's change() event, allowing the view to always be up to date.
Creating new views
Similar to the previous sections, creating a new view is relatively straight-forward. We simply extend Backbone.View. Here's an example of a one possible implementation of this, which I'll explain shortly:
var PhotoSearch = Backbone.View.extend({
el: $('#results'),
render: function( event ){
var compiled_template = _.template( $("#results-template").html());
this.el.html( compiled_template(this.model.toJSON()) );
return this; //recommended as this enables calls to be chained.
},
events: {
"submit #searchForm': "search",
"click .reset': "reset",
"click .advanced": 'switchContext"
},
search: function( event ){
//executed when a form '#searchForm' has been submitted
},
reset: function( event ){
//executed when an element with class "go" has been clicked.
},
//etc
});
What is 'el'?
el is basically a reference to a DOM element and all views must have one, however Backbone allows you to specify this in four different ways. You can either directly use an id, a tagName, className or if you don't state anything el will simply default to a plain div element without any id or class. Here are some quick examples of how these may be used:
el: $('#results') //select based on ID or jQuery selector.
tagName: 'li' //select based on a specific tag. Here el itself will be derived from the tagName
className: 'items' //similar to the above, this will also result in el being derived from it
el: '' //defaults to a div without an id, name or class.
Understanding render()
render() is a function that should always be overridden to define how you would like a template to be rendered. Backbone allows you to use any JavaScript templating solution of your choice for this but for the purposes of this example, we'll opt for underscore's micro-templating.
The _.template method in underscore compiles JavaScript templates into functions which can be evaluated for rendering. Here, I'm passing the markup from a template with id 'results-template' to be compiled. Next, I set the html for el (our DOM element for this view) the output of processing a JSON version of the model associated with the view through the compiled template.
Presto! This populates the template, giving you a data-complete set of markup in just a few short lines of code.
The 'events' attribute
The Backbone events attribute allows us to attach event listeners to either custom selectors or el if no selector is provided. An event takes the form {"eventName selector": "callbackFunction"} and a number of event-types are supported, including 'click', 'submit', 'mouseover', 'dblclick' and more.
What isn't instantly obvious is that under the bonnet, Backbone uses jQuery's .delegate() to provide instant support for event delegation but goes a little further, extending it so that 'this' always refers to the current view object. The only thing to really keep in mind is that any string callback supplied to the events attribute must have a corresponding function with the same name within the scope of your view otherwise you may incur exceptions.
Namespacing
When learning how to use Backbone, one important area that that is very commonly overlooked in tutorials is namespacing. If you already have experience with how to namespace in JavaScript, the following section will provide some advice on how to specifically apply concepts you know to Backbone, however I will also be covering explanations for beginners to ensure everyone is on the same page.
What is namespacing?
The basic idea around namespacing is to avoid collisions with other objects or variables in the global namespace. They're important as it's best to safeguard your code from breaking in the event of another script on the page using the same variable names as you are. As a good 'citizen' of the global namespace, it's also imperative that you do your best to similarly not prevent other developer's scripts executing due to the same issues.
JavaScript doesn't really have built-in support for namespaces like other languages, however it does have closures which can be used to achieve a similar effect.
In this section we'll be taking a look shortly at some examples of how you can namespace your models, views, routers and other components specifically. The patterns we'll be examining are:
- Single global variables
- Object literals
- Nested namespacing
Single global variables
One popular pattern for namespacing in JavaScript is opting for a single global variable as your primary object of reference. A skeleton implementation of this where we return an object with functions and properties can be found below:
var myApplication = (function(){
function(){
...
},
return{
...
}
})();
which you're likely to have seen before. A Backbone-specific example which may be more useful is:
var myViews = (function(){
return {
PhotoView: Backbone.View.extend({ .. }),
GalleryView: Backbone.View.extend({ .. }),
AboutView: Backbone.View.extend({ .. });
//etc.
};
})();
Here we can return a set of views or even an entire collection of models, views and routers depending on how you decide to structure your application. Although this works for certain situations, the biggest challenge with the single global variable pattern is ensuring that no one else has used the same global variable name as you have in the page.
One solution to this problem, as mentioned by Peter Michaux, is to use prefix namespacing. It's a simple concept at heart, but the idea is you select a basic prefix namespace you wish to use (in this example, myApplication_) and then define any methods, variables or other objects after the prefix.
var myApplication_photoView = Backbone.View.extend({}),
myApplication_galleryView = Backbone.View.extend({});
This is effective from the perspective of trying to lower the chances of a particular variable existing in the global scope, but remember that a uniquely named object can have the same effect. This aside, the biggest issue with the pattern is that it can result in a large number of global objects once your application starts to grow.
For more on Peter's views about the single global variable pattern, read his excellent post on them here: http://michaux.ca/articles/javascript-namespacing
Note: There are several other variations on the single global variable pattern out in the wild, however having reviewed quite a few, I felt these applied best to Backbone.
Object literals
Object literals have the advantage of not polluting the global namespace but assist in organizing code and parameters logically. They're beneficial if you wish to create easily-readable structures that can be expanded to support deep nesting. Unlike simple global variables, object literals often also take into account tests for the existence of a variable by the same name so the chances of collision occurring are significantly reduced.
The code at the very top of the next sample demonstrates the different ways in which you can check to see if a namespace already exists before defining it. I commonly use Option 3.
/*Doesn't check for existence of myApplication*/
var myApplication = {};
/*
Does check for existence. If already defined, we use that instance.
Option 1: if(!MyApplication) MyApplication = {};
Option 2: var myApplication = myApplication = myApplication || {}
Option 3: var myApplication = myApplication || {};
We can then populate our object literal to support models, views and collections (or any data, really):
*/
var myApplication = {
models : {},
views : {
pages : {}
},
collections : {}
};
One can also opt for adding properties directly to the namespace (such as your views, in the following example):
var myGalleryViews = myGalleryViews || {};
myGalleryViews.photoView = Backbone.View.extend({});
myGalleryViews.galleryView = Backbone.View.extend({});
The benefit of this pattern is that you're able to easily encapsulate all of your models, views, routers etc. in a way that clearly separates them and provides a solid foundation for extending your code.
This pattern has a number of useful applications. It's often of benefit to decouple the default configuration for your application into a single area that can be easily modified without the need to search through your entire codebase just to alter them - object literals work great for this purpose. Here's an example of a hypothetical object literal for configuration:
var myConfig = {
language: 'english',
defaults: {
enableGeolocation: true,
enableSharing: false,
maxPhotos: 20
},
theme: {
skin: 'a',
toolbars: {
index: 'ui-navigation-toolbar',
pages: 'ui-custom-toolbar'
}
}
}
Note that there are really only minor syntactical differences between the object literal pattern and a standard JSON data set. If for any reason you wish to use JSON for storing your configurations instead (e.g. for simpler storage when sending to the back-end), feel free to.
For more on the object literal pattern, I recommend reading Rebecca Murphey's excellent article on the topic.
Nested namespacing
An extension of the object literal pattern is nested namespacing. It's another common pattern used that offers a lower risk of collision due to the fact that even if a namespace already exists, it's unlikely the same nested children do.
Does this look familiar?
YAHOO.util.Dom.getElementsByClassName('test');
Yahoo's YUI uses the nested object namespacing pattern regularly and even DocumentCloud (the creators of Backbone) use the nested namespacing pattern in their main applications. A sample implementation of nested namespacing with Backbone may look like this:
var galleryApp = galleryApp || {};
/*perform similar check for nested children*/
galleryApp.routers = galleryApp.routers || {};
galleryApp.model = galleryApp.model || {};
galleryApp.model.special = galleryApp.model.special || {};
/*routers*/
galleryApp.routers.Workspace = Backbone.Router.extend({});
galleryApp.routers.PhotoSearch = Backbone.Router.extend({});
/*models*/
galleryApp.model.Photo = Backbone.Model.extend({});
galleryApp.model.Comment = Backbone.Model.extend({});
/*special models*/
galleryApp.model.special.Admin = Backbone.Model.extend({});
This is both readable, organized and is a relatively safe way of namespacing your Backbone application in a similar fashion to what you may be used to in other languages.
The only real caveat however is that it requires your browser's JavaScript engine first locating the galleryApp object and then digging down until it gets to the function you actually wish to use.
This can mean an increased amount of work to perform lookups, however developers such as Juriy Zaytsev (kangax) have previously tested and found the performance differences between single object namespacing vs the 'nested' approach to be quite negligible.
Recommendation
Reviewing the namespace patterns above, the option that I would personally use with Backbone is nested object namespacing with the object literal pattern.
Single global variables may work fine for applications that are relatively trivial, however, larger codebases requiring both namespaces and deep sub-namespaces require a succinct solution that promotes readability and scales. I feel this pattern achieves all of these objectives well and is a perfect companion for Backbone development.
Additional Backbone Tips
Automated Backbone Scaffolding
Scaffolding can assist in expediting how quickly you can begin a new application by creating the basic files required for a project automatically. If you enjoy the idea of automated MVC scaffolding using Backbone, I'm happy to recommend checking out a tool called Brunch.
It works very well with Backbone, Underscore, jQuery and CoffeeScript and is even used by companies such as Red Bull and Jim Bean. You may have to update any third party dependencies (e.g. latest jQuery or Zepto) when using it, but other than that it should be fairly stable to use right out of the box.
Brunch can easily be installed via the nodejs package manager and takes just little to no time to get started with. If you happen to use Vim or Textmate as your editor of choice, you may be happy to know that there are also Brunch bundles available for both.
Clarifications on Backbone's MVC
As Thomas Davis has previously noted, Backbone.js's MVC is a loose interpretation of traditional MVC, something common to many client-side MVC solutions. Backbone's views are what could be considered a wrapper for templating solutions such as the Mustache.js and Backbone.View is the equivalent of a controller in traditional MVC. Backbone.Model is however the same as a classical 'model'.
Whilst Backbone is not the only client-side MVC solution that could use some improvements in it's naming conventions, Backbone.Controller was probably the most central source of some confusion but has been renamed a router in more recent versions. This won't prevent you from using Backbone effectively, however this is being pointed out just to help avoid any confusion if for any reason you opt to use an older version of the framework.
The official Backbone docs do attempt to clarify that their routers aren't really the C in MVC, but it's important to understand where these fit rather than considering client-side MVC a 1:1 equivalent to the pattern you've probably seen in server-side development.
Is there a limit to the number of routers I should be using?
Andrew de Andrade has pointed out that DocumentCloud themselves usually only use a single controller in most of their applications. You're very likely to not require more than one or two routers in your own projects as the majority of your application routing can be kept organized in a single controller without it getting unwieldy.
Is Backbone too small for my application's needs?
If you find yourself unsure of whether or not your application is too large to use Backbone, I recommend reading my post on building large-scale jQuery & JavaScript applications or reviewing my slides on client-side MVC architecture options. In both, I cover alternative solutions and my thoughts on the suitability of current MVC solutions for scaled application development.
Backbone can be used for building both trivial and complex applications as demonstrated by the many examples Ashkenas has been referencing in the Backbone documentation. As with any MVC framework however, it's important to dedicate time towards planning out what models and views your application really needs. Diving straight into development without doing this can result in either spaghetti code or a large refactor later on and it's best to avoid this where possible.
At the end of the day, the key to building large applications is not to build large applications in the first place. If you however find Backbone doesn't cut it for your requirements I strongly recommend checking out JavaScriptMVC or SproutCore as these both offer a little more than Backbone out of the box. Dojo and Dojo Mobile may also be of interest as these have also been used to build significantly complex apps by other developers.
Building The jQuery Mobile Wireframe
Introduction
This section of the tutorial will focus on showing you how to prototype a mobile user-interface using jQuery Mobile. Beginners may wish to read Nick Rigg's 'Building Cross Platform Apps with jQuery Mobile' article beforehand as it introduces many of the initial concepts we'll be building on.
One of the great things about jQuery Mobile is that it allows you to easily create functional mock-ups of your intended mobile UI simply using mark-up and data attributes. Similar to Dojo Mobile, jQuery Mobile comes with a large suite of pre-themed components and UI widgets that can be used to structure a complete interface without needing to touch a great deal of CSS during the prototyping phase.
This means that rather than opting to wireframe your application using pencil sketches or a tool like Balsamiq/MockFlow, the same amount of time can be invested in creating a mock-up which can be render tested cross-platform and cross-device prior to coding any real logic for your web app. We can then easily write the models, view logic and routers for our application and simply tie them to the prototype to complete the project.
What are we going to build?
We're going to be building a complete mobile photo search application that uses the Flickr API and provides views for results, individual photos, options and sharing - all which will be bookmarkable. In Part 2 of the tutorial, we're actually going to write the Backbone.js code that powers the rest of the app but for now, it's imperative that we get the prototype right. So that we have something to reference easily, I've decided to call the application Flickly.
What devices do we want to offer an optimal experience to?
My thoughts on device-driven design with respect to web applications are as follows: time-permitting, a developer should ideally consider opting for something akin to Andy Clarke's 'Hardboiled' approach to web design where we deliver an experience that may be individually catered to take advantage of the strengths a particular browser or device has to offer.
The reality is however that we don't always have the scope to create per-device experiences, so today's application will attempt to optimize for the devices or browsers most likely to access it. It's essential that the content the application exposes is readily available to all users, regardless of what browser they are accessing it from so this principle will be kept in mind during the design phase. We'll be aiming to create a solution that's responsive from the start and jQuery Mobile simplifies a lot of the actual heavy lifting here as it supports responsive layouts out of the box (including browsers that don't support media queries).
Let's imagine that hypothetically, our analytics state that 50% of the users who come to Flickr access it via the iPhone, 10% via the iPad and the other 40% via the desktop. If we're going to build a web application catered to mobile, it would thus make sense to ensure iPhone users get an optimized experience with iPad and other devices (Blackberry etc.) getting an experience that looks acceptable.
With jQuery Mobile, this may just mean views being stretched or widened a little more, but the overall application will still remain fully usable.
Structuring the user interface
Home/Index screen
In my opinion, landing/first screen of a mobile application should focus on encouraging engagement with your app or service's primary function. Keep it very simple. With Flickr, this is relatively straight-forward - search. Once the primary function has been identified, avoid the temptation to over-clutter your UI for the sake of making it look more advanced than it has to. Flickr offer a number of advanced search options through their API and I initially thought including some of these options on the same page would make the user feel more empowered.
The problem with this assumption is that the majority of users just want an easy way to search for photos using keywords. That's all the first screen needs to offer - a search box. I ended up moving all of the advanced search options to an options page, but as it's just a click away, advanced users likely won't mind the small amount of extra work required to use those features. A fixed-position navigation toolbar that appears on the very bottom each view ensures that getting to where you need to seldom takes more than a touch.
Search results
The next concern was how to display search results. In my first draft of the application, I thought that mimicking Flickr's desktop experience (the N x M image grid found in results) would give users something familiar that they'd be comfortable with. Wrong again. On a mobile device, you're usually constrained by limited dimensions and should attempt to offer an experience that works best for this scenario rather than assuming one that works well elsewhere. It's a different paradigm. The grid on mobile suffered from a number of issues like lack of readable meta-data and difficulty selecting (touching) images as the thumbnails were quite small.
What I opted for instead was a jQuery Mobile ListView which was created specifically for the purposes of displaying a list of thumbnails with a description. Each thumbnail is given it's own row on the screen with meta-data positioned to the right and it's extremely easy to navigate around. The jQuery Mobile design team really thought this through and it shows. By using header-positioned previous and next buttons, I was then able to give users an easy way to navigate through paginated results without limiting their experience in any way. As mentioned, each of these result pages can be bookmarked and maintain information about the search type selected, page number and keywords chosen.
Single photos and sharing
Another important view was that for a single photo. The Flickr API has distinct calls required for both search results and single photos (with full meta-data) so it made sense to offer a view that could provide all of the available information about an image to the user if they clicked on a particular search result. In this case, the desktop experience wasn't overly complex - display a large image with captions beneath it. Porting this idea over to jQuery Mobile, a larger image was displayed at the top of a photo view with an inline list (resembling a 1-column table) for the meta-data. It was clean, easy to read and worked well on all devices.
I chose not to access the comments section of the returned data-set as in my opinion, this would have let to further views for user profiles, user pages and items again, outside the scope of this project. To give the user an opportunity to view a richer experience if they so choose, each single photo page also includes a link to it's corresponding page on Flickr. This way the user doesn't feel overly locked into the application if they want to access a complete view of the original data (with comments and the complete site experience). A 'share' page with links to post the item to Facebook and Twitter was also added.
Other pages
A number of other pages were created as a part of the application. These included about, source and help. Unlike the other views of the application that were required a great deal of thought, each of these pages simply used variations of the jQuery Mobile list options to render data in a readable, row format. You can see screenshots of some of these below, including samples of how the other pages that were mocked up might look in the final application.
.jpg)
Some developers may find the descriptions of my thought process around the mobile application minimalist, but I believe this is paramount to creating an experience that emphasizes usability and appropriateness for the intended audience's device of choice over other factors. It's a way of thinking that has worked for mobile applications I've created in the past, however I'm always open to considering other approaches if accompanied by a sound argument :)
To fork or download the jQuery Mobile prototype above, please see https://github.com/addyosmani/flickly-wireframe.
Conclusions
That's it for Part 1 of this tutorial. I hope it's come in useful. In Part 2, we're going to jump right in to some heavy Backbone.js development, using the concepts that have been introduced in this first part to create a fully functional mobile web application that will work cross-browser and cross-device. See you again soon!
About the Author
.jpg)
Addy Osmani is a User Interface Developer from London, England. An avid blogger, he has a passion for encouraging best practices in client-side development, in particular with respect to JavaScript and jQuery. He enjoys evangelizing the latter of these and is on the jQuery Bug triage, API and front-end teams. Addy works at AOL where he's a JavaScript developer on their European Products & Innovation team.
Find Addy on:
Comments (8)
