Taking Advantage of Emulators

When developing an application, you need to act like the user so that you can see what he sees. That means you must test the application for errors and verify functionality on the devices the user is likely to employ. In the past, you might have had to test a couple of types of desktop browsers, and possibly even several versions of those browsers. When you develop an application that targets mobile browsers, however, this testing becomes a significantly bigger challenge. There are numerous form factors to consider, with various methods of connectivity, and browsers are often “burned” into the firmware of the devices. An additional complication is the considerable cost of buying so many devices and the associated connectivity service plans. Fortunately, many browser producers and device manufacturers provide software emulators that make the process of testing a Web application more manageable.

Before scouring the Web for every emulator you can find, you should first narrow the scope of your search by defining your target devices, if you can. In many scenarios you can eliminate classes of devices and thus avoid customizing your application and testing for those devices. For example, consider a mobile application that is built to enable a group of employees better remote access to corporate information. A company might have employees use the PocketPC running Pocket IE, or it might have everyone use a specific type of Personal Digital Assistant (PDA). In a case like this, you wouldn’t need to be concerned about tailoring your application for the cell-phone user. Alternatively, a company might standardize on SIM cards for authentication and predominantly use cell-phone-based browsers. Of course, if your application is targeting the general public, you miss out on the opportunity to focus your efforts so narrowly.

Tip

Use a desktop browser as a debugging aid when developing applications for mobile browsers because debug and tracing information is not included in the output from the MobilePage.

Start with a Browser

Before you focus your efforts on testing with mobile device emulators, use a desktop browser. The desktop browsers are generally more stable than some of the new emulators. They also will be recognized and the HTML adapters will render appropriate markup. You can then move on to testing and refining the application using emulators with the assurance that the core functionality is in place and behaving as expected.

Using a desktop browser also provides for easy application debugging. Tracing functionality is not available for mobile pages when rendered to small form factors. Although debug information from error messages will be displayed in the output adapted for mobile devices, it will be truncated based on the characteristics of the device. There is no reason to forego the more feature-rich desktop browsers when developing a mobile-enabled application. However, user interface decisions that seem fine when viewed on the relatively large desktop monitor might seem less appropriate when scaling to the smaller real estate of the mobile device.

When using emulators to develop a mobile application, you’ll want to get broad coverage for the adapters that you have available. If you’ve installed adapters customized for a particular browser, consider how your development can exercise those adapters as well. Generally, with the adapters that shipped with the Microsoft .NET Framework and the device updates that have been released as of the writing of this book, you’ll want to be concerned with HTML, cHTML, XHTML, and WML. The cHTML family of adapters inherits from the HTML device group, so it might be sufficient to work with the Pocket PC emulator included as part of the PocketPC 2002 Software Development Kit. You can download the Pocket PC emulator from Microsoft at http://msdn.microsoft.com/downloads. The cHTML renderings do not take advantage of client-side script support, so you might want to turn off script support in the settings for the browser. Another way to achieve scriptless renderings during development is to override the capability by including a global match in the web.config file for the application. The web.config file in Code Listing 4-1 will cause your desktop browser to be treated as a scriptless device and receive cHTML from a mobile page.

Code Listing 4-1: Scriptless Browser Configuration Web.config

 <configuration>
    <system.web>
        <browserCaps>
            javascript="false"
        <browserCaps/>
    </system.web>
</configuration> 

The most recent emulators from Openwave, Ericsson, and Nokia all include support for WML and XHTML renderings. You might find that the messages from the different emulators reporting page errors are somewhat cryptic. In fact, the error reporting abilities vary significantly among the emulators. You might find it faster to start working directly with the XHTML or WML that is causing the problem. A quick search of the Web turns up a number of XHTML and WML validators in which you can paste the page output and get relatively detailed error reporting. Often, the source of the problem is the markup you’ve included directly. Since XHTML and WML both require strict XML compliance, you can easily overlook something that renders fine in the HTML browsers, which are traditionally more forgiving when you deviate from the standard. In addition to requiring well-formed markup, WML and XHTML browsers enforce schema validation. The tags used, and even their order or placement and nesting, must comply with the schema supported by the browser. Another approach that can help is to save to a file the page output from the emulator in which you are seeing an error. Then you can load the markup directly from the file into the different emulators and frequently isolate a problem more easily.