In the March 6 and March 20 editions of Mobile & Wireless UPDATE, I looked at some of the key features and functionality of the Microsoft .NET Compact Framework. (To access these two Mobile & Wireless Perspectives columns, see the URLs at the end of this paragraph.) This time, I want to continue this discussion by looking at best practices for using the Compact Framework to develop and implement mobile solutions. I also want to consider some developer and deployment ideas. As I discussed in the March 20 edition, the development of Compact Framework applications is best accomplished through Microsoft Visual Studio .NET 2003, which offers visual IDE and automated development functionality.

Debugging Debugging helps you identify and diagnose problems with the application during development. Best practices for debugging follow: - Use a real device. Although Visual Studio .NET 2003 has built-in Pocket PC and Windows CE emulators, the most efficient way to debug and test your application is on a real device that has a Wi-Fi (802.11b) connection from the development machine to the device. A Wi-Fi connection is much faster than physical or emulator connections. - Debug applications in chunks. Every time you enter debug mode, deploying the code to the device or emulator takes time. Debugging several features at once, in chunks, is more efficient. Also, you avoid deploying code for every change you make. - Include system.scr assemblies when you're in debug mode. Doing so lets you capture any runtime exceptions as strings, and resulting error messages can then be presented in a message box within your application. - Include an exit button. When you're designing a Pocket PC application, including an exit button is against Pocket PC application design principles because of the limited form factor. For debugging, however, the ability to completely stop the application from running is beneficial, so you might want to include an exit button.

Data Access Most Compact Framework applications require the ability to capture and review data in various forms. Best practices for data access follow: - Use ADO.NET data sets. Using data sets when you manipulate data on the device requires less coding. - Partially normalize the existing database schema. If you're starting with an existing server database schema for storing data in Microsoft SQL Server 2000 Windows CE Edition, combining data into fewer tables with a simpler schema (i.e., normalizing) on the device is a good idea. Doing so lets you perform database commands without needing to make complex joins. The result is enhanced performance.

Performance Tuning Tuning helps you improve the performance of an application's various parts. Without some level of performance tuning, applications might be too slow for effective use. Best practices for performance tuning follow: - Avoid highly complex UI features. The more features you have on one Compact Framework form, the more time will be necessary to load and display the form. - Avoid excessive function calls. Although using functions to code application features is typically a good practice, calling multiple functions can slow the application. - Use asynchronous processing and multithreading. Doing so lets you offload some of the processing into the background. The user can then continue using the application while processing occurs. - Assume the device is disconnected. Avoid making too many realtime server requests, trusting that connectivity (e.g., the wireless connection) is a given. If a user has a problem connecting, he or she will be kept waiting. Best practice is to synchronize required data to the device, then use that data offline.

In the next Mobile & Wireless UPDATE, I'll finish my overview of Compact Framework best practices, with a look at usability and deployment considerations. If you've been working with the Compact Framework, I'd like to hear about some of the best practices you've developed. Email me at