Get a "head start" on preparing your mobile application to function properly with Windows Mobile 5.0 and the Compact Framework 2.0. Discover the new features and functionalities available to Pocket PC and Smartphone applications and explore changes that could affect performance and usability.
Windows Mobile developers have had much to be excited about in recent weeks. With the release of Windows Mobile 5.0 to device manufacturers, there are a number of new features and functionalities made available to both new and existing (if upgraded) Pocket PCs and Smartphones. The .NET Compact Framework 2.0 is expected to be available in conjunction with the release of Visual Studio 2005, expected for release on November 7th and currently in beta. While there are a number of opportunities for Windows Mobile developers based upon these two important announcements, there is also a lot to consider.
For most application developers, the move to new versions of a development tool, technology, or operating system brings with it the challenges of compatibility. Usually, there are the critical concerns over whether an application can even run in the new environment, followed by changes that affect performance and usability. For Windows Mobile developers, these concerns are quite valid. Changes to the .NET Compact Framework 2.0 can pose some problems for any existing applications, while Windows Mobile 5.0 poses some additional issues. The first part of this article will break down some of the major considerations for migrating your applications to the new version of the framework, allowing you to get a "head start" on preparing your application to function properly when Windows Mobile 5.0 and the Compact Framework 2.0 are generally available.
The Compact Framework 2.0
The best place to start in understanding impacts on your existing Windows Mobile applications is with some general changes to the .NET Compact Framework in Version 2.0. These changes might seem minor at first, but they can have a significant impact on your application's behavior.
Windows Mobile 2003 Second Edition introduced native support for screen rotation, allowing applications on a Pocket PC or Phone Edition to be viewed in either portrait or landscape orientation. As a developer, you had the ability to write C# or VB .NET application logic to determine screen orientation and rearrange objects within a Windows Form programmatically. You also could just leave the code unaltered, and default behaviors within the runtime environment would automatically add scrollbars to forms when needed to allow the user to have access to all objects on the form. This "legacy screen emulation mode," as Microsoft refers to the behavior in the Windows Platform Migration FAQ (http://msdn.microsoft.com/mobility/windowsmobile/default.aspx?pull=/library/en-us/dnppcgen/html/migration_developers_faq.asp#migration_developers_faq_topic34), is no longer supported in Visual Studio 2005 or the Compact Framework 2.0. What this means to you as a developer is that your users changing the screen orientation from portrait orientation to landscape may not be able to access all objects within a given Windows Form. Fortunately, there are some relatively painless solutions to this issue.
You can change the AutoScroll property for a Windows Form to be true either at design-time or runtime for your application. Figure 1 shows the Property Sheet for a Pocket PC Windows Form in Visual Studio 2005.
Figure 1: AutoScroll property for a Windows Form
This would provide a "front-line defense" for your application's form to enable basic usability.
Another (and more granular) option introduced in the .NET Compact Framework 2.0 is the use of the Dock and Anchor properties available to user interface objects. If you have developed Windows Forms applications for the full .NET Framework, you are probably already familiar with these properties. Anchoring an object allows you to set the relative X and Y co-ordinates for an object in relation to their parent container (in this case, a form) such that regardless of the parent object's dimensions, the user interface object will adhere to this relative positioning. Docking a user interface object goes a step further by resizing the object based upon the dimensions of its parent container. Once again, these properties can be changed at both design-time and runtime. Figure 2 shows a button object's property sheet with the Dock and Anchor properties displayed.
Figure 2: Dock and Anchor properties
The Dock and Anchor properties provide a very solid and easy to implement solution for dealing with screen orientation-awareness and usability.
Another legacy behavior that has been removed from Visual Studio 2005 and the Compact Framework relates to VGA-enabled devices. A VGA device can support higher-resolution graphics than a standard QVGA screen, as well as increased screen real estate. To support legacy applications, a technique known as "pixel doubling" was employed. It essentially doubled the pixels of objects running on a VGA device for the display (and object positions) to match that of a QVGA device. Prior to Visual Studio 2005, a developer who did not want this behavior to occur actually ran a separate command-line utility (hires.exe) against their application to allow the application to be visualized as they had written the code.
If you expect your application to be run on VGA-enabled devices, you will have some serious design decisions regarding migrating to Visual Studio 2005 and the .NET Compact Framework 2.0. Although docking and anchoring can still help you with this issue, the fact that graphics will now display at half the size of their QVGA counterparts might pose a readability issue for end users. There are programmatic options available to you, including:
- Writing application logic to determine screen resolution
- Using multiple sets of images, supporting both QVGA and VGA, and loading the images at runtime
- Changing font sizes based upon screen resolution
- Changing object positions within a form based upon screen resolution
The easiest way to determine screen resolution at runtime is by using a new property available to Windows Form objects, the CurrentAutoScaleDimensions property. This property returns a SizeF structure (from the System.Drawing class) which then can be queried. The following C# code provides a basic example:
SizeF currentScreen = this.CurrentAutoScaleDimensions;
if (currentScreen.Height == 192)
// Your VGA device logic here.
The Height property contains the Dots-Per-Inch ("DPI") of the current form. 96 is the DPI of a QVGA screen, whereas 192 is DPI for a VGA screen.
The Windows Mobile 2003 Second Edition Resource Kit (http://www.microsoft.com/downloads/details.aspx?familyid=6a34dc83-c3ce-4a4c-ab83-491fd5729551&displaylang=en) and the MSDN Mobility and Embedded Developer Center (http://msdn.microsoft.com/mobility) both have useful information regarding how to programmatically deal with resolution-awareness in your Windows Mobile applications.
Menus and Pocket PCs
Smartphone developers have long been used to a specialized menu system for Windows Mobile applications. The soft key menu system provides the user with menu access without the need of a stylus. Users instead use specially mapped keys to activate and navigate to proper menu items. Starting with Windows Mobile 5.0, soft key menu functionality has been extended to Pocket PC and Pocket PC Phone Edition devices.
To enable soft key functionality, the main menu bar for a given menu structure must have either one or two menu items. Figure 3 shows a menu for a form with two menu items added. The figure also points out the associated key mappings to the menu items.
Figure 3: Soft key menu for Windows Mobile 5.0 Pocket PC
When working in Visual Studio 2005, the menu editor behaves in a fashion similar to Visual Studio.NET 2003, with the only difference being the layout of menu items in relation to the soft key functionality. Editing of menu items occurs in the same way as before, as seen in Figure 4.
Figure 4: Editing menus in Visual Studio 2005
When adding a third menu item to the main menu bar for a Windows Mobile 5.0 application, you will notice something quite different suddenly displays. The menu bar reverts back to the traditional menu style for Pocket PCs! Figure 5 demonstrates this change.
Figure 5: Menu bar reverting to "classic" Pocket PC style
As a Pocket PC developer, this behavior provides a sort of "good news/bad news" scenario for your application. The good news—existing .NET Compact Framework applications can be migrated to Windows Mobile 5.0 without having to change the menu system. The bad news—soft key menus are an expected behavior and functionality for Windows Mobile 5.0 Pocket PC users. To be truly compatible with the platform, you should strongly consider migrating any "old" menus to take advantage of the soft key functionality.
If your application is based on ADOCE and CEDB databases for data storage, you should be aware that the ADOCE runtime is no longer part of the ROM image in Windows Mobile 5.0. ADOCE and CEDB have officially been deprecated. According to the Windows Mobile Platform Migration FAQ for Developers (http://msdn.microsoft.com/mobility/windowsmobile/default.aspx?pull=/library/en-us/dnppcgen/html/migration_developers_faq.asp), an ADOCE runtime and ActiveSync Service Provider will eventually be made available as a separate download and install. Considering that it is unlikely that future Windows Mobile versions will provide even this level of support, now would likely be a good time to consider migrating your application to SQL Mobile and ADO.NET as your data solution.
Pocket Outlook/MAPI Access
Prior to Windows Mobile 5.0, you may have used P/Invoke functionality to directly access stored data for Contacts, Tasks, and Appointments in your .NET Compact Framework application. The underlying data storage for this information was CEDB. This, too, has changed for Windows Mobile 5.0 and will require you to make changes to your application logic. There is, however, a "silver lining" to this dark cloud; the .NET Compact Framework 2.0 provides a set of managed classes (in the Microsoft.WindowsMobile.PocketOutlook namespace, as shown in Figure 6) that should make the transition somewhat smoother. This namespace also contains classes for the interaction and manipulation of messages (E-Mail and SMS), allowing you to migrate or extend your applications to support messaging functionality.
Figure 6: The Microsoft.WindowsMobile.PocketOutlook namespace.
It is important to note that this namespace is only available for .NET Compact Framework applications that are targeted at Windows Mobile 5.0 devices. If you intend to support Pocket Outlook (now referred to as "Outlook Mobile" for Windows Mobile 5.0) access across operating systems, you will need to maintain separate Visual Studio 2005 projects for this purpose. Fortunately, Peter Foot of In The Hand Ltd and a Microsoft Most Valuable Professional ("MVP") for Windows Embedded has announced Windows Mobile In The Hand, a set of managed APIs that duplicate the Windows Mobile 5.0-specific classes for earlier OSes. You can find out more at Peter's Web site: http://www.inthehand.com.
The Windows Mobile platform has long supported the concept of application signing and trust for Smartphone devices. Starting with Windows Mobile 5.0, this model has been extended to Pocket PC and Pocket PC Phone Edition devices. Fortunately, the behavior for unsigned Pocket PC applications is slightly different than the Smartphone.
If you package a Pocket PC application for Windows Mobile 5.0 devices without a certificate, the user will be informed that they are about to install an unsigned application during the installation process. They can either continue with the installation or abort. By comparison, Smartphone applications' handling of unsigned (and even signed) applications is determined by device configurations that can be implemented by the hardware manufacturer, a cellular carrier, or both. Whether or not you implement application signing for your Pocket PC applications is up to you. Typically, if your application is for "in-house" use, the need to purchase a digital certificate and sign your application is not a priority. If you are selling your application through commercial channels, however, the issue of consumer perception of an "unsafe" application lacking in proper credentials might impact sales.
Microsoft does provide a wealth of information and resources regarding application security and signing at the MSDN Mobile and Embedded Developer Center (http://msdn.microsoft.com/mobility) and the Mobile2Market program home (http://msdn.microsoft.com/mobility/windowsmobile/partners/mobile2market/default.aspx).
Exploring New Managed APIs
In addition to the Outlook Mobile managed APIs mentioned earlier, there are a number of additional new managed APIs available in the .NET Compact Framework 2.0, including:
- Configuration Manager
- State and Notification Broker
- Picture Selection Dialog
- Camera Capture API
There is far too much to go into detail in this article. I will, however, go into far more detail in upcoming articles. This should not stop you from starting to explore these new managed APIs and to see whether you can use them to your advantage in your Windows Mobile 5.0 applications.
With there still being some time until Windows Mobile 5.0 and the .NET Compact Framework 2.0 become widely available, planning and preparing early can provide you with the ability to deliver your migrated Windows Mobile 5.0 application in a timely and effective fashion.