In this column, we continue our discussion of tips and tricks for implementing dynamic wireless applications using Active Server Pages (ASP) and Wireless Markup Language (WML).

As we previously discussed, compiled Wireless Application Protocol (WAP) decks can't exceed 1500 bytes in size. What's the best way to meet this criterion? Your options include limiting the number of cards in a deck or limiting the amount of data returned and displayed in a single card. When you design the wireless application, think about ways to organize the decks and cards.

After the last column, a reader asked about the best way to limit the number of records in the deck. I currently limit the number of records in a deck by paging through the recordset and displaying 20 records at a time. I code this paging functionality with VBScript within the ASP page. As an alternative, a number of database components help to manage recordsets. If you have another idea, let me know and I'll mention it in a future column.

Here's another tip: Put application logic in ASP functions and/or COM objects. This method lets you use existing business logic and reuse code among Web, wireless, and eventually voice Internet applications. For example, encapsulate database connection strings and logon details in a COM object on the server. This general programming idea increases in importance as enterprises create more applications for multiple device types.

You might come across other issues as you develop and implement WAP applications. For instance, the best approach is to use HTTP GET commands instead of POST commands for returning information from the wireless device to the server for processing. The POST commands work with most devices, but on some devices, variables disappear.

In addition, the functionality of Wireless Telephony Application Interface (WTAI) lets you make a voice call from the WAP application. WAP typically provides this feature—unless you try to use it with Nokia's 7100 series, where it fails. If you want to keep track of specific difficulties such as this one, and how people are working around them, I suggest you subscribe to one of the many wireless and WAP list services on the Internet.

When you near completion of the wireless application, test it, test it again, and test some more. You can use WAP device emulators and simulators, as I mentioned in my previous column, to test the wireless application during development. But before you deploy the WAP application, test it with real target devices to ensure that the application behaves as intended. Even though WAP devices support WAP, your application's success can vary greatly depending on WML features and the WAP microbrowser's interpretation of the application. If you intend to release a WAP application for public use, first test it with as many real WAP devices as possible.

In my next column, I'll continue with these tips and tricks for developing dynamic wireless applications with ASP. I'll also look at some ideas for deployment.