Publishing is probably the most complicated element of the Mobile Web. People from the desktop Web development community need to adjust their view when developing for the Mobile Web. Luckily, publishing to the Mobile Web does not have to be complicated. There is plenty of room in-between the simple and the complex for any developer and any project to find a home.
While it is easy to segue into the inner workings of device detection of the differences in browser rendering, in this section we focus on establishing a reasonable development baseline and easy ways to begin mobile publishing.
Supporting devices and browsers can be difficult and time consuming Every year, the industry sells hundreds of different mobile device types/variants worldwide. Mobile service providers often customize mobile browsers on their devices, creating a large number of different deployed browsers. As a rough guide, every major browser version has a lifetime of approximately 50 different device models, with various minor revisions. Since most devices don’t allow over-the-air updates, faulty devices can’t receive regular upgrades leading companies to pull them from the market and replace them with a new version. This typically includes a revised version of the browser, perhaps exacerbating the problem.
Most mobile service providers recommend supporting devices for two years, a difficult task.
Supporting devices and browsers is a major concern for many developers from the Web community accustomed to dealing with differences in multiple Web browsers.
While supporting multiple mobile devices and browsers gets complex, the situation is not as bad as many believe. This belief comes from looking at the mobile browser landscape in the same way as desktop Web browser landscape.
Consider the following points:
One way to approach this problem is to focus on five classes of devices that span a range of capabilities. Of the hundreds of devices available, supporting five mainstream devices makes a great place to start. Obviously supporting more devices ensures greater compatibility with more devices and developers should always endeavor to do this, but supporting five devices disparate devices can do the job.
Here is an example:
Mobile pages are just Web pages published to any Web server. Nevertheless, it can be problem a problem getting mobile users enter the URL for your site.
The following options are some of the ways getting users to access a Mobile Web site:
For more information on how to structure your site, when to redirect the user to a separate mobile-only only site, see Chapter 9. Going further with Adaptation
The .mobi top-level domain is the ICANN approved top-level domain specifically for mobile devices giving publishers the option to use an alternate domain for their mobile site. Instead of using device detection, sub-domains or directors, mobile users go to example.mobi. Much like the sub-domain approach, dotMobi sites sometimes use a separate server or virtual host, separating desktop sites from mobile sites on the same server.
If you own a dotMobi domain, you can route all traffic to it using device detection or server redirects.
The sub-domains approach to publishing, similar to server directories, lets you publish a mobile site to a location on your server, mobile.example.mobi, wap.example.mobi or m.example.mobi, for instance.
Since most servers treat sub-domains as separate Web sites with a unique root directory and server directives, this approach is convenient for your Mobile Web site because it keeps desktop and Mobile Web sites separated.
It’s possible to redirect traffic from a server directory to sub-domains to give the user easier access while taking advantage of separated environments. For example, entering example.mobi/mobile redirects the user to example.domain.mobi
The Internet Media Type – better known as MIME type – is an Internet standard for indicating the format of a message. It is used extensively in many Internet protocols. In the context of the Web in particular, it’s used as part of the HTTP protocol to help the browser understand how to parse and render content that it receives.
For each request made from a browser to a Web server, HTTP requires that the server includes a Content-Type header identifying the format of the response. Upon receiving this Content-Type header, the browser can decide how to decode the response and render it in an appropriate form.
In the mobile context, the server sends MIME types to the mobile browser. Many Web servers, by default, do not have the correct MIME types defined for mobile markup standards. It is important set up the Web server to serve the right Content-Type headers for mobile markup languages. At best this may cause the browser to render the page more slowly; at worst your pages may be unreadable or result the mobile device to produce an error message.
Use the value
application/xhtml+xmlfor all recommended mobile content types (XHTML-MP and XHTML Basic).
Testing is an vital component of mobile publishing. Mobile testing is a big job considering the many devices and the differences in how content renders on the device. Fortunately, simple testing methods exist for testing your mobile Web site.
One tip before beginning: Create a simple page on the development server containing links to the URLs for the sites you plan to test. Bookmark this site on each device used in the test. This way you avoid having entering URLs into the devices many times over.
<iframe src ="mobile/index.html" width="240" height="320" style="border:1px solid;"> </iframe>These steps create a reasonable representation of a mobile device on the desktop. You can even go as far as to wrap the frame with an image of a phone for further realism.When using advanced device detection methods, Firefox – with help from the User Agent Switcher extension – lets you change the User Agent HTTP header you send to the server. Once you add the data from the supported mobile user agents, you can test how each of your sites displays.
Other helpful all-purpose extensions for Firefox are the Web Developers Toolbar and Firebug (which provides very useful XHTML and CSS debugging).
Another method of testing a mobile site is to use a phone emulator. This is typically a desktop or Web-hosted application that mimics the device experience for a particular device or class of devices. The accuracy of phone and browser emulators vary from a perfect mimicking of the browser rendering to rough approximations.
While an emulator does not replace testing on an actual device, they are a very useful tool during development to do quick verification of how your code displays without loading it on a real mobile browser. Note that regardless of how perfectly a browser mimics the rendering of page on a real device, they can’t reproduce the overall experience of using a real device, since factors such as network speed and latency are involved. For this reason, emulators are a very useful step in any testing program, but should never be used to replace real device testing.
While getting access to devices, networks and the right data plans is a challenge, the outcome is worth the struggle.
Other methods of testing are very useful, but nothing represents the final experience better than testing on a real mobile device during the development process, since this best recreates how the user will interact with your site.
If you have only one device, borrow phones from friends and family. Talk to vendors that may let you rent phones or use their device lab. If you don’t have access to a vendor in your area, try going to a mobile service provider store and use the display phones for testing.
Prepaid SIM cards from multiple mobile service provider networks can be a developer’s best friend. Switching prepaid SIMs allows you to test on multiple devices across multiple n
Remote access services let you control an actual device remotely through your desktop. DeviceAnywhere is one of the few examples of such a service. The application taps into the actual device, which you rent through the company’s software. It supports most of the devices sold in North America and Europe.
Remote access provides a compelling method for testing and has the added convenience of a desktop emulator as well as showing the displayed characteristics of the actual device. Although it doesn’t replace the tactile lessons learned from using the real device, it’s a solution for small publishers with limited resources. It deals with the problem of testing on many devices some of which are not supported by networks in their own countries.