- Multipage Template
- Single-Page Template
- Link Types
- Preloading and Caching Pages
- Working with Page Transitions
- Customizing Loading Messages
- Wrapping Up
Preloading and Caching Pages
Page caching is very important when working with anything web-based. Cache refers to hidden storage where files are collected. By default, browsers handle webpage caching by putting the associated files in a local directory on the user’s computer so the webpage and its associated assets will load more quickly during subsequent visits. jQuery Mobile takes this concept a step further: the framework allows pages to be cached even before they’re linked to or displayed in the browser. Taking advantage of this functionality is as easy as using an HTML attribute named data-prefetch. Simply add it to any hyperlink in your webpage, and once the webpage has loaded, the URLs that these hyperlinks point to will be preloaded and cached. The following line of code shows how to add this attribute to a hyperlink to preload and cache the page it’s pointing to:
<a href="page2.html" data-prefetch>Link to page 2</a>
When running this example in a web browser, the request is made immediately upon page load. Figure 4.2 shows an example of the XMLHttpRequest being made from Chrome when the page loads.
Figure 4.2. A page being preloaded by jQuery Mobile using the prefetch attribute.
The framework also provides a way to handle page preloading via the application programming interface (API). We’ll talk more specifically about the API later in the book, but it’s important to know how to access it.
To preload pages programmatically, you first need to access the jQuery Mobile object:
$.mobile
Once the document object is ready, use the loadPage method to pass the URL you want to preload and define a number of properties for the request:
$(document).ready(function() {$.mobile.loadPage( "page2.html", {
type: false,
reloadPage: false,
type: 'get'
});
});
There are quite a few arguments you can pass as options in the loadPage method. Table 4.4 lists those optional arguments.
Table 4.4. loadPage optional arguments
Argument |
Description |
data |
Holds an object or string that can be sent with an Ajax page request. |
loadMsgDelay |
Sets the number of milliseconds to delay before showing the load message. The default is 50 milliseconds. |
pageContainer |
Holds the loaded page. The default is the jQuery Mobile page container, but this is customizable. |
reloadPage |
Defines whether or not to reload the page being requested. The default value is false. |
role |
When the page is loaded, this defines the data-role value that will be applied. |
type |
Specifies whether the request is a get or a post. |
In addition to providing control for preloading files, the jQuery Mobile framework provides control for caching pages in the document object model (DOM). Just like the preload option, you can define whether a page should be cached in the DOM via an HTML attribute or the jQuery Mobile API. The following example shows how the attribute can be used in a page tag to cache a webpage:
<div data-role="page" data-dom-cache="true"
>
To cache a webpage using the API, you can set all pages to cache by default:
$.mobile.page.prototype.options.domCache = true;
Or, you can cache a page independently. You would cache a page with an id of my-page like so:
$('#my-page').page(true);
When working with the single-page template, jQuery Mobile also manages the pages it preloads so the DOM doesn’t get too large. If many pages are kept in the DOM, the browser’s memory usage can get out of control and the browser will likely slow down or crash. To manage the memory size, the framework removes pages that are loaded via Ajax from the DOM automatically via the pagehide event when the visitor navigates away from them. You’ll learn more about this and other events later in the book.
There are a number of benefits to preloading and caching pages. They load quicker and prevent the Ajax loading message from appearing when a visitor tries to access the preloaded page. However, it’s important to keep in mind that each preloaded page creates an additional HTTP request, which uses more bandwidth. Therefore, it’s important to preload pages only when you think visitors are likely to view a subsequent webpage.