Mobile Web Development Strategies

Mobile devices have come a long way in the last few years. As powerful as their desktop counterparts, mobile devices are profoundly different with touch screens, GPS, accelerometers, cameras, and other sensors, not to mention smaller screens. So many differences demand an entirely different experience. We then have the challenge of bringing those designs to life in a sustainable, maintainable, and effective way. We use several key strategies including device detection, progressive enhancement, and responsive design.

Device Detection allows the web server to know which particular device is being used, and to serve up an entirely different web page for that device. Going to the same web site could give you something completely different whether you are on your laptop, iPad, your brand new Android phone, or that old phone from several years ago that allegedly has Internet access. You could build one website for all, but chances are it would only look good on one of these devices. Device detection lets you target each one separately, for its own unique experience. Not only can you target all mobile devices globally, but you can actually target each specific type and version, from iPhone 3 to Blackberry 6.

Device detection by itself has a major drawback. There are hundreds of possible devices out there, making it costly to build corresponding websites that would be difficult to maintain. Responsive Design is an alternative to this. One website is created that morphs according to the device’s screen width. For instance, a desktop may show a three-column-wide layout, whereas these columns would be stacked one on top of each other for mobile. Responsive design works great for static content. It starts to show some limitations with rich web applications.

Among the many mobile devices out there, screen resolution is only one of the differences. Rich web applications require the use of javascript. Progressive Enhancement checks for javascript support, and if found, adds extra style and functionality that only javascript can give. Older phones will get a basic experience while newer smartphones can utilize modern technology.

So which of these strategies is the best one? Well, that entirely depends on what you’re trying to build, and you don’t have to pick just one strategy. You could use device detection to send the user to a mobile version that uses progressive enhancement, but this is just one possibility.

http://coding.smashingmagazine.com/2009/04/22/progressive-enhancement-what-it-is-and-how-to-use-it/

http://www.alistapart.com/articles/responsive-web-design/

Zepto vs jQuery for Mobile

jQuery is the most popular js library by a long shot, and likewise jQuery Mobile is shaping up to be a great layer on top of that for mobile.  Comparatively Zepto is much smaller, has a smaller API and is still at version 0.8.  So why would we use Zepto?  First off, zepto is smaller. It’s goal is to stay in the 5 to 10k range. Bandwidth is a much bigger issue on mobile.

One of the things that’s made jQuery so popular is it’s cross browser support, going back to ie6. This is also a big part of the codebase and something Zepto has chosen to pare down.  The same browsers aren’t needed for mobile.  Since mobile is predominately webkit anyway, you can just progressively enhance for that.  If you’re packaging up an app for ios or android this makes sense as well.

Another great thing about Zepto is that it shares syntax with jQuery. The same methods work for both. This leads to a fast learning curve, but more than that.  You can start a project in Zepto.  If the device requirements change to support windows mobile or you need to use some of the jQuery only methods you can just swap out Zepto for jQuery and your code should essentially work, with only a few exceptions. In conclusion, you should give Zepto a try, but be ready to switch.

Issue with $(document).ready() on jquery mobile

One of the first things a developer learns with jQuery is the use of the document.ready function.  It’s a good place to initialize your scripts well before all of the images are loaded in the onload event. A  jQuery mobile site on the other hand works differently.  It’s a single page application, meaning that each of the screenviews aren’t individual “pages” in the traditional sense, but multiple screenviews loaded into the DOM at once.  It’s what allows jQuery mobile it’s fancy and responsive transitions.  It’s a nice feature, but where do we initialize our scripts? Well, we put them in the pageinit event like this.

$( '#myPage' ).live( 'pageinit',function(event){
alert( 'This page was just enhanced by jQuery Mobile!' );
});

The #myPage selector is for a specific page. If you want your pageinit globally use the ‘div[data-role=”page”]’ selector. To bind make sure you use the .live instead of the .bind method. This will insure all future pages that haven’t been created yet get the bind as well.  Prior to the beta 2 version we used the pagecreate event instead of pageinit. A change was made in that version to bind jQuery mobile’s widgets with the pagecreate event. Pageinit comes after the widgets have been initialized so it will typically be the one you want. If you’d rather call a script before the widgets you should use the pagebeforecreate event. The pagecreate should rarely be used.  The only reason I could think of using it, is if you’re trying to create your own widgets for the framework.