Share via

A Guide to Windows Mobile Programming for Symbian OS Developers

  • Article

 

Matthew Calamatta

September 2005

Applies to:
   Microsoft .NET Compact Framework
   Microsoft Visual Studio 2005
   Windows Mobile version 5.0

Summary: Learn how to help the Symbian OS developer make a transition to programming for Windows Mobile–based devices. This article describes how to produce powerful software on a variety of Windows Mobile–based devices and how to use your existing knowledge to master Windows Mobile programming. (13 printed pages)

Contents

Introduction
Windows Mobile Development Can Make Your Life Easier
Software Tools for Windows Mobile-Based Programming
Types of Windows Mobile-Based Devices
Useful Things You Can Do With Windows Mobile
Conclusion (The Fun Starts Here)

Introduction

This article discusses two modes of development for Windows Mobile–based devices using the terms managed code and native code. Managed code refers to code that is written in Visual Basic .NET or C#; this code has garbage collection, which means that you don't have to worry about memory management. Native code refers to code that is written in C++ that interfaces directly with the Microsoft Win32 environment of a Windows Mobile–based device. Your experience developing Symbian OS applications with C++ will probably make you think about C++ as a first choice of language for Windows Mobile–based application development, but C# and the .NET Compact Framework represent the future.

Windows Mobile Development Can Make Your Life Easier

If you have developed applications exclusively for Symbian OS–based devices, it may be refreshing to see how much easier life is for Windows Mobile developers. Symbian OS is designed with very strict object models and programming paradigms. Good reasons underpin this approach: software that runs with limited resources—memory, storage space, and screen real estate—can't afford to be sloppy, leaky, or memory hungry. As a Symbian OS developer, you know from experience that you are very tightly controlled in what you can do and how you can do it. To make things more interesting, you have probably discovered that developer documentation has been at times patchy, difficult to find, or sometimes merely absent.

As you will discover, Windows Mobile–based application development allows you to transfer your good programming practices into a friendly, flexible environment. One of the most appealing differences when comparing similar projects that are being developed on Symbian OS and Windows Mobile software is the speed of the latter. Windows Mobile developers get results so quickly for two excellent reasons: first, the development tools and operating system are streamlined and harmonized, and second, a wealth of documentation and online support is available for the Windows Mobile developer.

Before this article gets too in depth, the following are a few features that a Symbian OS developer may appreciate about Windows Mobile development:

  • Get your software development kits (SDK), integrated development environments (IDE), and documentation from the same place
    It shouldn't be the developer's job to make a given IDE work with a particular SDK. Nor should you need to look up operating system information from a specific handset manufacturer if the handset is running a standardized platform. With Windows Mobile development, the operating system manufacturer also writes the development tools and the documentation. It's a one-stop shop
  • No cleanup stack
    The Symbian OS cleanup stack gives you peace of mind about memory leaks. This reassurance sometimes comes at the expense of some tricky troubleshooting because the cleanup stack can be a challenging mechanism to fully comprehend. Windows Mobile has no cleanup stack. Instead, you can have the power and responsibility of the new and delete operators by using native Win32 code, or you can have the security and safety of garbage collection with the .NET Compact Framework.
  • No descriptors
    Say goodbye to the red tape and bureaucracy of descriptors with TBufC, HBufC, TBufCbase, and the whole army of classes involved in string manipulation. Say hello instead to real multipurpose string classes, either by way of the .NET Compact Framework, the Microsoft Foundation Classes, the Standard Template Library or the Windows Template Library, in addition to classic C++ string manipulation.
  • Hassle-free on-device debugging
    With Windows Mobile development, on-device debugging is simply a case of plugging your device into your development computer, starting a development environment like Visual Studio 2005, and then clicking the Debug button. If you have struggled with device debugging by using a particular Symbian IDE and a particular SDK from a different supplier, you will appreciate the ease of Windows Mobile device debugging.
  • You don't need a unique identifier (UID)
    You don't need to send an e-mail message to Microsoft to request a UID for your application. Your application will be identified by a provider name and product name. More importantly, your application will be identified by means of a digital certificate, which may have to be approved by a particular network operator. Although some operators will put tighter security on their smart devices than others, you will typically sign your software with a certificate derived from the Microsoft M2M root certificate, which is pre-loaded on the majority of current smart devices. For more information about signing your application with a digital certificate, see the Security and Signing section later in this article.

Common Programming Tasks in Symbian OS and Windows Mobile

Table 1 compares common programming tasks in Symbian OS and Windows Mobile software.

Table 1. Comparison of common programming tasks

Task Symbian OS Windows Mobile software
Write code for a mobile device Use Metrowerks CodeWarrior for Symbian OS, Visual Studio 6 or Borland Mobile Studio Use Visual Studio 2005 for both managed and native code.
Create and use resources such as bitmaps, strings, and dialogs Use a text editor to create .rss files. Use resource editing, which is fully integrated into Visual Studio 2005. What you see in the integrated resource editor is what appears on the Windows Mobile–based device.
Write to a database Use the database management system (DBMS) APIs. For Windows Mobile 5.0, use EDB or SQL Mobile; for prior versions of Windows Mobile, use the native database APIs or SQL Server CE version 2.0
Handle personal information manager (PIM) data Use the Contacts Model API, the Agenda API, and the To-Do List API. Use the Pocket Outlook Object Model (POOM) library to interact with Contacts, Appointments, and Tasks. Each PIM data type is derived from a common object, allowing you to take a common approach for querying and manipulating all three types.
Store temporary or small bits of data, such as application settings or user profiles Output the data to a stream (by using the stream APIs) or save to a file. Use the registry. Windows Mobile provides a complete registry database. You can create keys, subkeys, and values of different types, similar to the way you can on a Windows desktop computer. The registry also contains system areas that you can query.

You can always use files, of course.
Debug by using an emulator Use the simulators that come with the various SDKs. Use Visual Studio 2005: Change your build target to the appropriate emulator, and then press F5. The emulator starts automatically.

With Visual Studio 2005, you can also use ActiveSync to connect to your emulator, so it appears on your desktop computer as an attached Windows Mobile–based device.

Note   To use the Windows Mobile 5.0 emulators, the Windows Mobile 5.0 SDK must be installed.
Debug by using a device Combine IDEs, SDKs, and various transports, such as infrared (IR) and Bluetooth to target your chosen device. Use Visual Studio 2005: Build your code, set your breakpoints, and then press F5.

You can debug over USB or serial cable, or wireless local area network (WLAN)
Deploy an application from a desktop computer Create a .sis file package.

Push the package down to the device by using either IrDA or Bluetooth.

 Create a new Smart Device Cab Project inside Visual Studio 2005.

This project will allow you to create a deployment package by dragging files into target folders and setting up registry keys.

You may need to digitally sign both of the individual files and the installable .cab file.

Register your .cab file with ActiveSync by using a simple .ini file. ActiveSync automatically installs the application to the Windows Mobile–based device the next time it is connected.
Create a desktop computer connector utility between a mobile device application and a server. Use the Connectivity SDK. Create an ActiveSync service provider on the desktop computer and an ActiveSync client on the device or use RAPI, the Remote API.

Software Tools for Windows Mobile-Based Programming

Depending on which version of Symbian OS you target (for example, Series 60 1.0, 1.2, 2.0, UIQ 2.0, or 2.1), you might be using Visual Studio 6.0, Metrowerks CodeWarrior for Symbian or Borland Mobile Studio. You will have searched for the correct SDKs and, in some cases, searched for specific missing header files to get the SDKs to work with your chosen development environment. You will probably have spent some time working with environment variables on your development computer to allow for switching between the various SDKs.

You'll be pleased, in comparison, at the simple choice when deciding which Microsoft family of tools to use: Visual Studio 2005 allows you to develop both managed and native code and target Windows Mobile 5.0–based devices in addition to Windows Mobile 2003–based devices.

The full set of Windows Mobile SDKs will allow you to target both Pocket PCs and Smartphones of all shapes and sizes, including Quarter VGA–sized Smartphones (QVGA) and VGA–sized Pocket PCs.

Contact your software vendor for pricing and purchasing details for Visual Studio 2005.

Types of Windows Mobile-Based Devices

Windows Mobile–based devices, broadly speaking, come in two form factors: Pocket PCs and Smartphones. Windows Mobile–based Smartphones are analogous to Nokia Series 60 devices; they are meant to be used one-handed, have no touch screen, and offer two soft keys that map menu commands. There are subtle user interface (UI) differences, like the use of ClearType fonts on Windows Mobile–based Smartphones and a slightly larger screen (176 x 220 on Smartphones versus 176 x 208 on Series 60). New Windows Mobile–based Smartphones with QVGA, 240 x 320 screens are fast becoming available in addition to landscape Smartphones with QWERTY hardware keyboards (for example the Motorola Q).

Windows Mobile–based Pocket PC Phone Editions parallel UIQ phones with their touch screens and styluses. They have larger screens than Windows Mobile–based Smartphones (240 x 320, but high-resolution Pocket PC Phone Edition devices offer double that density).

Nokia's Series 80, which uses a fixed landscape format aimed at heavier data input scenarios, has no direct parallel in Windows Mobile software, although many Pocket PC models support screen rotation to switch between portrait and landscape orientations.

Note Although there is no direct Windows Mobile parallel to Nokia's Series 80, there are a number of comparable Windows CE–based devices, such as Samsung's Nexio S160 or Dap Technologies' Microflex CE640X.

For useful tips about migrating between Windows Mobile versions, see the Windows Mobile Platform Migration FAQ for Developers.

Screen Orientation and Resolution

Your Windows Mobile–based application has to be both resolution aware and orientation aware. Windows Mobile 2003 Second Edition software brought two eye-catching innovations: screen rotation and screens that have higher resolutions. Any single Windows Mobile–based device can support only a single resolution, although it may support screen rotation. Screen rotation support means that your application must look good and function correctly in both landscape mode and portrait mode, and it must react to the screen being rotated at run time.

An increase in the number of pixels shouldn't necessarily mean putting more things on the screen. Instead, a higher resolution gives you the ability to better render a layout, perhaps by using higher-resolution graphics and larger fonts. Simplicity and clarity should continue to be your UI design goals.

Useful Things You Can Do With Windows Mobile

The following three features on Windows Mobile–based devices have no parallel on Symbian OS:

  • Home screen and Today screen plug-ins
    The Home screen (on a Smartphone) and Today screen (on a Pocket PC) represent the starting point for Windows Mobile–based devices. In addition to applications with dialog views, you can write small programs and dynamic link libraries (DLL) that plug in to the Home and Today screens. Typically, your plug-in will have a simple feature set. It will offer a simple view of some data and will allow the user to react to it. One built-in plug-in shows the user message counts (for example, for text messages and e-mail messages). When tapped or selected by using the directional pad, the plug-in starts Microsoft Pocket Outlook. You can find dozens of custom plug-ins with stock news, weather reports, and device information like remaining battery life. They provide an effective and convenient way of giving the user visibility of important information. You can also find sample projects for both Home and Today screen plug-ins.

  • **Windows Media Player integration
    **With Windows CE version 5.0, you can make use of Windows Media Player to integrate media features into your applications. You could, for example, show the title of the currently playing track on your Home screen, or you could skip to the next song without having to switch to Windows Media Player.

  • Media cards that autoplay
    Imagine an SD card behaving on your Smartphone or Pocket PC much like a CD-ROM behaves on your Windows–based desktop computer. This feature is one of the easiest things to implement on a Windows Mobile–based device. To do this, rename the application that you want to start, such as a software catalog or game, to autorun.exe    , and then copy it into a folder specifically called 2577. (The number is important) Then, copy that folder and its contents to the root of your media card, insert the media card into your Windows Mobile–based device, and your application will automatically start the application.

    Note The number used to name the folder indicates the CPU type that the autorun.exe is targeting. 2577 is the processor code for the ARM–based processor family and, therefore, indicates that the contained autorun.exe is to be used by ARM–based processor devices. In the case of Windows Mobile–based devices, the folder is always named 2577 because all Windows Mobile–based devices have ARM–based processors.

A Smartphone-Savvy Application

On a Windows Mobile–based Smartphone, the controls and fields on a form have to be navigable and usable by the directional pad. The typical UI for a Windows Mobile–based application uses a vertical, top-down layout. More importantly, all controls appear in a single column. Your Windows Mobile–based application should never scroll sideways, especially on a Windows Mobile–based Smartphone. Your Symbian OS experience, especially you are mostly programming with Series 60, will prepare you well because you will already have the mindset for designing simple, single-column layouts.

A typical Windows Mobile–based Smartphone application will have a menu bar at the bottom with two buttons on it. These buttons will map to two hardware keys on the phone, called soft keys. Although similar to the Series 60 soft keys, there is one important difference. The left soft key on the Smartphone should map to the main function in the context of the application (for example, a New button would map to a function to create a new contact when the user views a list of contacts). The right soft key, which is a Back button on a Series 60 phone, is for secondary functions on the Smartphone such as canceling or providing pop-up menus. The Back function on a Smartphone has its own hardware key.

The Back button switches to the next window down on the z-order. That is, the current application's window is hidden, and the previous foreground window is restored. It should be possible to drill down through the last-viewed applications by using the Back button until you finally get to the Home screen.

You can also press the hardware Home key, which brings the Home screen to the foreground and hides the application window. Pressing the Home key on the Smartphone is similar to pressing the Desktop icon on a desktop computer; it causes all non-desktop computer windows to be hidden.

Managed Versus Native Code

When coding for a Windows Mobile–based device, you can use the full power of C++, or the quick results of C# (which also gives you more common code between desktop computers and smart devices). Both options can help you create well-written object-oriented code. You can represent objects, behaviors, and relationships among objects by using classes, Component Object Model (COM) objects, and interfaces.

Complex Behavior Versus Fast Results

Your programming choices depend on the end product. If you want a highly complex user interface (that is, one that relies on non-standard, owner-drawn controls) or you want to override standard system behavior, you may want to use C++. The power of C++, however, means that you must be careful and conscientious with regard to memory management and resource handling.

Although Visual C++ is powerful and provides fast execution, the .NET Compact Framework gives you even faster results, especially when developing forms and dialogs. It is remarkably quick to produce a UI–heavy application by using the .NET Compact Framework. The .NET Compact Framework provides a rich library of easy-to-use functions, particularly for commonly performed tasks like XML parsing and HTTP connections. In addition, the .NET Compact Framework provides an effective memory manager that closely tracks all program memory allocations and efficiently reclaims unused memory through garbage collection. This capability alleviates the need for you to explicitly provide memory management and is especially useful when you're developing for devices that have limited memory.

The .NET Compact Framework is now built into the read-only memory (ROM) of all Windows Mobile–based devices. It simplifies common programming tasks like file interaction, communication, and user interface behavior. In the long-term future of Windows Mobile–based development the .NET Compact Framework should become the focus for developers.

The .NET Compact Framework offers a scaled-down feature set when compared with the full .NET Compact Framework. Typically, developers can use native code to use features that the .NET Compact Framework doesn't have. You can access, however, an excellent online library of extensions to the .NET Compact Framework. OpenNETCF is an example of a vibrant Windows Mobile developer community at work. If you can't implement a feature by using the .NET Compact Framework alone, someone has likely made it possible in OpenNetCF.

For more information, see Introduction to Development Tools for Windows Mobile-based Pocket PCs and Smartphones.

Native Code Development with MFC and WTL

Before managed code arrived, Microsoft Foundation Classes (MFC) were a popular choice for rapid application development using native code. MFC wraps around many of the native Win32 API calls and makes them easier to use. Its main disadvantage is that Windows Mobile 2003–based Smartphones don't support it, which reduces the reusability of your code between Pocket PCs and Smartphones. An MFC–based application also tends to have a larger footprint than a pure Win32 application (that is, one that interfaces directly with the Win32 APIs rather than going through the MFC wrapper classes).

If you want the ease-of-use of MFC without losing the cross-platform code and trimmed down size, you can use the Windows Template Library (WTL). WTL is an open-source project that offers MFC–style rapid application development through a library of template classes. WTL for Windows Mobile software is also a useful choice if you want the power and flexibility of native code with the ease of MFC development without incurring the overhead of MFC.

Note   For more information visit the WTL support forum. To get a copy of WTL, visit the WTL download site.

Memory Management

It is worthwhile to mention two aspects of good memory management on a mobile device. The first is common to all platforms and is a good practice. The second is a useful feature of Windows Mobile–based devices.

First, keep it small and simple. Don't try to harness and manage large, unwieldy data structures in your application memory. Stream off (that is, save to a stream or other persistent data store) what you are not using and work with small, relevant blocks. Good memory management will also lead to better application performance; moving around large chunks of data consumes processor time in addition to battery power.

Second, the.NET Compact Framework garbage collector takes the developer pain out of memory management and lets you write memory-safe code more quickly than ever. The .NET Compact Framework garbage collector keeps track of all allocated objects and safely disposes of the objects that are no longer required. If you are accustomed to carefully tracking the cleanup stack in Symbian OS and making sure that everything that went onto the stack also comes off, garbage collection is a dream come true.

For more information about the .NET Compact Framework and Windows Mobile memory architecture, see Mike Zintel's blog.

When a Windows Mobile–based device is running low on memory, the operating system will send all running applications the specific window messages WM_HIBERNATE and then WM_CLOSE. (WM_CLOSE is analogous to the EEikCmdExit message sent by the Symbian OS to your Symbian application to request that the application should close.) Your application should handle these messages by stripping down to its bare bones, saving state to permanent storage, and then shutting itself down. From the user's point of view, your application should return to the state it was left in the next time it is run. Therefore, it is important to save all temporary data and restore it to the UI when your application comes back up.

For more information about planning for low-memory states, see Handling Low Memory States.

All Windows Mobile-based Applications Are Equal

Unlike Symbian OS, Windows Mobile–based applications that have user interfaces and that run as services have no file type distinction. Rather than .app files and .exe files, on Windows Mobile–based devices, you have .exe files. You can also create and use .dll files as you would on Symbian OS.

Real Windows, Simple Controls

The applications that you create for Windows Mobile software will contain a windows message loop — similar to the message loop on a Windows desktop computer application. The .NET Compact Framework hides the message loop mechanism. With native Win32 development, however, you will be dealing in code with messages that tell you (for example) when the application needs to draw your screen area, when the application needs to close down, and when the application has become active. Unlike the typical Symbian OS scenario, a window based on Windows Mobile software is a window — and not a custom control object. This difference means that you have greater control and flexibility over what to do with your screen elements. There are extensive Win32 APIs to give you full control over user interface elements, whether those are buttons or dialogs, drop-down lists or menu bars.

In Symbian OS, you may need to instantiate and use a handful of objects to control the behavior of a given window element. Then, you may need to use a handful of helper objects to do more. The .NET Compact Framework, in contrast, is helpful in its simplicity. Not only can you move controls onto a form in the IDE by using a drag-and-drop operation, but you can customize the control's appearance by setting property values in the IDE, and you can add control event handling by simply double-clicking the control in the Form Designer and instantly generating the event-handling code.

The Registry

The Windows Mobile software registry database resembles the registry on a Windows–based desktop computer with the important exception of security. On certain types of Windows Mobile–based devices, you cannot modify certain areas of the registry, and you cannot query other areas of the registry. For more information about security models, see the Security and Signing section later in this article.

As with traditional Windows programming, the registry should be used sparingly and for small pieces of data. If you need to store large amounts of data or highly structured data, you can use the file system or system databases.

Databases

You can interact in two ways with databases on a Windows Mobile–based device:

  • Native Database API and EDB
    ****You can use the native database API (called CEDB) to enumerate database volumes, open and manage databases, and manage database records. For Windows Mobile version 5.0, you need to use EDB. EDB Database Support is covered in the MSDN Library.
  • **SQL Server Mobile Edition (previously called SQL Server CE)
    **SQL Server Mobile Edition (SQL Mobile) is a far more powerful option that is ideal for enterprise-class applications, which need greater security and better redundancy. SQL Mobile is the device version of the SQL Server relational database and gives you a secure, reliable data storage solution complete with support for SQL statements and transactions, including (unlike the Symbian DBMS APIs) table joins. In addition to providing a reliable local storage solution for devices, SQL Mobile also provides secure data synchronization with a remote SQL Server instance over a corporate network or public internet connection.

Windows CE 5.0 has substantial revisions in the database system used for PIM data, so be sure to use the POOM API to manage PIM information rather than accessing the PIM databases directly.

Configuration Service Provider

Compared with the myriad configuration APIs on Symbian OS, Windows Mobile software offers a simple, powerful way to configure a device. The Configuration Service Provider (CSP) is an engine that forms part of the operating system. It consumes XML–formatted provisioning messages that can target operating system settings and application settings. For example, with a single block of XML, you could provide General Packet Radio Service (GPRS) settings, create a new e-mail account, and add a digital certificate to the device certificate store. You only need one function call to pass your configuration XML to the CSP: DmProcessConfigXML. You can even package the configuration settings into a special installation file (by using standard Windows Mobile software development tools). Marcus Perryman has a useful blog entry on the subject. By installing this configuration file onto a Windows Mobile–based device, you will then apply all the settings it contains.

Installing Software

When packaging your application with Symbian OS, you would create a .sis file containing your application executables and all required resource files. The .cab file is the Windows Mobile software equivalent of a .sis file and is created using a Smart Device Cab Project wizard in Visual Studio 2005. The end product of a Smart Device Cab project is an installable package–the .cab file.

You can install a .cab file onto a Windows Mobile–based device in one of the three following ways:

  • Opening the .cab file on the device
    Copy the .cab file to the device and open it by using a file manager utility on the device. Windows Mobile software recognizes a .cab file and will automatically try to install it.
  • Through ActiveSync on your Windows computer
    You need to write an additional simple .ini file to register the .cab file with ActiveSync. When a suitable Windows Mobile device is connected, ActiveSync will initiate the installation. This mechanism is helpful when you want to write a desktop computer installer that ultimately installs software onto a Windows Mobile–based device. For more information, see Registering with Application Manager.
  • Over the Air
    Using Pocket Internet Explorer on your Windows Mobile–based device, you can click a URL that points to a .cab file that is hosted on a Web server. Microsoft Pocket Internet Explorer will download the file and the operating system will then assume control and install it.

Security and Signing

Symbian OS or Windows Mobile–based Smartphones are networked computers. As such, a malicious or careless programmer can damage parts of a Smartphone or can use the parts to damage other devices. Traditionally, the Symbian OS suppliers and handset makers have protected areas of the system by hiding the knowledge from developers. This approach is made possible because of the fragmented nature of Symbian OS; each handset maker and other stakeholder can choose to remove and modify core system components. Although unsigned applications on Symbian OS cause a user prompt to appear, the true barrier to malicious code has been this deliberate removal of entire APIs or of supporting documentation. The theory is that what you, the developer, don't know, won't hurt the device or the user. Many developers have searched in vain for a particular way of configuring a system only to be told that they have to pay for the privilege of seeing the related header files (through a variety of paid-for partnership programs).

By contrast, the Windows Mobile software approach to securing the operating system is based on digital certificates. All API calls are fully documented (in a level of detail that will astound hardened Symbian OS developers), but a clearly demarcated subset of APIs may be restricted so that the code won't run unless it is signed by a network operator or handset maker.

Windows Mobile–based devices can have one-tier or two-tier security. In the one-tier security model, an application that has been signed with the appropriate certificate will have access to all parts of the operating system, but without this signature, there will either be a system prompt before running the software or the application will be completely unable to be installed, depending on the device setting for handling unsigned applications.. The two-tier security model protects certain areas of the operating system. Typically, Pocket PCs use the one-tier model, whereas Smartphones use the two-tier model. The manufacturer of a device, in addition to the operator that sells the device, sets the security levels on the device. Some operators ensure that only signed applications can be installed or run on the device. Others choose prompt-level security for most functionality while maintaining high security in certain areas. In this case, when the user is installing and running an unsigned third-party application, the device asks the user to confirm if the user wants to proceed. This behavior is similar to the user experience on, for example, a Nokia 6600.

Use of the Extended Telephony API in two-tier security, for example, requires your application to be signed with a privileged certificate. Only device manufacturers, Microsoft, or operators can use a privileged certificate to sign commercial software.

For more information about the Windows Mobile security models, see A Practical Guide to the Smartphone Application Security and Code Signing Model for Developers or Windows Mobile 5.0 Application Security.

Games

You can use multiple approaches to write games for Windows Mobile–based devices. The most powerful way is to use the Game API, which gives you total control over the display's video frame buffer memory. If your game doesn't require total control over the video hardware, you can draw by handling the Windows paint message.

Windows Mobile 5.0, which is built on Windows CE 5.0, also supports Direct3D Mobile, which will be familiar to you if you have Microsoft DirectX API experience on desktop computers. The .NET Compact Framework now also gives you managed Direct3D development; see Mobile Direct3D Programming for more information.

For more information about game development and Windows Mobile, see the following articles:

The Windows Mobile operating system is a powerful and welcoming platform for game development. If you have been making games for Symbian–based devices, however, you may ask the following question: "Where's My Java?"

Most of the current Windows Mobile–based Smartphones have third-party Java Virtual Machines pre-installed. These applications allow users to download and run Java MIDlets on the Windows Mobile platform. You can use a Windows Mobile–based device to test your earlier Java applications. Actual Java development, however, is outside the scope of this article.

Conclusion (The Fun Starts Here)

There are some Symbian OS developers who believe that Symbian OS's sharp learning curve is what makes it attractive as a career option. Because it's hard to do, fewer people do it; because few people do it, they're always in demand. I believe many other developers have a far more positive opinion about software development, namely that it should be fun and rewarding in more ways than financial. If you have had experience with the challenges of Symbian OS development, moving to Windows Mobile software will be a delight. Even better, the discipline and organization instilled by Symbian OS development will serve you well in getting the best out of Windows Mobile. You can achieve so much more with much less hassle.

Find Out More

The following list contains useful Web sites where you can find tips, read the latest news, and communicate with the vibrant Windows Mobile community:

Note The presence of a third-party site in this list does not imply Microsoft endorsement of the site.

The following print resources, published through Microsoft Press, provide further information:

  • Microsoft .NET Compact Framework (Core Reference) by Andy Wigley, Mark Sutton, Rory MacLeod, Robert Burbidge, and Stephen Wheelwright
  • Programming Microsoft Windows CE .NET, Third Edition, by Douglas Boling

You can also post questions to the active developer newsgroups to access a large pool of participants with Windows Mobile expertise. Two key newsgroups are the Smartphone developer newsgroup (microsoft.public.smartphone.developer) and the Pocket PC developer newsgroup (microsoft.public.pocketpc.developer).