A Technical Overview of the Mobile Web : THE TECHNICAL CHALLENGES OF MOBILE DEVICES (part 2)

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
8/11/2011 5:10:07 PM

2. Device Diversity

Web developers have been spoiled for years. For almost a decade, most computer users have been surfing the Web using Microsoft's Internet Explorer browser, most probably running on a Windows operating system. Although this browser has been hardly perfect throughout that time particularly in terms of rigorous standards support (and indeed "spoiled" might feel like the wrong adjective!), the prevalence of a single predominant browser had one distinct advantage. Yes, web developers have to work hard to deal with the quirks and strange behaviors of this particular piece of software, but at least they only had to do it once.

Over the last several years, other web browsers have begun to make serious inroads into Internet Explorer's market share. Browsers like Mozilla Firefox, Google Chrome, and Apple's Safari have rapidly increased the likelihood of a given user visiting your site with a non-Microsoft browser. On the whole, these browsers are highly standards-compliant (and Internet Explorer has also improved in this respect), so although there has been an increase in an average developer or tester's workload, this has been incremental, rather than intolerable. Yes, there is an increased diversity in browser usage, but you can still be fairly confident that most of a well-written, standards-compliant web application will function and display more or less equivalently across a range of contemporary browsers.

The situation for mobile web though, as you might have guessed, is a completely different story. There is far more variation in device and implementation of web browsers than you will ever have seen on a desktop or laptop environment, and you quickly discover that diversity — of both a device's physical characteristics and the software that runs on it — is a particularly painful fact of mobile web development life. This has an understandably large impact on the approaches you should take to prepare for, develop, and test the quality of your mobile web applications and services.

You've already seen a range of physical form factors for mobile devices. The most immediate aspect of diversity that strikes a newcomer is the dimensions of the screen. It's certainly true that this alone has one of the biggest impacts on how you design your mobile web applications — particularly if you have expectations of being able to implement "pixel-perfect" designs as you can on a traditional web browser.

Take screen width, for example. The chart in Figure 7 (taken from DeviceAtlas, a comprehensive online database of mobile device characteristics) illustrates the degree to which mobile device screens vary. It plots the number of distinct device models that have various physical screen widths in pixels, on a non-linear X-axis.

Figure 7.

The first thing to notice is the sheer size of the range in screen widths. While you may not feel it necessary to build a site that caters simultaneously for outlier devices with screen widths of 39px and of 790px, the majority of device models still have widths lying between about 100px and 300px — a significant range to adapt your site to.

It's also worth noting that the distribution of screen widths is "bunched" into three main ranges, spanning widths of approximately 100px-140px, 160px-190px, and 220px-320px. You may correctly deduce that these are low-end (or older) devices, mid-range devices, and high-end devices respectively, and certainly newly released devices are also more prevalent at the right end of the chart.

Nevertheless, this is a far cry from a desktop or laptop browser world where screens fall into a small number of distinct sizes and where a single constant page width (say, 960px) would be an acceptable structure for display on most screens.

Apart from the screen and keyboard, other physical characteristics of devices that may affect mobile web design include their ability to be tilted or rotated, whether they accept touch-screen gestures, whether they can emit audio or vibrate, whether they can take images with one or more cameras, and even whether they can detect their own location through cell triangulation or GPS — all underpinned by the browser's ability to actually allow client-side web services to access those physical capabilities.

While physical differences among devices are perhaps the most obvious, you need to take into account many more considerations that relate to their software characteristics. Because the operating system of the device underpins the majority of a user's experience with it, this itself is an important factor. There is nothing yet approaching the dominance across mobile devices of a few operating systems (as seen on desktops and laptops, with Microsoft Windows, Apple's OS X, and various Linux systems, for example). While the race is on to create the mobile world's dominant operating system — particularly among the high-end sector of the device market — the field is still remarkably open and varied.

But most importantly to the mobile web developer, it is the devices' web browsers themselves that are the most significant source of diversity, and this is an area that you need to understand better than any other.

3. Browser Characteristics

Less than 5 years ago, when most mobile devices used their own embedded or simple real-time operating systems, it appeared to mobile web developers as though there were as many operating system versions as there were models of devices. Given that these operating systems tended to contain their own varied browser implementations, with no option for users to upgrade them or install alternatives, the challenge of delivering a reliable web experience to all of them was almost insurmountable. Such browsers were typically very limited, and often derived from their WAP browser precedents, provided limited or incomplete XHTML or CSS capabilities, low-fidelity media support, and little or no opportunity to use JavaScript or AJAX in web pages.

In 2005, Opera, a Norwegian browser manufacturer, launched Opera Mini, a browser that could be installed by the user on such devices and which subsequently has become a very popular third-party browser for older and low- to mid-range handsets. (Opera also provides a more capable browser, Opera Mobile, which runs on high-end devices, primarily those running Symbian and Android.) Using a proxy architecture to compress, adapt, and re-layout the content on behalf of the device, this browser provided the first glimpse that rich and complex websites could be rendered well and made relatively usable on a typical mobile device screen. Figure 8 shows Opera Mini v3 rendering a complex blog site in a way suitable for a simple mobile device. Figure 9 shows the same site rendered in Opera Mobile.

Figure 8.

Figure 9.

At about the same time, Nokia released a new browser for their high-end S60 range of devices that was based on code from the open-source WebKit browser project. Given its desktop heritage, the WebKit engine provided an unprecedented level of support for HTML, CSS, and JavaScript on a mobile device. This was something of a watershed in the history of mobile browsers, and since then, a number of significant mobile device platforms now ship with WebKit-based browsers, including Apple's iPhone, Google's Android, Palm's WebOS, and most recently Blackberry. Microsoft's mobile operating systems do not provide WebKit-based browsers, but the capabilities of their default browsers have risen significantly in recent releases.

Figure 10 shows the same blog site as above rendered by WebKit-based Safari browser on the Apple iPhone. Such browsers have rendering capabilities on par with some of their best desktop brethren.

While the different implementations of each of these browsers can vary radically — device diversity is not going away any time soon — they do at least share a common open-source ancestry. This has helped the cause of efficient mobile web development greatly, because a developer or designer can at least assume a reasonable level of support for image and media support, CSS, and AJAX (although not Flash, video, or vector graphics, which remain variable in their support across browsers).

Figure 10.

Unfortunately, it's easy to forget that not all users are necessarily running the latest and greatest smart phones. Many cheaper handsets still run on embedded operating systems with weak web or WAP browsers, and in certain parts of the world, or for certain demographics, these still can be extremely prevalent. Unless you are absolutely sure that all your target users are going to have a small number of models of WebKit-enabled smart phones, you need to be defensive about how you use more advanced web techniques.

4. Speed and Power

A mobile device manufacturer has to walk a fine line when designing their models. The target size and weight of a device are more or less constrained by market expectations — no discerning customer would buy a 2-pound mobile device to put in his pocket — and yet there are ever-increasing demands placed upon devices by modern radio networks, brighter screens, more powerful cameras, and more complex browsers and applications.

There is, therefore, a balancing act maintained between a device's battery weight and life, its CPU's speed and power requirements, the number of applications that can be run simultaneously, and the screen specifications, among other factors. The means by which a device's manufacturer achieves this balance often has implications for the mobile developer. Apple's iPhone, for example, when first launched in 2007, had a fantastic screen and browser for its time, but supported only the dated GPRS and EDGE mobile data technologies and provided only a single-threaded process model. This meant that web access was slower than on rival devices, sites needed to heavily optimize their content, and users could not run application and browser sessions concurrently. Subsequent models did add faster 3G networking, but it was many years before the device finally offered multi-tasking of applications.

On most devices, battery technology and the heat emission caused by powerful CPUs remain the ultimate constraints upon the capabilities of the device. A desktop or laptop computer using AC power or a large battery can contain power-hungry CPUs and dissipate their heat with spacious, effective cooling systems. A web developer hardly takes these physical characteristics into account, because even a highly graphics- or script-heavy website barely affects the machine's performance.

A typical mobile device, however, has a CPU clock speed of much less than a tenth of a typical desktop computer. Much of the battery power is being used simply to keep the device actively connected to a cellular or WiFi network. And a user does not want to get sweaty hands holding a device that is struggling to dissipate the heat generated by heavy application or browser usage.

To illustrate just how constrained even a contemporary device is, Figure 11 shows relative results of the SunSpider JavaScript benchmarking test suite run on the Safari browser on two different iPhone models. The figures given on the y-axis are the factor slower that these devices run relative to Safari 4.0 on a contemporary MacBook Pro laptop. For instance, the regular expression portion of the test took almost 90 times longer (1.7s) on the iPhone 3GS than on the laptop (19ms), and even basic string and date/time manipulation is 20 times slower. This is a dramatic difference indeed.

Figure 11.

Benchmarks aside, what these constraints mean for a web developer is harder to judge quantitatively. In broad terms, it is obviously sensible to keep the amount of unnecessary or complex client-side processing to a minimum. A computationally expensive animation or video on your website that can't maintain your intended frame rate (and which drains the device's battery life) obviously will not be popular with your users. Large, tag-soup pages will place a processing and rendering load on a device that svelte, well-formed XHTML pages will not. Clever page transitions and graphical effects will falter on devices without accelerated hardware APIs to support them.

Some mobile developers take the approach that a site should cater to the "lowest common denominator" and simply avoid using features that might be challenging for most mobile devices. Unfortunately, users (especially those who have invested in high-end devices) have high expectations, and you should aim to use such facilities when they are feasible. Ultimately, the best understanding of that feasibility, and your practical limitations, comes through testing and examining your sites' performance and impact on real handsets.

Other -----------------
- Parallel Programming with Microsoft Visual Studio 2010 : Task Parallelism - Unhandled Exceptions in Tasks
- Parallel Programming with Microsoft Visual Studio 2010 : Introduction to Parallel Tasks
- jQuery 1.3 : DOM Manipulation - Moving elements
- .NET Debugging : Introduction to the Tools - .NET 2.0—Redistributable & .NET 2.0—SDK
- .NET Debugging : Managed Heap and Garbage Collection
- Context and Interception : Custom Component Services (part 3) - The Transaction Management Service
- Context and Interception : Custom Component Services (part 2) - The Logbook Service
- Context and Interception : Custom Component Services (part 1) - Building a Custom Context Attribute & Installing a Custom Message Sink
- Software Testing with Visual Studio Team System 2008 : Data-driven unit testing
- Software Testing with Visual Studio Team System 2008 : Unit testing an ASP.NET application
- Microsoft Enterprise Library : Error Management Made Exceptionally Easy - Replacing an Exception & Logging an Exception
- Microsoft Enterprise Library : Error Management Made Exceptionally Easy - Diving in with a Simple Example
- iPhone Programming : Connecting to the Network - Embedding a Web Browser in Your App
- iPhone Programming : Connecting to the Network - Detecting Network Status
- Parallel Programming with Microsoft Visual Studio 2010 : Introduction to Parallel Programming - Software Patterns
- Parallel Programming with Microsoft Visual Studio 2010 : Introduction to Parallel Programming - Multicore Computing & Speedup
- Microsoft ASP.NET 3.5 : Web Services for ASP.NET AJAX Applications (part 2) - Consuming AJAX Web Services
- Microsoft ASP.NET 3.5 : Web Services for ASP.NET AJAX Applications (part 1) - Remote Calls via Web Services
- Microsoft ASP.NET 3.5 : AJAX-Enabled Web Services - Implementing the AJAX Paradigm
- The Art of SEO : Measuring Search Traffic (part 2)
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us