Consumers are on track to buy one billion HTML5-capable mobile devices in 2013. Today, half of US adults own smartphones. This comprises 150 million people, and 28% of those consider mobile their primary way of accessing the Web. The ground swell of support for HTML5 applications over native ones is here, and today’s developers are flipping their priorities to put mobile development first.
Even in large enterprise environments, mobile browser statistics are on the rise and starting to align with their desktop cousins. We are still faced, however, with the fact that one third of the Internet is using a version of Internet Explorer older than 9. Even more sobering, in some cases, these early IE users can make up two thirds of the visitors to our sites. This will get better over time, and desktop users will upgrade to newer versions and better browsers, but as we push the Web forward and create amazing applications across all browsers, we must also create a solid architecture that will account for all users and give them the best experience possible.
The capabilities of web browsers mean everything to the success of our web projects and products. Whether for fun, profit, or the overall betterment of mankind, it’s important to understand how data should be served up for both desktop and mobile users. Finding the common ground across all browsers and figuring out which pieces should be used in the construction of today’s web applications is the goal of this chapter.
The Mobile Web refers to browser-based applications created for mobile devices, such as smartphones or tablets, which can be connected wirelessly. Since 2008, the Web has shifted toward focusing on mobile browsers, which are delivering an overall better quality of life for today’s web developers and users. However, this better quality of life is sometimes short lived once you start testing your new mobile web app on the myriad of devices and browsers. You may begin to wonder just what is supported and which HTML5 features you should use to build your app.
Whether you’re an HTML5, W3C standards-loving, Open Web expert or just coming fresh off HTML 1, this chapter will equip you with the latest code, trends, and market research to guide you through making the right decision for your next web project. So what are you waiting for? Level up!
First, let’s get our priorities straight. Prioritizing mobile design and development over the desktop was once laughable. In just a few years, the idea of “mobile first” has taken over, giving web developers a breath of fresh air in terms of HTML5-based APIs toward hardware access on mobile devices.
Apart from the obvious, here are multiple reasons for thinking mobile first:
Developing sites for constrained devices and resolutions will force you to create more fluid and flexible content.
Device features, such as accelerometer and geolocation hardware, present new business opportunities with technologies like Augmented Reality.
Overall, mobile first requires you to think in a code-quality mindset. Today, it’s required for developers to worry about things like battery life when doing hardware-accelerated animations with CSS. This quality of development not only brings better performing apps, but it also encourages you to focus on cleaner semantics.
As you wean yourself off of desktop-focused web development, mobile browsers give you a glimpse into the future. This allows you to stay on the bleeding edge and in touch with new specifications and features.
Unfortunately the Mobile Web isn’t write-once-run-anywhere yet. As specifications become final and features are implemented, interoperability will be achieved. In today’s world of mobile browsers, however, we don’t have a largely consistent implementation across all browsers. Even though new tablets and phones are constantly being released to achieve a consistent level of HTML5 implementation, we all know that we’re stuck supporting the older, fragmented devices for a set amount of time. So, needless to say, such devices as the iPhone 3G and any device that hasn’t upgraded past Android 4 will be the IE6s of this mobile era.
As the mobile landscape exists today, we have multiple platforms and browsers to support. When you use HTML5’s core APIs, you’re bound to the features that are supported by your target device. So it’s critical to understand where the mobile browser scene is today—and where it’s headed.
Writing mobile web apps that span all platforms and all browsers can be a huge undertaking. Previously, web app developers didn’t care if a desktop computer had a camera or accelerometer attached to it. The web applications of yesterday were not tied to the operating system and the capabilities of desktop hardware. Now, the Mobile Web adds another dimension of support to the apps we build, and the fragmentation across browsers and devices is mind-blowing. We must now create applications to be compatible across browsers, platforms, and devices. For example, Android’s WebKit-based browser supported Web Workers in version 2.1, but later disabled support in version 2.2, 3.0, and 4.0. Then, support of Web Workers was fixed and turned back on in 4.1! Confusing, right? This is what I mean by another dimension of support or fragmentation. You’re not only supporting browsers, but the operating system the browser is tied to as well.
How do you sort it all out? Not to worry, the remainder of the chapter examines the various mobile browsers, discusses the commonly supported APIs of each device, and identifies a core set of features from which you can build a solid enterprise mobile web app.
Note
You can find the latest matrix of HTML5 support across all rendering engines on the HTML5 engine comparison page on Wikipedia.
Take a moment to review the various mobile browsers and their respective communities. As developers, we must try to embrace all platforms and develop applications that span all of the following browsers—and more if needed. For example, your users should not be limited to a WebKit-only mobile application in which your code runs on iOS and Android only.
WebKit is the browser engine behind Mobile Safari, Android, and Chrome, to name a few. This open source project is constantly pushing the open web envelope, adapting to the latest W3C specifications as they’re published. The recent explosion of interest in WebKit can be attributed to the fact that it powers many of the leading mobile platform browsers.
Figure 2-1 shows the source code revision (vertical) as the function of time (horizontal). Some icons are there to represent products associated with WebKit; the position approximately resembles the era those products were made popular.
Apple’s adoption and implementation of early HTML5
specifications has been impressive. The company has been an obvious force in
pushing the Web forward. With standard hardware and multicore technology,
iPhones and iPads have been a great platform for HTML5 development. But,
it’s not all ponies and rainbows in iOS land, as each mobile browser has its
share of quirks and bugs. Earlier iOS versions suffered from a bug with JavaScript’s
innerHTML() and forced developers to
think of new ways to insert dynamic content. You’ll see the solution to this
problem in the next chapter—as for now, we’ll focus on the big
picture.
Apple’s community process around iOS progression and filing bugs is bound and limited to the way Apple chooses to do things. You can file bugs with its BugReporter (http://bugreport.apple.com), but you can search through issues that you submit only. Luckily, once again, the community has stepped up to give Apple a hand in allowing nonconfidential data from customers to be openly searched. To see if your bug has already been filed, you can visit http://openradar.appspot.com/faq.
Even though the Android default browser is based on WebKit, as of this writing, its implementation of HTML5 specifications is just starting to beef up in version 4. As Android evolves, we can rest assured that the coming HTML5 implementations will evolve with its community (http://source.android.com/community). For now, however, Android devices are horribly fragmented, and HTML5 support varies on devices and OS versions.
As for Android’s future, the newer Dolphin browser (http://dolphin-browser.com) promises to deliver major advances in browser technology:
5 to 10 times faster than the default Android browser
100% faster than Chrome (at times)
Scored over a 450 when tested on the respected test site, http://HTML5test.com, shown in Figure 2-2
Mozilla has been around for a while and is stronger than ever in focusing on community efforts and pushing the Web forward. As of this writing, Mobile Firefox is in third place for the best HTML5 implementation (Figure 2-3) and has trumped Mobile Safari (iOS) in terms of implemented HTML5 features.
This swapping of the throne will continue as the Mobile Web moves forward and evolves—and that’s a good thing. We want competition and standards progression. Mozilla is no stranger to the evolution of the Mobile Web with its ambitious new project called WebAPI (https://wiki.mozilla.org/WebAPI). The WebAPI project is a set of APIs for accessing device functionality usually accessible only for native applications. In summary, it’s an OS based on HTML, CSS, and JavaScript for mobile devices. It’s yet another effort to move the Web forward and enable developers to write web applications once for all mobile operating systems. Estimated delivery for the WebAPI project is mid-2012 through the Boot to Gecko project (B2G). Figure 2-4 shows a screenshot of B2G’s Gaia UI.
Opera (http://www.opera.com/mobile) has two separate browsers for mobile phones: Opera Mobile and Opera Mini. In Opera Mini, the Opera Presto browser engine is located on a server. In Opera Mobile, it is installed on the phone. Currently, Opera Mini holds a large percentage of market share among other browsers, but for enterprise HTML5 applications, Opera Mobile supports the core specifications we need, such as Web Storage, Web Workers, and Geolocation.
Windows Phone 7.5 features a version of Internet Explorer Mobile with a rendering engine that is based on Internet Explorer 9. So the simplest way of explaining what Windows Phone supports is to say that it supports what IE9 supports, including Web Storage and Geo location. The supported specifications for IE9 Mobile can be found at http://windowsteamblog.com/windows_phone/b/wpdev/archive/2011/09/22/ie9-mobile-developer-overview.aspx.
On a better note, Windows Phone 8 supports IE10. Internet Explorer 10 includes much better support for such HTML5 features as WebSockets, Web Workers, Application Cache, and IndexedDB.
As of the latest worldwide report on browser market share, WebKit-based browsers are clearly in the lead with over 80% of the market (Figure 2-5). Right now, Android and iOS dominate, but as new operating systems, such as Mozilla’s HTML5-based mobile B2G project, emerge we could see another shift of power in the ongoing “browser war.”
Things are moving fast already. During the months that it took me to write this book, WebKit-based browsers grew from a 75% market share in October 2011 to more than 80% in 2012. Opera Mini shrunk from 18.65% to 12%. IE browsers grew from .16% to .58%, but Microsoft is just starting up its marketing machine for the Windows Phone platform in 2012—so expect that IE number to grow.
Note
You can check the latest browser statistics at http://www.netmarketshare.com/browser-market-share.aspx?qprid=0&qpcustomd=1.
All of this information leads into the important topic of browser grading. Browser grading is a must for any mobile web project. It gives developers and QA a way to keep sane while developing and testing your application. It also sets forth a specific support schedule for your users and an overall target for your mobile web app’s capabilities. Table 2-1 illustrates a sample browser grading sheet from QuirksMode.
Table 2-1. Browser grading example
With a clearer picture of the mobile device and browser landscape, you next need to determine which W3C specifications the various browsers support and how you can use them today. In terms of enterprise development, certain client-side APIs are considered the advanced building blocks of today’s mobile web applications: Geolocation, WebSocket, Web Storage, Device Orientation, and Web Workers. These are the specifications on last call from the W3C; close to finalized, they are stable (for the most part) and adopted in today’s mobile browsers. Of course, you can find many other great specifications like the Media Capture API, which allows access to the device audio, video, and images, but this book tries to stay focused on specifications that are widely supported across all browsers today.
Table 2-2 details the support of the building-block APIs in the five leading or upcoming mobile platforms. All of these mobile browsers are considered grade A, B, or C. Throughout the book and at http://html5e.org, I will refer to this group of specifications and browsers as HTML5 Enterprise or HTML5e to easily identify and build upon the same specifications and browsers across mobile and desktop environments.
Table 2-2. HTML5 Enterprise (HTML5e) mobile support
Browser | Geolocation | WebSocket | Web Storage | Device Orientation | Web Workers |
|---|---|---|---|---|---|
Mobile Safari | Yes | Yes | Yes | Yes | Yes |
Android | Yes | No | Yes | Yes | No |
Mobile IE | Yes | Yes[a] | Yes | No | Yes[a] |
Opera Mobile | Yes | Mixed[b] | Yes | Mixed[c] | Yes |
Mobile Firefox | Yes | Mixed[b] | Yes | Yes | Yes |
[a] Mobile IE from Windows Phone 7.5 does not support these, but Windows 8 and above does. [b] Both Mozilla and Opera have temporarily disabled WebSockets due to security issues with the protocol. [c] Opera Mobile for Android has experimental support. | |||||
As you can see in Table 2-2, Mobile Firefox and Safari are the clear winners in terms of broad support, with Opera Mobile coming in at a close third. Android still has some work to do, and version 4 is looking much better. Likewise, Mobile IE has much better HTML5 support in IE10, but IE9 focused mainly on the “same markup” approach: trying to get things right in regard to HTML5-related markup and the IE rendering engine.
Note
For the latest browser HTML5 support information, check out http://caniuse.com and http://mobilehtml5.org.
So you’ve decided which browsers you’re going to support (all of them hopefully), but now you must polyfill or gracefully degrade, your apps where certain HTML5e specifications are not implemented. The premise for graceful degradation is to first build for the latest and greatest, then add polyfills, or handlers, for less capable devices. How can you create a development environment that will service your enterprise project needs and give you an API that works and degrades gracefully across multiple mobile browsers? At the end of each subsequent chapter, we’ll look at approaches to handling these issues and identify projects that could possibly provide an open source solution.
You now have a starting point: a decent view of which HTML5 APIs are supported within mobile device browsers. In terms of the future, W3C, spec-driven, device features are only guaranteed to get better as new device operating systems are released and the specifications themselves become final. The following chapters will examine and rate available frameworks to form a reusable API for your project.
In addition to deciding which browsers you are going to support, you need an easy way to develop and test across them. Enterprise development and QA cycles can get expensive depending on the scale of your project. So setting up the proper rapid development and testing environment is critical to success.
Because the current mobile market is mostly owned by Android and iOS, WebKit-based testing is fairly easy. You can test things out as you normally do on your desktop browser, then run them on a targeted mobile device that is backed by a version of WebKit. Just because you tested your app on the desktop version of Chrome or Safari, however, does not mean that everything will work properly across all WebKit-based mobile browsers. Nor does it mean that WebKit is the perfect representation of the Mobile Web. You should test across as many target platforms as possible based on W3C standards.
The best way to test your mobile HTML5-based application is to use the actual physical device you are targeting (or an emulator). As a service to developers, Max Firtman, the author of Programming the Mobile Web (O’Reilly) does a great job of identifying available emulators and maintains an up-to-date list, which you can find at mobilexweb and preview in Figure 2-6.
Take a few moments to decide which emulator you may need and get ready for Chapter 3. There, you’ll review how to debug hardware acceleration issues, investigate all the available remote debugging techniques, and learn how to work and develop across each browser.
