MSDN Magazine - June 2008 - (Page 127)

MichAel SAFFitz GoinG Places Adaptable Apps For Windows Mobile When Microsoft first shipped Pocket PC 2000, and for a few years following, developers could relatively easily write one application that ran well on all devices. Generally, all devices had the same capabilities and characteristics: touch support, screen resolutions, portrait orientation, API sets, and so forth. Consequently, you could focus almost exclusively on your application’s functionality. You didn’t need to worry about these other elements of the device, and you definitely didn’t need to worry about the potential that they could change. But change is inevitable. As the market and technology developed, more and more devices became available, and these devices started to have divergent designs. Fast forward to 2008 and there are now more than 140 different Windows Mobile® phones available that support a variety of different options—12-key and QWERTY keyboards; candy bar and clam shell styles; with and without GPS; square, portrait, and landscape screens; Wi-Fi, Bluetooth, and infrared communications; and other capabilities that vary from device to device. Unlike Pocket PC 2000, it’s now much easier for customers to find a device that matches their needs, tastes, and budget. I’m going to show you some of the tools and techniques that developers can use to build adaptable applications. I’ll look at some general design and architecture principles and then dig into the specifics around adapting to differences in screens and capabilities. While there’s certainly some additional care and consideration that must be taken when you choose to build an adaptable application, the benefits of the upfront investment often far outweigh the alternative: developing and testing a version of your application against every current (and future) device, or electing to not support a device and, thus, limiting your potential user base. Design and Architecture Adaptable Applications This growth in the diversity of Windows Mobile devices, however, has made it necessary for developers to be aware of these differences and to plan for them in their applications. Developers now need to build what are called adaptable applications—apps that work well and look great on all Windows Mobile devices. Fortunately, as an operating system, Windows Mobile offers one of the most consistent core API sets of any mobile platform across devices. Windows Mobile developers will find the same core API set (designed in many places to match those found on the desktop) regardless of the device’s mobile operator or hardware manufacturer. As a result, most developers building adaptable applications will find that addressing different display resolutions, dots per inch (DPI), and orientations will be the predominant area of focus. For a smaller number of developers, differences in device capabilities (such as presence of telephony, GPS, and so on), API changes between major releases of Windows Mobile, and designing to target both touch and non-touch devices will also be areas to consider. Developers need to build apps that work well on all Windows Mobile devices. When building adaptable applications, following time-tested practices and good architectural patterns is essential. From a practices perspective, by carefully and explicitly identifying your requirements, you can begin to understand the minimum device profile that your application needs. You’ll also identify the optional capabilities that, when present, your application can use dynamically. In taking this approach, you can be sure that your application runs on the largest number of devices without having to code to the lowest common denominator. As a brief example, let’s say that I have been asked to build a simple package delivery tracking application. I investigated my requirements and determined that I need to collect signatures to indicate that a package has been successfully delivered. As a nice-to-have feature, the application should upload package status to a server for online tracking. As a result of the need to collect signatures, my application will be limited to touch devices (Windows Mobile Professional and Classic). Having identified this, I’m now free to use the additional functionality requiring touch (such as the button control). At the same time, I should be careful about architecting the connectivity components. If I assumed my application would have access to cellular data connections, for example, I would unnecessarily eliminate Classic devices that don’t contain a phone but could have Wi-Fi. Finally, you should note that if my client changes her mind and Send your questions and comments to goplaces@microsoft.com. June 2008 127

Table of Contents Feed for the Digital Edition of MSDN Magazine - June 2008

MSDN Magazine - June 2008 Contents Toolbox CLR Inside Out Cutting Edge Patterns In Practice SAAS Concurrency Robotics Form Filler GUI Library Service Station Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.