The history of software is replete with fierce competition among technologies and products. People argue vehemently about which technology will eventually overtake the other. In 20 years of business, I've seen this scenario play out quite a few times. These days, a popular debate is raging about whether mobile websites are preferable to native mobile applications.
For a mobile website, you write your code once using JavaScript, HTML, and maybe HTML5. Unlike a mobile application, your graphics options for a mobile website are severely limited, and the hardware used to access the site is out of your control. The overall user experience with a mobile site, and in some cases the site's performance, will likely be different than if the content were in the form of a native mobile application. Unless the mobile browser supports HTML5 and you code against local storage capabilities, a mobile website requires more bandwidth and more frequent round trips. On the other hand, the downside of mobile apps is that you must create a native application for each mobile platform you intend to support. Thus, your effort and cost are multiplied by the number of platforms for which you create native apps. This debate is definitely not easy to settle, and I heartily recommend making a decision strictly on a per-project basis.
Now that you've developed your first mobile app in "Build a Client-Side Mobile Web App Using jQuery Mobile," I'll now explore the position of the mobile-website camp and introduce the current preliminary version of a library that promises to make mobile site development easier and more productive.
jQuery Mobile
As obvious as it may sound, the jQuery library changed a few things in web development. Foremost is its contribution to making AJAX and JavaScript an integral part of the web experience. Today, when we think of a web interface, we think holistically of client-side and server-side functionality, as well as of out-of-band service calls. The creators of jQuery didn't invent JavaScript or AJAX, but their library made these languages so easy to use that everybody assimilated the library and its programming model. To measure the success of jQuery, just think of what the folks at Microsoft did with it: They stopped development on their own ASP.NET AJAX extensions and embraced jQuery.
jQuery Mobile and its parent library, jQuery, are so closely related that the expression "chip off the old block" perfectly summarizes the affiliation between the two. jQuery Mobile just inherits from the parent jQuery library and adapts this library to the world of mobile development. Therefore, in order to use jQuery Mobile, you must also reference the jQuery library.
The main purpose of the jQuery Mobile library is to enable cross-platform, cross-device, and cross-browser programming of mobile websites. The library shares the same architecture and programming model as full jQuery. (Note that this article is based on an Alpha version of jQuery Mobile. It is likely that more features will be available and that a larger group of browsers will be fully supported by the time this article goes to print.)
Current Browser Compatibility
Any JavaScript library relies on browser capabilities to offer its services to developers. Primarily, a JavaScript library shields developers from the differences in the underlying browsers. If you think the number of desktop browsers is fairly large, the number of browsers in the mobile world is quite staggering, and the differences in functionality among them are significant. Developers learn a unified API that works across a large number of browsers. For example, a significant part of the jQuery code base deals only with browser compatibilities and performs tricks to ensure that users get nearly the same experience regardless of the browser. JavaScript libraries are not magic, so you should not expect them to make the same content in different browsers look exactly alike. However, most libraries are quite successful in providing a similar experience.
The jQuery Mobile library has one basic requirement: Browsers must support media queries. A media query is the feature that a page author uses to limit the scope of a style sheet. In this way, the look and feel of the page content can be adapted to devices based on their specific capabilities. A media query is expressed through the media attribute in the element, as in the following example:
The content of the media attribute is an expression that the browser must be able to parse and understand. The preceding example uses a mobile-specific style sheet if the device width is less than 768 pixels (typically, the width of a tablet device). Media queries are common in the jQuery Mobile style-sheet file.
In jQuery Mobile, browsers are graded A, B, or C, based on the capabilities they provide with respect to the library's needs. A-grade browsers typically offer full programming support and can execute JavaScript code. They also offer Document Object Model (DOM) manipulation and can apply Cascading Style Sheets (CSS) styles. These browsers are tested regularly and basically represent the group of browsers that the library is built against. There's no guarantee, however, that 100 percent of the library's features are supported on all A-grade browsers.
B-grade browsers are capable and powerful browsers, but they have a limited market share that is not sufficient to justify regular testing. Finally, C-grade browsers don't support media queries. When operating through a C-grade browser, jQuery Mobile just falls back to plain HTML and basic CSS. No DOM modification is applied to page elements. Figure 1 charts the mobile browsers that jQuery Mobile currently supports and shows their rankings.
Grade | Native Browsers | Opera Mini | Opera Mobile | fennec |
---|---|---|---|---|
A | iOS, Android, WebOS, BlackBerry 5 and later, Symbian | iOS 3+, Windows Mobile, BlackBerry 5+, Symbian | Android, Symbian | Android |
B | Nokia Maemo | Nokia Maemo | ||
C | BlackBerry 4.x, Windows Mobile | Android |
For more details about browser support, you might want to check out the jQuery Mobile Graded Browser Support page. You'll notice that jQuery Mobile works well with most native browsers on more recent mobile platforms. Opera Mini is probably the best browser for older devices. Windows Phone 7 is not supported yet, but as you can guess, support will be coming soon.
Pearls of HTML5
In an attempt to provide a native mobile look and feel, jQuery Mobile applies changes to plain HTML elements, adding style information and bitmaps. To do this, jQuery Mobile requires a CSS style sheet along with a link to the parent jQuery library. In Figure 2, you can see the header that is ultimately necessary for any page that will use jQuery Mobile.
A jQuery Mobile page may be based on HTML5 syntax and may include new tags, such as
In jQuery Mobile, the data-role attribute indicates the role played by that specific element in the context of the page. Feasible values include header, footer, content, and page. This information simply helps the library decide which DOM will change to apply to that element. For example, the default style sheet renders the header on a black background and with a larger font, and it renders the footer with a smaller font. Figure 3 shows the output of the markup in Figure 2.
The library recognizes quite a few data-xxx attributes that are used to decorate HTML elements and give them a special meaning. In this regard, HTML5 data-xxx attributes are different from microformats. A microformat is still a special HTML markup, but it has a general scope and is not limited, as data-xxx attributes are, to the current application when not on the current page.
Configuring the Header and Footer
Most mobile pages have a header and a footer. The header typically contains text, an image, and one or two buttons. Buttons usually go at the edges of the screen. The image and text are often mutually exclusive. You often find the Back button in the header. This button is added automatically to simplify navigation and to mimic the iPhone interface. (Windows Phone 7 and most Android devices have their own manual Back buttons.) In any case, you can either customize or remove the default Back button. If you provide your own Back button, the default one is dismissed. Here's the markup you need to define a custom Back button:
<<
Waterpolo scores
Alternatively, you can prevent the button from being displayed by using the following markup:
Waterpolo scores
Associated with a button markup, the data-icon attribute indicates the default icon to use for a button. The feasible values are delete, back, edit, and save.
Another data attribute worth mentioning is data-position. This attribute indicates the effective position of the header and footer bars during scrolling. The default value is inline, meaning that the header and footer will flow with the page and disappear from view if the page is too long. To keep bars in their regular positions, set the attribute to fixed:
Waterpolo scores
The library runs some scripts following scroll events to position bars at the top or bottom of the visible page.
The header can contain up to two buttons. The first two anchors are used as buttons unless you enter a different configuration. By default, the first anchor goes to the left and the second anchor takes the rightmost position. You can specify a position by using the ui-btn-left or the ui-btn-right CSS classes as follows:
<<
Waterpolo scores
Finally, you can still change all the default settings for the header and footer by simply embedding a
Any link you add to the footer element will be styled as a button. By default, footer buttons are placed side by side to save space and can support icons as buttons in the header. If you want to add some padding around the footer element, you must add the ui-bar CSS class. Here's an example:
In mobile pages, the footer is also often used as an application bar that contains a few buttons that are shared by various pages. To make this happen, you must assign your footer an ID and a fixed position, set the ID through the data-id attribute, then use the same ID in the footer of each linked page. Here's the markup you need for an application bar:
You must repeat this markup for each page that you want the application bar to appear on. Compared to a plain list of buttons, an application bar covers the entire row and buttons (up to five) are evenly arranged in the space. If more than five buttons are listed, the bar wraps to the next row.
In mobile pages, lists are everywhere. A special data-role attribute takes the responsibility of rendering list items in a way that mimics the UI of most devices, as in the UI shown in Figure 3. You have various options by which to style the list item. For example, you can add an icon to the left side and text to the right side. Here's how:
The data-transition attribute indicates the effect from the list on the selected list item. Common values are slide, flip, and fade.
You can also create the list of items dynamically after downloading data from the server. Consider that a jQuery Mobile page is still subject to browser origin restrictions and is not allowed to download data from a remote data source. Figure 4 shows the source code to create a list view on the fly.
The example shown in Figure 4 assumes that the user will download scores of sport matches. The text of the list item contains the names of the teams. The icon indicates whether or not the match was played, and the rightmost text displays the score. It's important to remember that when you populate a UI element programmatically, you must send it a message to activate a listview role. This behavior is no different from what the jQuery UI forces you to do with its rich widgets.
jQuery Mobile adds a bunch of new events to the rich list of events supported by the parent jQuery. New events that are specific to the mobile interaction are tap, taphold, swipe, swipeleft, swiperight, scrollstart, scrollstop, and orientationchange. For each element marked with the role of page, you can have events like pagebeforeshow, pagebeforehide, pageshow, and pagehide. In spite of the name and the gesture, these events are in no way different from other jQuery events: You bind your handlers to them by using live() or bind() functions.
Now that you know enough to start practicing with jQuery Mobile, let's address a final, important point. How can you comfortably test your pages? You might want to use Visual Studio or WebMatrix to create a web project and, at your leisure, mix plain HTML pages with ASP.NET Web Forms or with MVC views. You can freely integrate jQuery Mobile in these pages and run them. When you view these pages in Internet Explorer, you won't see much. Most of the time, all you get is an old-fashioned, scanty HTML page.
Internally, jQuery Mobile relies on the WebKit engine, so you'll certainly get much better results if you switch to Safari or, better yet, Google Chrome. I use Chrome for my testing and encounter a nearly identical experience as when I test on a real device. Another option is, of course, to use emulators, as long as they let you test pages served from a localhost server. However, I get the true sense of my page only after I've tested it on a real device. Testing entails deploying sources on an Internet-based server—which isn't really an easy thing to do but provides the most realistic scenarios.
Now that we've scouted out the mobile website camp, try putting these techniques into practice to make your mobile site development easier and more productive in our next article where we will show you how to convert an existing website into a mobile website.
Lists, Lists, and More Lists
Events
Testing and Final Touches