Some times debugging jQuery Mobile can be tricky. Here are a few tips to help you through the debugging process.
Use an analog
It is difficult to debug jQuery Mobile on a mobile browser, but you can use an analog. By analog, I mean a desktop browser that has a similar core to the mobile browser causing you issues. For an iPhone, that would be Safari, for WP7 use IE, and for Android use Chrome. This isn’t the same as running your code on a device but it is as close as your going to get on a desktop.
Use Unique Ids on elements
A lot of experienced web developers get confused by jQuery Mobile’s nature. Unlike a normal web app that lives only until the next page load, jQuery Mobile apps can live past page loads. The fact that new pages get mixed into the DOM with previous pages can be initially confusing. It also can introduce subtle bugs if your element names are not unique, not just on the page they were created on, but across all pages. Remember by the rules of HTML an Id is supposed to be a unique item. If you load in a new page with a button named print, and you have a previous page also with a button named print, odds are when you tap the print button on the newly loaded page nothing will happen. This is because the older button exists in the DOM first.
Reference the active page
jQuery Mobile keeps a reference to the currently active page in $.mobile.activePage. Use it in selectors that are supposed to be restricted to the current page. Not only will this make your code faster by narrowing the selector, it will also keep you finding matches on other non-visible pages.
var key = $(this).attr("data-rockncoder-tag"),
id = this.id;
Use the pageinit event not $(document).ready()
One of the first bits of jQuery we all learn is to use $(document).ready() to detect when jQuery is ready to rock. jQuery Mobile; however, is not ready until after the pageinit event has been triggered. This can be a very subtle bug. On some systems it may appear that it works fine, but on others it may cause erratic, difficult to repeat weirdness to occur.
Always test on a device
No other precaution that you take is as valuable as testing on a device. And you should try to test on all of the devices that you plan to support. It is of course impossible to test on every possible device, but be sure to select a healthy cross section of devices.
Use a remote-able browser
Currently the only one of these that I am aware of is the Opera Mobile browser. With it on your device and Opera on your desktop, it is possible to view HTML, CSS, and most importantly set breakpoints while your app runs on a device. There are other debugging aids such as WEINRE, which allow viewing of markup and viewing console logs, but to the best of my knowledge they don’t allow for the setting of breakpoints. Opera is available from http://www.opera.com/.
Unfortunately there is no magic bullet that will make all of your bugs go away. Hopefully these tips will allow you to both find and prevent issues in your app.
Safari Books Online has the content you need
Take advantage of these jQuery mobile resources in Safari Books Online:
|Pro jQuery Mobile will teach you how to create themable, responsive, native-looking applications for iOS, Android, Windows Phone, Blackberry, and more.|
|jQuery Mobile provides a practical approach to using jQuery Mobile to quickly develop web-based applications for mobile devices.|
|jQuery Mobile First Look will show you the features of the jQuery Mobile framework, what they do, and how they can be used.|
|jQuery, jQuery UI, and jQuery Mobile: Recipes and Examples is a practical “cookbook” packed with realistic, easy-to-use solutions for making the most of jQuery Core, jQuery UI, and jQuery Mobile.|
About this author