Getting Started With Windows Mobile Application Development - Embedded.com

Getting Started With Windows Mobile Application Development

Windows Mobile-based devices, both Pocket PC and Smartphone, are widelydeployed around the world. Much of what drives the popularity of thesehighly portable devices is their rapidly improving hardwarecapabilities. These devices now provide high-quality displays, cameras,increased memory sizes, and powerful communications capabilities thatwere unimaginable not long ago. Windows Mobile 5.0 puts these powerfuldevice capabilities and much more into easy reach of developers.

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

This article is excerpted from a paper ofthe same name presented atthe Embedded Systems Conference Boston 2006. Used with permission ofthe Embedded Systems Conference. For more information, please visit www.embedded.com/esc/boston/

Development Tools
In order to development applications for Windows Mobile devices you aregoing to need an integrateddevelopment environment (IDE) that can target the device. Thedevelopment tools range from free to well over $1000. The latest toolavailable for “smart device” development is Visual Studio 2005. You canalso write applications for Windows Mobile devices using EmbeddedVisual C++, Visual Studio 2003, and Windows CE Platform Builder. Thefollowing Table 1 shows eachof the development tools that are available.

Table1

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

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

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

Figure1

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

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

Figure2

Developing Database Applications
Windows Mobile devices are popular targets for databaseapplications. There are two options for database development underWindows Mobile 5. These are SQL Server CE 2.0 and SQL Server Everywhere2005.

SQL Server 2000 Windows CE Edition (SQL Server CE) version 2.0 isthe compact database for rapidly developing applications in both nativemode and the .NET Compact Framework that extend enterprise datamanagement capabilities to devices. Microsoft SQL Server 2005Everywhere Edition offers essential relational database functionalityin a compact footprint ideal for embedding in mobile and desktopapplications including a new generation of occasionally connecteddynamic applications. SQL Server Everywhere requires the .NETCF version2.0.

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

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

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

Figure3

Writing Today Screen Plugins
A custom Today screen item is simply a DLL that implements a specificinterface and is registered in such a way that the Today screen canfind it. Each DLL must export one required and one optional function atspecific ordinals.

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

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

When the Today screen application must force all components torefresh 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, generallypointed to by the prgbCachedData member of the structure, it should free this memory upon receipt ofthis message. For Today items that do not cache any data, the WM_TODAYCUSTOM_CLEARCACHE messagehandler can return 0.

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

In Windows Mobile 2002 software and later, themes, which arecombinations of images and color selections, can be applied to theToday screen, so Today screen applets should include code to make theirbackgrounds appear transparent. You can use the TODAYDRAWWATERMARKINFO structure todo this.

Designing Rotation AwareApplications
Windows Mobile 5 introduced a standard API for handling screenrotation. It's important that your application appear and behaveproperly in landscape mode as well as portrait mode. The four mostpractical design approaches are as follows:

1. Dynamically resize thecontent.
2. Change the content.
3. Change the content layout.
4. Design for a square clientarea.

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

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

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

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

Figure4

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

1. Resizes full- screenwindows to the new orientation and sendseach of them theWM_SIZE notification.
2. Sends top-level windows theWindows CE WM_SETTINGCHANGE message.

The WM_SIZE notificationcontains a parameter that indicates whether a screen rotation hasoccurred and it specifies the new client area width and height. To usethe WM_SIZE notification todetermine whether a screen rotation has occurred, your code shouldperform a check to determine whether the screen dimensions have beenreversed.

If so, you can go ahead and process a block of code that displaysthe alternate screen layout. Windows CE does not automatically resizewindows that are not full-screen. A window is considered full-screen ifits top, left, and right coordinates are at or outside the client areaboundaries. The client area is the entire screen area below the titlebar.

For application windows that are not full-screen, you can use theWindows 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 screenrotation has occurred. To use the WM_SETTINGCHANGE message, your code should perform a check to determine whether theparameter equals SETTINGCHANGE_RESET .If so, you can go ahead and process a block of code that displays thealternate screen layout.

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

David Heil ischief engineer at CalAmp Solutions Corp.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.