Friday, January 10, 2014

jQuery Mobile Events Diagram

When building jQuery Mobile applications I often find it useful to have a quick reference to all events within the lifecycle. This jQuery Mobile events diagram should be helpful for new developers learning the jQuery Mobile event model or advanced developers that often bind to these events:

This diagram is also available within Pro jQuery Mobile. In addition to the diagram, you will also find detailed examples and descriptions for each event. My events diagram for jQuery Mobile 1.3 and earlier is also available. Enjoy!

Sunday, February 19, 2012

jQuery Mobile: Performance Tips

sharkDo you know what swimmers wore in the last summer Olympics to gain a performance advantage? They wore sharkskin suits. The swimmers that wore this new technology won more races and broke more world records than ever before. Unfortunately, mobile development requires much more effort than simply sliding on a suit to gain more performance. Mobile developers are challenged with multiple limitations that affect performance: a network with limited bandwidth and underpowered devices. As we build mobile applications, it is important to code review the entire project with an emphasis on performance. Listed below are several tips for improving the performance of your jQuery Mobile applications:

Prefer Native jQuery Mobile Widgets

We can gain several implicit advantages by reusing jQuery Mobile's native widgets. They are compatible across all browsers, they simplify maintenance, and more importantly, they save us from writing additional custom code that adds overhead to our applications. While there will be occasions when we need to build custom widgets, it is important to consider all native solutions prior to choosing a custom alternative. I have seen several instances where custom alternatives were built when native solutions would have provided similar behavior with much less overhead. For instance, I was recently reviewing a jQuery Mobile app that had built a custom message box when the same effect could have been designed with a native inset list (see Figure 1-1).
Native versus Custom Message Box
Figure 1-1. Native versus Custom Message Box

The native solution is significantly leaner containing 80% less CSS versus the custom solution (compare Listing 1-1 versus 1-2).
Listing 1-1. Custom Message Box
.message-box {
background-color: #ECE8D3;
color: #816d49;
font-size: 0.75em;
line-height: 1.3;
margin: 0 0 10px;
float: left;
width: 100%;
-moz-box-shadow: 0 0px 10px rgba(0, 0, 0, 0.3);
-webkit-box-shadow: 0 0px 10px rgba(0, 0, 0, 0.3);
box-shadow: 0 0px 10px rgba(0, 0, 0, 0.3);
-moz-border-radius: 0.6em;
-webkit-border-radius: 0.6em;
border-radius: 0.6em;
.message-box .inner {
padding: 10px 12px;
.message-box p {
color: #816d49;
font-size: 11px;
text-shadow: none;
font-weight: normal;

<div data-role="content">
<div class="message-box">
<div class="inner">
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna.</p>

Listing 1-2. Native Message Box
.ui-li-message {
white-space: normal;

<div data-role="content">
<ul data-role="listview" data-inset="true" data-theme="e">
<p class="ui-li-message">Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna.</p>

Another example I also encountered was the usage of JTSage's SimpleDialog plugin. While I have found value with JTSage's DateBox plugin for configuring date ranges, I have not seen a compelling advantage to consider their SimpleDialog versus the native dialog we get out-of-the-box with jQuery Mobile. Again, the native dialog provides similar behavior with much less overhead.

Removed Unused Themes

If you plan to style your entire jQuery Mobile application with custom themes it is preferred to use the structure-only CSS file from jQuery Mobile's download site. This is a lightweight alternative for applications that do not need the default themes and it simplifies the management of the custom themes (see Listing 1-3).
Listing 1-3. jQuery Mobile's structure file without default themes
<meta charset="utf-8">
<title>Custom Theme</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel=stylesheet href="css/theme/custom-theme.css" />
<link rel=stylesheet href="css/structure/"/>

<script type="text/javascript" src="jquery-min.js"></script>
<script type="text/javascript" src=""></script>
Additionally, to reduce HTTP requests, it is preferred to merge both the custom theme and structure files before deploying to a production environment.

Prefetch Secondary Pages that are Accessed Frequently

Most often, it is preferred to leverage the single-page model and dynamically append frequently accessed pages into the DOM in the background. We can achieve this behavior by adding the data-prefetch attribute to any link we want to dynamically preload:
<a href="prefetch.html" data-prefetch>Prefetched Link</a>
This hybrid approach allows us to selectively choose which secondary links we want to dynamically load and cache. This pattern is only recommended for pages that are accessed very frequently because this behavior will trigger an additional HTTP request.

Remove Unused Plugins

The jQuery Mobile framework contains many valuable plugins. However, if your application does not use all features then you can make your app a bit leaner by simply removing the unnecessary plugins. For instance, I was able to save 6KB by simply removing the following plugins from the uncompressed jQuery Mobile library: collapsible, collapsibleset, checkboxradio, select, and slider. The jQuery Mobile team is currently creating a Download Builder that will help simplify this task in the future.

Cache Highly Accessed Read-Only Pages

We can cache jQuery Mobile pages by attaching the data-dom-cache="true" attribute on the page container:
<div data-role="page" data-dom-cache="true">
The cached pages are persisted in the DOM. While this feature is advantageous for frequently-accessed, lightweight pages, its usage needs to be monitored carefully to assert the DOM remains at a manageable size.

Prefer the CDN-hosted minified and gzipped jQuery Mobile files

The files from the jQuery Mobile's CDNs are highly optimized and will provide a more responsive experience for your users. They are compressed, cached, minified, and can be loaded in parallel.

Mobile Web Performance Analysis Tools

If you are interested in evaluating your own mobile sites, here are several popular analysis tools that offer something unique in regards to how they grade for performance:
  • YSlow for Mobile: A Bookmarklet that grades internal and external sites from either a mobile or desktop browser.
  • Blaze: Evaluates the performance of your site from a physical device that is running in the cloud. This tool only allows you to evaluate external sites.
  • pkapperf: Captures performance metrics from your device's physical network traffic. This tool allows you to evaluate both internal and external sites.

Faster mobile networks and mobile CPU's will eventually become our shark skinned suits and mobile sites will become faster without any additional effort. While this is promising for developers, the Olympic swimmers are facing a new challenge. Those famous shark suits have been banned for the 2012 Summer Olympics.

Saturday, May 21, 2011

Titanium MVC Pattern

Are you looking to simplify your Titanium programming model? Leveraging the MVC pattern will help produce cleaner code and promote reusability. Applying the MVC pattern within Titanium is relatively easy and it provides all the advantages we expect from MVC. Here is a quick example of the view and controller components:


The view is responsible for creating the window and adding the necessary UI components. Your views may optionally manage styling properties (color, font, and positioning). Ideally, the better practice is to extract all styling properties into external JSS files but I found this feature to be too quirky in its initial release.

* View Template
* Usage: APP.ui.LoginView.createWindow();

APP.ui.LoginView = (function(){

/* private methods to build UI specific components */
function buildWindow(){
return Ti.UI.createWindow({
title: 'Title',
barColor: '#225377',
backgroundColor: '#d4d2d3'

function buildUsernameTextField(win){
win.usernameTextField = Ti.UI.createTextField({
autocorrect: false,
hintText: 'Username',
left: 10,
width: 285,

/* Public API only exposes the createWindow method. */
return {
createWindow: function(){
var win = buildWindow();
return win;


The controller is responsible for managing events (button taps) and navigation. Events handlers communicate with server-side services when necessary.

* Controller Template
* Usage: APP.ui.LoginController.init();

APP.ui.LoginController = (function(){

/* Private helper methods */
function setEventListeners(win){
win.usernameTextField.addEventListener('return', function(){

win.passwordTextField.addEventListener('return', function(){

/* Public API only exposes init method. */
return {
init: function(){
var win = APP.ui.LoginView.createWindow();


The model is typically a JSON payload retrieved from a Restful service. For example, the handleLoginEvent will return user profile information after a successful login. We can save this object locally and leverage it on subsequent screens.

  • Small objects and methods.
  • Improved organization and readability
  • Promotes reusability of views. Also, the decoupled views allow you to swap in native-specific UIs when necessary all while reusing a single controller.
  • Simpler maintenance.
  • Allows for simpler unit testing with responsibilities split into separate objects.

I expect many developers may fall in the trap of modeling their JavaScript according to the KitchenSink examples. While those examples are useful, their programming practices should not be followed for a production ready app. For example, their examples do not leverage closure to eliminate global scope, they do not use a namespace convention for improved organization, and all MVC responsibilities were bundled within a single object.

Sunday, March 20, 2011

Mobile March

The Mobile March conference was held at the Best Buy headquarters this weekend. Here is a brief recap of the sessions I attended:

Morning Sessions


Key points:
  • There is a low tolerance for mediocrity in mobile. Apps have a 50% abandon rate after the first 30 days.
  • Mobile trends: News via tablets, social media, location based apps, group messaging with apps like Beluga.
  • Mobile marketing, what's working: Incentives, deals, hot buys, and rebates.
  • 5 things to consider: Activate advertising with text or QR codes, activate sponsorships with mobile, launch mobile coupons, test a location based campaign, use mobile to drive app downloads.

Simple and low cost mobile technologies have proven to be very effective solutions. SMS, QR codes, and social media fall within this category. The goal is simple, get customers to engage and then extend the conversation.

Cracking the Code: QR Codes and Coupons

Key points:
  • QR code scanning is up 1000% in the last 6 months. Consumers love to scan QR barcodes.
  • QR codes link users to additional information. For example, Best Buy has QR codes next to each price tag. Launching the QR code provides the user with detailed information and user reviews. Additionally, if you scan another product you can see a side-by-side comparison of both products.
  • Looking for a QR reader? Try NeoReader.
  • Chino Latino is the first restaurant to put a QR code on a billboard.

Mobile March had QR codes at the entrance of each session. Scanning the code displayed the presenters bio. Again, this is a simple, low cost solution to interact with mobile customers.

The iPhone vs Android Showdown

Key points:
  • iPhone
    • Xcode 4, which was released a few weeks ago, has finally simplified the organization of their Interface Builder and code editor. Navigating between Interface Builder and code is much quicker via their new tab orientation instead of externalized windows found in Xcode 3.
    • Xcode is the superior IDE when compared to Android development on Eclipse. The Interface Builder is far superior and the iPhone emulator loads much faster.
  • Android
    • Android's distribution model is superior. It takes several hours to deploy to Android's Market. The Apple Store certification process may take up to 2 weeks.

Creating a mobile wireframe is easily 2-3 times faster in Xcode. While Android finally released a UI builder with their 3.0 SDK it is far from perfect. A major Android advantage is their time to market on app upgrades. If you have a production defect will you have the patience to wait for the Apple certification process?

Grill yourself

Key points:
  • Think about UX as soon as you have an idea.
  • Keep apps simple and moving parts to a minimum.
  • You can sell anything if you can do it simple, quick, and cheap.
  • Share the analytics about your mobile users with your organization.

Afternoon Sessions

The Current State of the Mobile Web

Key points:
  • Native advantages: performance, consistency, safety, convenience, functionality.
  • Native disadvantages: harder to build, approval process, hard to discover, fragmentation.
  • Mobile Web advantages: open, connected, ubiquitous, unregulated.
  • Mobile Web disadvantages: unregulated, performance is slower.
  • Mozilla and Google are coming out with web app stores soon.
  • Looking for a fixed header and footer for your scrollable window on iOS? Try iScroll.

There are clearly many advantages to Mobile Web. Its deployment model is instantaneous and it helps reduce fragmentation and development costs. If you are interested in jQuery Mobile, here is a good presentation.

Blackberry Playbook

Key points:
  • Cost of entry
    • BlackBerry: Free
    • Android: $25 (one time)
    • Apple: $99/yr
  • Distribution
    • Google: lass than hour
    • BlackBerry: 4-6 hours
    • Apple: up to 2 weeks
  • BlackBerry has a "try before you buy" program in their AppWorld store which is unique.

The Playbook tablet by BlackBerry will be released soon. While competition is good, they definitely have an uphill battle to climb.