Getting Started With Windows Mobile Application Development

Since its introduction the PocketPC operating system has seen five revisions and has been based on three different versions of the Windows CE operating system. Both PocketPC 2000 and PocketPC 2002 were based on Windows CE 3.0. Windows Mobile 2003 and Windows Mobile 2003 2nd Edition were based on Windows CE 4.2. The latest OS Windows Mobile 5 is based on Windows CE 5.0.

Development Tools
In order to development applications for Windows Mobile devices you are going to need an integrated development environment (IDE) that can target the device. The development tools range from free to well over $1000. The latest tool available for "smart device" development is Visual Studio 2005. You can also write applications for Windows Mobile devices using Embedded Visual C++, Visual Studio 2003, and Windows CE Platform Builder. The following Table 1 shows each of the development tools that are available.

Table 1

The Windows Mobile 5.0 platform is the successor to Windows Mobile 2003 Second Edition platform and refers to the class of devices running Windows CE 5.0 and optionally the .NET Compact Framework 2.0. This comprehensive new platform enables Visual Studio 2005 developers to target both Pocket PC and Smartphone devices that run variants of Windows CE operating system. Out of the box, Visual Studio 2005 enables and assists the development of applications for devices running Windows CE version 4.2, but by installing two freely available SDKs, support for Windows Mobile 5.0 and Windows CE 5.0 is now available.

Developing Managed Applications
Managed applications are applications designed around the .NET Compact Framework (.NETCF). Version 1.0 or 1.1 of the .NETCF may be built into ROM on certain devices and version 2.0 is available for installation on a device. Managed applications are not compiled into machine language for a particular process.

Rather, they exist as a set of byte codes for the .NET virtual machine. Managed applications must be developed with either Visual Studio 2003 or Visual Studio 2005.

Figure 1

Developing Native Applications
Native applications are compiled into machine language for a target processor. In the case of Windows Mobile they are compiled for the ARM process (all Windows Mobile devices are built with ARM processors). The native application calls Win32 APIs and class libraries like MFC and ATL directly.

Native applications are more complex to write and more difficult to maintain yet they usually run faster than managed applications. Native applications must be developed with either Embedded Visual C++, Platform Builder, or Visual Studio 2005.

Figure 2

Developing Database Applications
Windows Mobile devices are popular targets for database applications. There are two options for database development under Windows Mobile 5. These are SQL Server CE 2.0 and SQL Server Everywhere 2005.

SQL Server 2000 Windows CE Edition (SQL Server CE) version 2.0 is the compact database for rapidly developing applications in both native mode and the .NET Compact Framework that extend enterprise data management capabilities to devices. Microsoft SQL Server 2005 Everywhere Edition offers essential relational database functionality in a compact footprint ideal for embedding in mobile and desktop applications including a new generation of occasionally connected dynamic applications. SQL Server Everywhere requires the .NETCF version 2.0.

SQL Server Everywhere
Microsoft SQL Server 2005 Everywhere Edition (SQL Server Everywhere) architecture includes both a development environment and a client and server environment. The development environment includes the computer on which applications are developed.

This computer must have Microsoft Visual Studio 2005, including the .NET Compact Framework, to create applications for SQL Server Everywhere. You can create managed applications by using either Microsoft Visual Basic or C#, or you can use Microsoft Visual C++ for Devices, previously referred to as Microsoft eMbedded Visual C++ 4.0, to create native applications. The client environment is made up of one or more supported devices on which the application and SQL Server Everywhere are deployed.

When the devices do not contain network connectivity, you can use Microsoft ActiveSync to connect SQL Server Everywhere to the server environment. The server environment is made up of one or more computers that run Microsoft Internet Information Services (IIS) and an instance of Microsoft SQL Server or data propagated for a heterogeneous data source. You can run IIS and SQL Server on the same computer or configure them over multiple computers. IIS is required to connect to and exchange data between servers and clients.

Figure 3

Writing Today Screen Plugins
A custom Today screen item is simply a DLL that implements a specific interface and is registered in such a way that the Today screen can find it. Each DLL must export one required and one optional function at specific ordinals.

The InitializeCustomItem function (ordinal 240), which creates the child window to display the data, is required for all Today screen items. If the Today screen item supports an options dialog box to allow the user to make changes in what content is shown or how it appears, the DLL must also export CustomItemOptionsDlgProc as ordinal 241.

After the window is created, the Today screen sends WM_TODAYCUSTOM_QUERYREFRESHCACHE to the child window every two seconds to determine whether the displaying data has changed and must be repainted. To minimize repainting of the Today screen, each item should respond TRUE only if the data must be repainted. This is the only time you can update the height of your window. The Today screen no longer sends WM_PAINT to the child window if you set the window height to zero.

When the Today screen application must force all components to refresh their data, it sends the WM_TODAYCUSTOM_CLEARCACHE message with a wParam of the TODAYLISTITEM structure for that Today item. If your component caches data, generally pointed to by the prgbCachedData member of the structure, it should free this memory upon receipt of this message. For Today items that do not cache any data, the WM_TODAYCUSTOM_CLEARCACHE message handler can return 0.

Users can interact with Today screen items, generally by switching to another application and displaying the data that was presented in the Today screen item in that application. The user can then edit or otherwise act upon the data. To facilitate this interaction, Today screen applets should check for the WM_LBUTTONUP message and act accordingly.

In Windows Mobile 2002 software and later, themes, which are combinations of images and color selections, can be applied to the Today screen, so Today screen applets should include code to make their backgrounds appear transparent. You can use the TODAYDRAWWATERMARKINFO structure to do this.

Designing Rotation Aware Applications
Windows Mobile 5 introduced a standard API for handling screen rotation. It's important that your application appear and behave properly in landscape mode as well as portrait mode. The four most practical design approaches are as follows:

1. Dynamically resize the content.
2. Change the content.
3. Change the content layout.
4. Design for a square client area.

Dynamically resizing content to the dimensions of the client area produces the best user experience with the least number of trade-offs. For example, as shown in the following illustration, the Calendar application resizes its grid cells, expanding and contracting them to fit the dimensions of the client area.

Sometimes content and controls fit nicely in one orientation but not in another. One way to overcome this problem is to show less content in the other orientation. For example, the Calendar application displays only eight months, not 12, in landscape mode.

Reorganizing controls within a window might be your only option when you absolutely must have the same set of controls in each orientation. For example, in landscape mode, Windows Media Player displays its buttons to the side of the video clip,

For windows and dialog boxes that contain controls, designing content to fit the visible square common to both portrait and landscape orientations ensures that it displays properly in either orientation without changes. For example, as shown in the following illustration, the content of the Calendar Options dialog box needs no modification to display properly in both screen orientations.

Figure 4

Detecting Screen Rotation
Generally, the user initiates a screen rotation either by pressing the screen rotation program key or by choosing a new screen orientation from the General tab of the Screen application, accessible from the Settings control panel. With each change in screen orientation, Windows CE performs the following actions automatically:

1. Resizes full- screen windows to the new orientation and sends each of them theWM_SIZE notification.
2. Sends top-level windows the Windows CE WM_SETTINGCHANGE message.

The WM_SIZE notification contains a parameter that indicates whether a screen rotation has occurred and it specifies the new client area width and height. To use the WM_SIZE notification to determine whether a screen rotation has occurred, your code should perform a check to determine whether the screen dimensions have been reversed.

If so, you can go ahead and process a block of code that displays the alternate screen layout. Windows CE does not automatically resize windows that are not full-screen. A window is considered full-screen if its top, left, and right coordinates are at or outside the client area boundaries. The client area is the entire screen area below the title bar.

For application windows that are not full-screen, you can use the Windows CE WM_SETTINGCHANGE message to detect and respond to screen rotations.

The Windows CE WM_SETTINGCHANGE message contains a parameter that is set to the value SETTINGCHANGE_RESET when a screen rotation has occurred. To use the WM_SETTINGCHANGE message, your code should perform a check to determine whether the parameter equals SETTINGCHANGE_RESET. If so, you can go ahead and process a block of code that displays the alternate screen layout.

To detect and respond appropriately to a screen rotation, your application window must process one or both of these notifications and then redisplay its contents with an alternate layout that fits the new client area dimensions.

David Heil is chief engineer at CalAmp Solutions Corp.