jQuery Mobile allows pages to be pulled into the DOM dynamically via its default click hijacking behavior, or through manual calls to $.mobile.changePage(). This is great for applications that generate HTML pages/fragments on the server-side, but there are sometimes cases where an application needs to dynamically generate page content on the client-side from JSON or some other format. This may be necessary for bandwidth/performance reasons, or because it is the data format of choice for the server they are interacting with.
For applications that need to generate page markup on the client-side, it's important to know about the notifications that are triggered during a $.mobile.changePage() call because they can be used as hooks into the navigation system that will allow you to generate your content at the appropriate time.
A call to changePage() will usually trigger the following event notifications:
pagebeforechange
pagechange
pagechangefailed
These notifications are triggered on the parent container element ($.mobile.pageContainer) of pages, and will bubble all the way up to the document element and window.
For applications wishing to inject pages, or radically modify the content of an existing page, based on some non-HTML data, such as JSON or in-memory JS object, the pagebeforechange event is very useful since it gives you a hook for analyzing the URL or page element the application is being asked to load or switch to, and short-circuit the default changePage() behavior by simply calling preventDefault() on the pagebeforechange event.
To illustrate this technique, take a look at this working sample. In this sample, the main page starts off with a list of categories that the user can navigate into. The actual items in each category are stored in a JavaScript object in memory, for illustrative purposes, but the data can really come from anywhere.
var categoryData = {
animals: {
name: "Animals",
description: "All your favorites from aardvarks to zebras.",
items: [
{
name: "Pets"
},
{
name: "Farm Animals"
},
{
name: "Wild Animals"
}
]
},
colors: {
name: "Colors",
description: "Fresh colors from the magic rainbow.",
items: [
{
name: "Blue"
},
{
name: "Green"
},
{
name: "Orange"
},
{
name: "Purple"
},
{
name: "Red"
},
{
name: "Yellow"
},
{
name: "Violet"
}
]
},
vehicles: {
name: "Vehicles",
description: "Everything from cars to planes.",
items: [
{
name: "Cars"
},
{
name: "Planes"
},
{
name: "Construction"
}
]
}
};
The application uses links with urls that contain a hash that tells the application what category items to display:
<h2>Select a Category Below:</h2>
<ul data-role="listview" data-inset="true">
<li><a href="#category-items?category=animals">Animals</a></li>
<li><a href="#category-items?category=colors">Colors</a></li>
<li><a href="#category-items?category=vehicles">Vehicles</a></li>
</ul>
Internally, when the user clicks on one of these links, the application intercepts the internal $.mobile.changePage() call that is invoked by the frameworks' default link hijacking behavior. It then analyzes the URL for the page about to be loaded, and then decides whether or not it should handle the loading itself, or to let the normal changePage() code handle things.
The application was able to insert itself into the changePage() flow by binding to the pagebeforechange event at the document level:
// Listen for any attempts to call changePage().
$(document).bind( "pagebeforechange", function( e, data ) {
// We only want to handle changePage() calls where the caller is
// asking us to load a page by URL.
if ( typeof data.toPage === "string" ) {
// We are being asked to load a page by URL, but we only
// want to handle URLs that request the data for a specific
// category.
var u = $.mobile.path.parseUrl( data.toPage ),
re = /^#category-item/;
if ( u.hash.search(re) !== -1 ) {
// We're being asked to display the items for a specific category.
// Call our internal method that builds the content for the category
// on the fly based on our in-memory category data structure.
showCategory( u, data.options );
// Make sure to tell changePage() we've handled this call so it doesn't
// have to do anything.
e.preventDefault();
}
}
});
So why listen at the document level? In short, because of deep-linking. We need our binding to be active before the jQuery Mobile framework initializes and decides how to process the initial URL that invoked the application.
When the callback for the pagebeforechange binding is invoked, the 2nd argument to the callback will be a data object that contains the arguments that were passed to the initial $.mobile.changePage() call. The properties of this object are as follows:
toPage
options
$.mobile.changePage() function.For our sample application, we are only interested in changePage() calls where URLs are initially passed in, so the first thing our callback does is check the type for the toPage. Next, with the help of some URL parsing utilities, it checks to make sure if the URL contains a hash that we are interested in handling ourselves. If so, it then calls an application function called showCategory() which will dynamically create the content for the category specified by the URL hash, and then it calls preventDefault() on the event.
Calling preventDefault() on a pagebeforechange event causes the originating $.mobile.changePage() call to exit without performing any work. Calling the preventDefault() method on the event is the equivalent of telling jQuery Mobile that you have handled the changePage() request yourself.
If preventDefault() is not called, changePage() will continue on processing as it normally does. One thing to point out about the data object that is passed into our callback, is that any changes you make to the toPage property, or options properties, will affect changePage() processing if preventDefault() is not called. So for example, if we wanted to redirect or map a specific URL to another internal/external page, our callback could simply set the data.toPage property in the callback to the URL or DOM element of the page to redirect to. Likewise, we could set or un-set any option from within our callback, and changePage() would use the new settings.
So now that we know how to intercept changePage() calls, let's take a closer look at how this sample actually generates the markup for a page. Our example actually uses, or we should say, re-uses the same page to display each of the categories. Each time one of our special links is clicked, the function showCategory() gets invoked:
// Load the data for a specific category, based on
// the URL passed in. Generate markup for the items in the
// category, inject it into an embedded page, and then make
// that page the current active page.
function showCategory( urlObj, options )
{
var categoryName = urlObj.hash.replace( /.*category=/, "" ),
// Get the object that represents the category we
// are interested in. Note, that at this point we could
// instead fire off an ajax request to fetch the data, but
// for the purposes of this sample, it's already in memory.
category = categoryData[ categoryName ],
// The pages we use to display our content are already in
// the DOM. The id of the page we are going to write our
// content into is specified in the hash before the '?'.
pageSelector = urlObj.hash.replace( /\?.*$/, "" );
if ( category ) {
// Get the page we are going to dump our content into.
var $page = $( pageSelector ),
// Get the header for the page.
$header = $page.children( ":jqmData(role=header)" ),
// Get the content area element for the page.
$content = $page.children( ":jqmData(role=content)" ),
// The markup we are going to inject into the content
// area of the page.
markup = "<p>" + category.description + "</p><ul data-role='listview' data-inset='true'>",
// The array of items for this category.
cItems = category.items,
// The number of items in the category.
numItems = cItems.length;
// Generate a list item for each item in the category
// and add it to our markup.
for ( var i = 0; i < numItems; i++ ) {
markup += "<li>" + cItems[i].name + "</li>";
}
markup += "</ul>";
// Find the h1 element in our header and inject the name of
// the category into it.
$header.find( "h1" ).html( category.name );
// Inject the category items markup into the content element.
$content.html( markup );
// Pages are lazily enhanced. We call page() on the page
// element to make sure it is always enhanced before we
// attempt to enhance the listview markup we just injected.
// Subsequent calls to page() are ignored since a page/widget
// can only be enhanced once.
$page.page();
// Enhance the listview we just injected.
$content.find( ":jqmData(role=listview)" ).listview();
// We don't want the data-url of the page we just modified
// to be the url that shows up in the browser's location field,
// so set the dataUrl option to the URL for the category
// we just loaded.
options.dataUrl = urlObj.href;
// Now call changePage() and tell it to switch to
// the page we just modified.
$.mobile.changePage( $page, options );
}
}
In our sample app, the hash of the URL we handle contains 2 parts:
#category-items?category=vehicles
The first part, before the '?' is actually the id of the page to write content into, the part after the '?' is info the app uses to figure out what data it should use when generating the markup for the page. The first thing showCategory() does is deconstruct this hash to extract the id of the page to write content into, and the name of the category it should use to get the correct set of data from our in-memory JavaScript category object. After it figures out what category data to use, it then generates the markup for the category, and then injects it into the header and content area of the page, wiping out any other markup that previously existed in those elements.
After it injects the markup, it then calls the appropriate jQuery Mobile widget calls to enhance the list markup it just injected. This is what turns the normal list markup into a fully styled listview with all its behaviors.
Once that's done, it then calls $.mobile.changePage(), passing it the DOM element of the page we just modified, to tell the framework that it wants to show that page.
Now an interesting problem here is that jQuery Mobile typically updates the browser's location hash with the URL associated with the page it is showing. Because we are re-using the same page for each category, this wouldn't be ideal, because the URL for that page has no specific category info associated with it. To get around this problem, showCategory() simply sets the dataUrl property on the options object it passes into changePage() to tell it to display our original URL instead.
That's the sample in a nutshell. It should be noted that this particular sample and its usage is not a very good example of an app that degrades gracefully when JavaScript is turned off. That means it probably won't work very well on C-Grade browsers. We will be posting other examples that demonstrate how to degrade gracefully in the future. Check this page for updates.