As we have discussed in the past two issues of Wireless & Mobile UPDATE, dynamic wireless applications are well suited to development with server-page technology such as Active Server Pages (ASP). Here are some tips to help you develop and debug the Wireless Application Protocol (WAP)/ASP wireless applications.
To develop and test WAP applications, use a phone emulator/simulator. Emulators look like phones, run on computers, and accurately represent wireless application displays and interactions between the user and the application. Motorola, Ericsson, Nokia, Openwave, and other vendors offer WAP emulators and wireless software development kits (SDKs). Simulators can be configured to use development/production WAP gateways, but they usually function without gateways, too. I use the Openwave Simulator, currently the UP.Simulator version 4.1. It lets me connect directly to the WAP application over HTTP, but for final application testing, I use the WAP or UP.Link gateways.
The UP.Simulator information window displays information about URL requests, deck compilation, and errors. It also returns useful data about net/cache hits and the size of uncompiled and compiled decks. Deck size shouldn't exceed 1.5Kb; if it does, device errors will occur.
Develop a static Wireless Markup Language (WML) template of the deck and cards, as you might when you develop HTML. Test the template until you're satisfied with it, then begin developing the ASP parts of the application.
While you develop the WML template and ASP application, turn off content caching by using the following WML code in the head of the WML deck.
While you develop the WML template and ASP application, turn off content caching by using the following WML code in the head of the WML deck.
<head> <meta http-equiv="Cache-Control" content="max-age=0" forua="true" /> </head>
This code prevents the simulator and test devices from using cached content, making the device connect to the Web server for every test and get the latest content. During development and testing, it's important to make sure the device executes and displays the latest version of the code.
When you deploy the application, change the content maximum-age value to a higher number (e.g., 3600) to let the device cache content that remains fairly constant. This technique improves application performance.
Two types of errors frequently occur during the development of dynamic wireless applications: WML compilation errors and ASP compilation and runtime errors. WML syntax problems cause most WML compilation errors, which can crop up even if you've developed your initial WML template and use it with ASP to develop the application.
Fix WML compilation errors by first examining the source of the error. View the UP.Simulator information window to find the problem—it shows all the WML code and describes WML compilation issues. ASP errors usually show up as WML compilation errors; if an ASP error occurs, the ASP engine describes the error in HTML code (i.e., database connection), which is inserted into the WML deck and produces syntax problems.
If an ASP-related error eludes you despite your careful examination of the UP.Simulator information, try this handy trick. Comment out the Response.ContentType = "text/vnd.wap.wml" code and run the ASP page with appropriate variables in a regular Web browser. This process reveals ASP errors more clearly than do emulators or real WAP devices. Debug the ASP problem and use the WAP content type again. Finally, retest using the simulator.
In the next Wireless & Mobile UPDATE, I'll discuss more development techniques and give additional tips and tricks for developing dynamic wireless applications with ASP.
