What's New for Developers in Windows Mobile 6
4/27/2007
Jim Wilson, JW Hedgehog, Inc.
February 2007
Understanding Windows Mobile 6 Naming Conventions
Strong Windows Mobile 5.0 Compatibility
Simplifying Application Development
Simplifying Application Deployment
Building One Application That Runs on Many Devices
What You Need to Starting Building Windows Mobile 6 Applications
If you're not familiar with Windows Mobile 5.0 or you would like a Windows Mobile 5.0 refresher, please have a look at What's New for Developers in Windows Mobile 5.0. The features, tools, and APIs that the What's New for Developers in Windows Mobile 5.0 paper discusses apply equally to Windows Mobile 6.
This paper explains the new Windows Mobile 6 features and their purpose from a developer's perspective. This paper also explains the many new tools provided by the Windows Mobile 6 Software Development Kit (SDK), and provides some guidance on getting started developing Windows Mobile 6 applications.
The following lists briefly cover some of the most notable developer-related features of Windows Mobile 6 and the Windows Mobile 6 SDK.
Simplified Line of Business Application Development and Deployment
Easier to Build One Application That Runs on Many Devices
Enhanced User Experience
Understanding Windows Mobile 6 Naming Conventions
Windows Mobile 5.0 Naming
Windows Mobile 6 Naming
Windows Mobile 5.0 for Smartphone
Windows Mobile 6 Standard
Windows Mobile 5.0 for Pocket PC Phone Edition
Windows Mobile 6 Professional
Windows Mobile 5.0 for Pocket PC
Windows Mobile 6 Classic
The new naming convention focuses on each version's capabilities from an application perspective rather than focusing on the device hardware.
If you've previously developed Windows Mobile applications, you're aware of the extremely consistent developer experience across the Windows Mobile family of devices; you use a common set of APIs, tools, and utilities across the whole Windows Mobile family. The one feature that does differ among Windows Mobile devices is touch screen support. Pocket PC and Pocket PC Phone Edition devices have touch screens and therefore support direct screen input; Smartphone devices do not have a touch screen and therefore are unable to support direct screen input.
To be more consistent with this key differentiator, the Windows Mobile 6 SDKs no longer target specific device types as was true with earlier Windows Mobile SDKs. Instead, the two Windows Mobile 6 SDKs differentiate between devices with a touch screen and devices without a touch screen. You use the Windows Mobile 6 Professional SDK to develop applications for devices that have a touch screen, those devices historically called Pocket PC or Pocket PC Phone Edition. You use the Windows Mobile 6 Standard SDK to develop applications for devices that do not have a touch screen, those devices historically called a Smartphone. The relationship between the Windows Mobile 6 SDKs and Windows Mobile 6 devices is shown in Table 2.
Table 2. The relationship between the Windows Mobile 6 operating systems and the Windows Mobile 6 SDKs
Windows Mobile 6 Operating System
Corresponding Windows Mobile 6 SDK
Windows Mobile 6 Standard
Windows Mobile 6 Standard SDK
Windows Mobile 6 Professional
Windows Mobile 6 Professional SDK
Windows Mobile 6 Classic
Windows Mobile 6 Professional SDK
Notice that the two devices that have touch screens, Windows Mobile 6 Classic and Windows Mobile 6 Professional both use the Windows Mobile 6 Professional SDK; whereas the Windows Mobile 6 Standard device, which does not have a touch screen, uses the Windows Mobile 6 Standard SDK.
Strong Windows Mobile 5.0 Compatibility
Simplifying Application Development
This section describes the new development tools provided by the Windows Mobile 6 SDKs and the role each tool plays in the application development process.
Emulators have always been an important part of mobile application development, allowing you to test your application without requiring access to a physical device. The more of your testing that you are able to do using the emulator without being required to use a real device, the easier, faster, and less expensively you can work. The Device Emulator 2.0, installed as part of the Windows Mobile 6 SDK, builds on the Device Emulator 1.0 legacy to offer greater fidelity with the real device experience by emulating many new device states and features not previously available. Just as was the case for the Device Emulator 1.0, the Device Emulator 2.0 is a true ARM emulator. As a true ARM emulator, the Device Emulator 2.0 runs the same executable files as a real device thereby eliminating the need to manage separate application executable files for the emulator then are required for a real device. With the Device Emulator 2.0, one set of executables is all you need for both the emulator and real devices.
The Windows Mobile 6 SDK installation process automatically replaces the Device Emulator 1.0 that Visual Studio 2005 installs with the Device Emulator 2.0. As a result, all of your Visual Studio 2005 Windows Mobile project will use the Device Emulator 2.0 and will be able to take advantage of new features and improvements that the Device Emulator 2.0 provides.
One of the biggest frustrations of application testing is slow application startup and execution. To reduce delays caused by the emulator's performance, the Device Emulator 2.0 has been significantly optimized. Each application is different, so it's difficult to say how much any individual application is affected by the emulator optimizations but the Device Emulator 2.0 can provide a performance improvement of up to 40 percent over the Device Emulator 1.0.
The Device Emulator 2.0 adds many new device form factors enabling you to test your application behavior on many of the newest device form factors often before the devices are even on the market. Figure 1 shows the new 320x320-display form factor in the Device Emulator. The 320x320 display is one of the new device form factors available in Windows Mobile 6.
Figure 1. The Device Emulator emulating the new Windows Mobile 6 320x320 display form factor
In addition to the many new Windows Mobile 6 devices, the Device Emulator 2.0 continues to provide a rich set of Pocket PC 2003SE, Smartphone 2003SE, Windows Mobile 5.0 Pocket PC, and Windows Mobile 5.0 Smartphone device emulators. Figure 2 shows a Pocket PC 2003SE device and a Windows Mobile 5.0 Smartphone in the Device Emulator.
Figure 2. The Device Emulator emulating a Pocket PC 2003SE and Windows Mobile 5.0 Smartphone
Whether the Device Emulator 2.0 is emulating a new Windows Mobile 6 device or one of the older devices, the emulator still provides all of the new features discussed in this section.
By their nature, mobile devices spend a great deal of time on battery power, being plugged into AC power only occasionally. When the charge level of the device's battery becomes very low, your application may need to take specific actions to avoid data loss in the event that the entire battery charge expires. So that you can now test the effects of power state changes on your application, the Device Emulator 2.0 introduces power state emulation.
Figure 3. The Device Emulator's power state configuration controls
As shown in figure 3, the emulator configuration dialog allows you to switch the emulator state between using battery power and being plugged into AC power by checking or clearing the Battery: check box. When on battery, you can also set the battery charge level percentage. The emulator responds to these changes in the power state and charge level just as a device does. The emulator displays the appropriate icons and messages; it also raises the appropriate State and Notifications Broker events.
The Device Emulator 2.0 provides support for three new phone profiles: headset, speakerphone, and car kit. As shown in figure 4 you can enable each of these profiles by checking the appropriate check box on the emulator configuration dialog. When you check the profile check boxes, the emulator behaves just as if you have plugged in a headset, enabled the speakerphone, or connected a car kit including raising all of the appropriate State and Notifications Broker events.
Figure 4. The Device Emulator's profile configuration controls
The majority of Windows Mobile devices available today have phone and other wireless communication capabilities. There are many different situations where you may want your application to interact with these communications capabilities. You may simply want to turn down the music your application is playing when the phone rings or you may need to incorporate much more sophisticated features that involve working more closely with the communications hardware. In either case, developing these types of applications has historically been difficult, due largely in part to the difficulty of testing such an application.
To address the difficulty of testing such applications, the Windows Mobile 6 SDK includes the Cellular Emulator. The Cellular Emulator enables you to test your application's behavior in different cellular communications situations from within the Device Emulator. Figure 5 shows the Cellular Emulator.
Figure 5. The Cellular Emulator enables you to test phone and communications behavior from within the Device Emulator
The Cellular Emulator is a powerful tool for testing the behavior of your application as the state of cellular communications changes. The Cellular Emulator allows you to perform simple tests like making outgoing calls from the emulator, receiving incoming calls, and dropping a call. It also provides similar features for SMS messages. For developers needing to test more involved features, the Cellular Emulator provides support for modifying the SIM configuration and simulating network handoffs between 2G and 3G networks. All this testing is done without requiring a physical device.
To use the Cellular Emulator with the Device Emulator, you first need to associate the Cellular Emulator with the Device Emulator. Creating the association is very easy.
When the emulator completes the reset process, you'll see that the emulator now shows that cellular service is available.
Figure 6. Entering the Cellular Emulator COM port number to enable cellular service emulation for the Device Emulator
The widespread availability of inexpensive Global Positioning System (GPS) equipment combined with the easy-to-use GPS Intermediate Driver introduced in Windows Mobile 5.0 provide developers with the opportunity to easily location-enabled their applications. Historically, the challenge with location-enabled applications has been finding a good way to test them. Windows Mobile 6.0 solves this problem, through the FakeGPS utility.
The FakeGPS utility allows you to easily test your location-enabled applications without requiring access to an active GPS device or active GPS feed. Instead, you create a simple text file containing a list of GPS NMEA messages, copy the text file to the \Program Files\FakeGPS\GPS folder on your device, and then enable FakeGPS. The following is a portion of a sample FakeGPS input file.
$GPGLL,4738.0173,N,12211.1874,W,191934.767,A*21 $GPGSA,A,3,08,27,10,28,13,19,,,,,,,2.6,1.4,2.3*3E $GPGSV,3,1,9,8,71,307,43,27,78,59,41,3,21,47,0,10,26,283,40*77 $GPGSV,3,2,9,29,13,317,0,28,37,226,37,13,32,155,36,19,37,79,42*42 $GPGSV,3,3,9,134,0,0,0*46 $GPRMC,191934.767,A,4738.0173,N,12211.1874,W,0.109623,12.14,291004,,*21 $GPGGA,191935.767,4738.0172,N,12211.1874,W,1,06,1.4,32.9,M,-17.2,M,0.0,0000*75 $GPGLL,4738.0172,N,12211.1874,W,191935.767,A*21 $GPGSA,A,3,08,27,10,28,13,19,,,,,,,2.6,1.4,2.3*3E $GPRMC,191935.767,A,4738.0172,N,12211.1874,W,0.081611,15.81,291004,,*2A
Working in conjunction with the GPS Intermediate Driver, FakeGPS routes the messages from the text file to any applications reading the GPS feed. Because the FakeGPS utility works directly with the GPS Intermediate Driver, you can use it to test your applications on both real devices and the Device Emulator without making any modifications to your program. To activate the FakeGPS data feed, use the FakeGPS utility to select the desired input file and choose the Enable option as shown in figure 7.
Figure 7. Setting up the FakeGPS feed to enable testing of location-enabled applications
Few things are more frustrating than having the application that you've worked so hard to develop, suddenly fail when you install the application on a user's device. Unfortunately, this can sometimes happen if you haven't tested your application running under the same security settings as the end user's device. The best way to avoid security related problems is to make security planning a central part of your application design, development, and testing process. This is the purpose of the Security Configuration Manager.
The Device Security Manager runs on your desktop and provides two essential services. The Device Security Manager displays the current security settings of the device or emulator currently connected to your desktop through Microsoft ActiveSync® on Windows XP or Windows Mobile Device Center (WMDC) on Vista. The displayed information includes the device security policy, the list of individual security settings, and the list of certificates installed into each of the device's certificate stores.
The Device Security Manager also allows you to configure the emulator with common security policies, allowing you to fully test the effect of the different security policies on your application without needing a real device. Figure 8 shows the Device Security Manager just after configuring the emulator to have a one-tier prompt security policy.
Figure 8. The Security Configuration Manager after updating the emulator security policy
Using the Device Security Manager, you can take advantage of the ease of application testing with the emulator while ensuring that your application behaves as you expect under the different security policies.
Note:
For more information on Windows Mobile security, see the Windows Mobile Developer Center or Mobile2Market Frequently Asked Questions.
Prior to distributing your application, you commonly must the sign the application executable and the installation files with the appropriate certificate to identify your organization as the publisher of the application. For security reasons, all of the application's executable files (both *.dll and *.exe) and the CAB file installing the application must be signed. Signing each individual executable file, building the CAB file, and then signing the CAB file can be time consuming especially in cases where an application is composed of several executable files. The CabSignTool utility is a command-line utility that simplifies the application signing process by relieving you from the details of signing the individual parts of an application.
The CabSignTool utility signs a CAB file and all of the contained executable files at once. You simply build the application executable files and create the CAB file without being concerned with signing any of the files. The CabSignTool utility then explodes the CAB file contents, signs each executable file, reassembles the CAB file incorporating the signed version of the executables, and then signs the CAB file. The CabSignTool utility gives you the option of signing both the CAB file and executables with a single certificate or signing the CAB file with a separate certificate from the certificate used to sign executable files.
Mobile applications are often left running on a device for weeks or months without being closed. The prolonged use of an application over such a long period can sometimes reveal problems in an application that are difficult to find through traditional application testing. To find these problems requires that the application be put under the same kind of stress during your testing cycle that the application will experience when deployed. The Hopper utility provides a way to perform this kind of stress testing.
The Hopper utility simulates a user rapidly clicking at random locations within your application. This puts your application under tremendous stress and performs a level of unstructured application usage that can expose application errors not easily found when doing traditional application feature testing. The Hopper utility can be used to stress test a single application or can be used to stress test several applications at one time incorporating even greater randomness by randomly switching between the applications in addition to randomly clicking within the individual applications. You should include the Hopper utility in all of your application testing. This same utility tests Windows Mobile devices to ensure that the devices are stable. Including the Hopper utility in your testing not only verifies the stability of your application but also verifies that your application does not introduce device instability.
The Local Server Framework is tools and classes designed to simplify testing mobile applications that rely on communication with remote servers. To help simplify your mobile application development, the Local Server Framework enables you to set up a virtual network and server that receives the network calls your application issues and returns back the results your program expects. By using a well controlled local server environment, you can more easily separate issues in your mobile applications that are created by external network or server issues from those issues that are occurring in your program.
The Windows Mobile 6 SDK provides several samples that you may find useful. The samples cover most topics that you're likely to encounter when developing Windows Mobile 6 applications and serve as a great time saver and learning tool. A few of the most notable samples follow.
This sample demonstrates how to build a native application that dynamically adapts to device form factor differences. This sample covers how to incorporate docking, anchoring, and other display management features. This sample also includes a class, ScreenLib that encapsulates much of this display logic. The ScreenLib class is designed for reusability and can easily be adapted to your own applications.
This sample demonstrates the usage of the new Windows Mobile 6 sound API.
These samples demonstrate several usages of the WISP Lite APIs. The topics covered include performing text recognition on ink-based input, using ink-based input within an application and storing the ink in a file.
This sample demonstrates how to access the GPS Intermediate Driver from within a managed application. The sample includes all of the necessary wrapper methods to abstract the native call details from the managed application.
All Windows Mobile 6.0 devices include .NET Compact Framework 2.0 SP1 in ROM. This allows you to take full advantage of the rich features provided by .NET Compact Framework 2.0 and the many improvements over .NET Compact Framework 1.0 without being concerned with needing to deploy the .NET Compact Framework 2.0 runtime with your application. Even your .NET Compact Framework 1.0 applications will run better on Windows Mobile 6 devices because your .NET Compact Framework 1.0 applications are fully compatible with .NET Compact Framework 2.0 and will therefore run on your Windows Mobile 6 devices and take full advantage of the .NET Compact Framework 2.0 improvements without you making any changes to the program. The improvements to the .NET Compact Framework 2.0 are many and focus on improving developer productivity, providing greater fidelity with the full .NET Framework, and increasing support for device features. This section describes some of the most notable features of .NET Compact Framework 2.0.
Although .NET Compact Framework 2.0 includes a number of improvements throughout, many of the most obvious improvements are in the user interface related features.
Controls are the building blocks of your application user interface. The usability of many applications is tied directly to how well the application takes advantage of the available controls. The .NET Compact Framework 2.0 provides many new controls; these new controls help to simplify your application user interface design and provide an improved experience for the user.
As part of the new controls, the .NET Compact Framework 2.0 provides two controls for displaying and entering date-based information: the MonthCalendar control and the DateTimePicker control. Both controls are shown in figure 9. The MonthCalendar control is useful when you would like to include the look of calendar in your application and have it always be visible on the form. The DateTimePicker is well suited for the limited display size of mobile devices; date and time information are displayed in what looks like a TextBox control but when a user needs to enter data, the DateTimePicker control displays a full calendar.
Figure9. The MonthCalendar control and the DateTimePicker control.
For applications wanting to incorporate a rich HTML-based display, the .NET Compact Framework 2.0 includes the WebBrowser control shown in figure 10. The WebBrowser control provides a number of events that allow your application to track the user's interaction with the WebBrowser control's content; if desired your application can respond to the user interaction events with custom behaviors.
Figure 10. The WebBrowser control displaying the Windows Live mobile search page
One of the most interesting of the new controls is the Notification control. The Notification control allows you to display a message to the user without changing the context of the user's current activity. The Notification control allows you to display messages in a pop-up style balloon similar to the way a Windows Mobile device displays a low battery message.
The controls mentioned in this section are just the beginning. The .NET Compact Framework 2.0 includes many more controls beyond what we've mentioned here including the StatusBar control, DataGrid control for Smartphone, UserControl-derived custom controls, and many more.
Windows Mobile devices come in many different form factors with new form factors appearing all of the time. To ensure that your application works successfully across the family of Windows Mobile devices, you need to design your application user interface to adapt to differences in the size, shape, and resolution of device displays. To relieve you from the details of handling these device differences, the .NET Compact Framework 2.0 provides several new features that simplify the creation of adaptable application user interfaces.
The most notable of these new features is the addition of control docking and control anchoring. Control docking and control anchoring help you to make your application user interface more adaptable because docking and anchoring enable you to provide default behaviors regarding how a control should respond to changes in the display area.
Docking a control aligns the control with the edge of its parent control. For example if you configure a control to dock with the left edge of its parent, the control positions against the left edge of the parent control and fills the entire area along the left edge of the parent control as shown in figure 11. When device form factor differences cause a change in the size of the parent control, the docked control automatically resizes itself to remain aligned with the parent control's left edge.
Figure 11. A control docked to the top edge of its parent control shown on a portrait and landscape display
Anchoring a control indicates that one or more edges of a control should remain a fixed distance from the corresponding edge(s) of the parent control. Differences in the size of the device display cause the control to automatically adjust its size, and if necessary, its position to always maintain the anchored edge's specified distance from the edge(s) of the parent control. Figure 12 shows a TextBox control anchored to the left, right, and bottom edges of the parent control.
Figure 12. A control anchored to left, right, and bottom edges of its parent control shown on a portrait and landscape display
In some cases, it may not be practical for an application to resize or move its controls in response to differences in the size of the device display area. This commonly occurs when an application has a number of controls, which if resized might become too small for the user to reasonably interact with. In this case, the better solution is to allow the user to scroll the application display area to view controls that are off the edge of the display. With .NET Compact Framework 2.0 you don't need to do anything special to incorporate scrolling into your application. When your application displays, the .NET Compact Framework 2.0 automatically detects if any of the controls are out of view due to the display size and adds scroll bars to the application form as necessary. The .NET Compact Framework 2.0 also provides all of the scrollbar handling; therefore, the user can scroll the form to reach the hidden controls without requiring any special handling by the application.
Devices have not only differing display sizes but also have differing display resolutions. If these resolution differences are not accounted for, an application originally designed for a 96 dots-per-inch (dpi) display will look very tiny and squished on a 192 dpi device. To display properly, the controls need to scale for the new display resolution. With .NET Compact Framework 2.0, dealing with these resolution differences is easy because the .NET Compact Framework 2.0 automatically scales all controls to account for differences in the design-time resolution and the runtime resolution.
One very important improvement in the .NET Compact Framework 2.0 is better support for devices with keypads or keyboards. In .NET Compact Framework 2.0 all controls now receive KeyUp, KeyDown and KeyPress events allowing you to incorporate custom keyboard handling in your application. Through the newly added Form.KeyPreview property, you also have the choice of whether you would like to have keyboard events sent to the individual controls or if you would like to have all control keyboard events sent to the form containing the controls.
The .NET Compact Framework 2.0 also includes support for setting controls as tab stops and for setting control tab order. This allows users with keyboard-enabled devices to move between application controls using the tab key rather then needing to use a stylus.
By their nature, LOB applications spend a great deal of time managing and interacting with data. For developers creating LOB applications, efficient and easy-to-use data classes are essential. Windows Mobile 6 provides LOB application developers with the fully relational database support they need by including the SQL Server Compact Edition in ROM. With SQL Server Compact Edition in ROM, you can take advantage of the power and capabilities of a locally installed relational database, SQL Server Compact Edition, without needing to include the database installation components in your application deployment.
Whether you're working with relational data using the DataSet class and SQL Server Compact Edition, or you're working with hierarchical data using the XML classes, the .NET Compact Framework 2.0 provides the easy-to-use, efficient, and feature-rich classes you need to reduce your programming effort while improving application performance.
Note:
In addition to the many great new features discussed in this section, see the section below "Greater Performance and More Efficient Resource Management" for a discussion of the improved data class runtime performance.
The one relational data class that the .NET Compact Framework 2.0 provides that will most affect your applications is the new SqlCeResultSet class. The SqlCeResultSet class provides an updatable, scrollable cursor directly to a SQL Server Compact Edition database. Instead of duplicating large volumes of database data in memory as the DataSet class does, the SqlCeResultSet class works directly with the SQL Server Compact Edition database engine and therefore provides data update and cursor scrolling without needing to duplicate the data.
The architecture of the SqlCeResultSet class substantially reduces the amount of memory an application uses as compared to the DataSet class. In many cases, the SqlCeResultSet can reduce the amount of memory your application requires by several megabytes. In addition to reducing memory consumption, the SqlCeResultSet is much faster than the DataSet class. The SqlCeResultSet commonly outperforms the DataSet class by 300 percent to 500 percent.
The .NET Compact Framework 2.0 provides several enhancements for working with XML-based data. These changes make working with the XML APIs easier and bring the XML APIs much more in line with the features provided by the full .NET Framework. As part of these enhancements, the .NET Compact Framework 2.0 adds support for the XML query language XPath; XPath can substantially reduce the amount of programming required to navigate XML data and can often navigate XML data more efficiently than when using explicit navigation APIs. The XmlSchema class and related classes have also been added which allow you to programmatically work with and create XML Schemas.
One of more frequently requested features, XML serialization, is now available. The .NET Compact Framework 2.0 now includes the XmlSerializer class and related classes such as the XmlElement and XmlAttribute classes. With the addition of these classes, you can now easily persist and restore application objects as XML.
The new XmlSerializer class replaces the Web service XML serialization implementation used in the .NET Compact Framework 1.0. All Web service XML serialization and deserialization is now performed with the new XmlSerializer class. The new XmlSerializer class is consistently two to three times faster than the Web service XML Serialization implementation in .NET Compact Framework 1.0. Thanks to the new XmlSerializer class, the overall time an application spends in a Web service call from a .NET Compact Framework 2.0 application can now be significantly shorter than the same call from a .NET Compact Framework 1.0 application.
Windows Mobile 6 provides better performance for managed applications by including .NET Compact Framework 2.0 in ROM. The .NET Compact Framework 2.0 provides substantial performance improvement over the .NET Compact Framework 1.0. The performance improvement affects virtually every area of application execution including the recovery of application resources.
The .NET Compact Framework 2.0 runtime has undergone a thorough examination and rework with the goal of improving performance. The effort has paid off. Although it's difficult to identify how the performance enhancements will affect any given application, many areas of the .NET Compact Framework 2.0 runtime may perform nearly one-and-one-half times the speed of the corresponding operation in the .NET Compact Framework 1.0. Other areas provide even more significant improvements such as method dispatching, both virtual and non-virtual, which in many cases is nearly two-and-a-half times faster than the .NET Compact Framework 1.0.
In addition to the overall runtime performance improvements, special attention has been given to improving the performance of the data classes. The .NET Compact Framework 2.0 DataSet class loads data three to four times faster than the .NET Compact Framework 1.0 version. The XmlTextReader class has undergone similar performance improvements and is now able to read the contents of an XML file nearly three times faster than the .NET Compact Framework 1.0.
Beyond the many application run-time performance improvements, the .NET Compact Framework 2.0 also provides tremendous performance improvements in the garbage collector. In general, the .NET Compact Framework 2.0 garbage collector recovers memory more than seven times faster than the .NET Compact Framework 1.0. Large object allocations are managed and recovered separately from other memory allocations and were already very fast in the .NET Compact Framework 1.0 but the .NET Compact Framework 2.0 garbage collector is still more than four times faster. Table 3 provides an overview of the .NET Compact Framework 2.0 performance improvements.
Table 3. Overview of the .NET Compact Framework 2.0 performance improvements over the .NET Compact Framework 1.0
Task
.NET CF 2.0 Performance Improvement over .NET CF 1.0
Overall Runtime Execution
1 1/2 times faster (on average)
Method Dispatching
2 1/2 times faster
DataSet Loading
3 to 4 times faster
XmlTextReader Reading
3 times faster
Garbage Collector Memory Recovery
7 times faster
Garbage Collector Large Object Recovery
4 times faster
Not only will applications perform better with .NET Compact Framework 2.0 than with .NET Compact Framework 1.0 but .NET Compact Framework 2.0 applications running on a Windows Mobile 6 device will start up 25 percent faster than the same .NET Compact Framework 2.0 application running on an earlier Windows Mobile device. The improved start up time on Windows Mobile 6 devices is a result of the .NET Compact Framework 2.0 being installed in device ROM. Simply having the .NET Compact Framework 2.0 in device ROM, improves application startup 25 percent over devices that have .NET Compact Framework 2.0 installed in RAM.
All of these performance improvements not only mean that your users will be happier with your faster, more responsive applications; these performance improvements also accelerate your application development because you now spend less time waiting. Your application will start faster, run faster, and yield the results of your application testing faster.
The .NET Compact Framework 2.0 provides many new features over those available in the .NET Compact Framework 1.0. With so many more features, .NET Compact Framework 2.0 applications are able to perform much more of their work using only managed code then was possible in .NET Compact Framework 1.0 applications. Even with the many new features, managed applications still need to interact with native code on occasion. The .NET Compact Framework 2.0 provides a much improved native code interoperability implementation over that provided by the .NET Compact Framework 1.0 that makes interacting with native code from your managed application code much easier and less confusing.
The .NET Compact Framework 2.0 adds Component Object Model (COM) support, which allows your managed applications to call COM components directly. No longer is it necessary to create a custom native library to make a COM object accessible as was required in .NET Compact Framework 1.0.
The native code marshalling layer has been improved to support many more data types then in the past. Most of the data marshalling limitations present in .NET Compact Framework 1.0 are gone. You can now pass most parameters directly from your managed application to native code without any special programming; this includes classes and structures that contain embedded types such as strings and arrays. The .NET Compact Framework 2.0 also provides customizable parameter marshalling through the MarshalAs attribute.
For those developers who need to work with native functions that require a window handle, all .NET Compact Framework 2.0 Windows Forms controls now provide a Handle property. The Handle property exposes the native window handle of the control's underlying window and can be passed to native methods that expect a windows handle.
All Windows Mobile 6 devices have SQL Server Compact Edition, an enterprise-quality relational database, installed in ROM; this is true for both Pocket PC and Smartphone devices. With SQL Server Compact Edition in ROM, your applications can take full advantage of a local, fully relational database, SQL Server Compact Edition, without needing to include the database installation components in your application deployment. This reduces your deployment support time and cost.
Note:
Existing database files created using SQL Server 2005 Mobile Edition are fully compatible with SQL Server 2005 Compact Edition and can be used without modification to the database file.
SQL Server Compact Edition is a feature-rich relational database providing a thorough SQL syntax including inner joins, outer joins, and subqueries. SQL Server Compact Edition provides full transactional consistency ensuring that your database is always maintained in a consistent state even in the event of an application crash or complete loss of device power. SQL Server Compact Edition provides record-level, page-level, and database-level locking ensuring database integrity even when simultaneously accessed and updated by multiple threads or multiple applications. One key feature for LOB applications is SQL Server Compact Edition's support for databases up to 4 GB in size.
SQL Server Compact Edition allows you to fully leverage your existing SQL Server skills by providing a rich subset of the SQL Server 2005 SQL implementation. You can also fully leverage your existing database programming skills because SQL Server Compact Edition provides an ADO.NET library for managed applications and an OLEDB library for native applications, both of which are consistent with their SQL Server 2005 counterparts.
SQL Server Compact Edition fully integrates with both SQL Server Management Studio and Visual Studio 2005. Using SQL Server Management Studio, you can create new SQL Server Compact Edition databases, view the database objects, create tables, modify tables, and perform interactive queries. Figure 13 shows SQL Server Management Studio displaying the list of tables, table columns, and table indexes from a SQL Server Compact Edition database.
Figure 13. SQL Server Compact Edition database table, table columns, and table indexes viewed in SQL Server Management Studio
Visual Studio 2005 fully supports SQL Server Compact Edition providing the same data-oriented features as are available for other databases. Using Visual Studio 2005, you can add a SQL Server Compact Edition database to a project as a data source. When adding a SQL Server Compact Edition data source, Visual Studio 2005 behaves as it does for a SQL Server 2005 database; it generates a strongly typed DataSet-derived class, and adds the database tables to the Visual Studio 2005 Data Sources pane. Just as with SQL Server 2005, you can drag tables and columns from the Data Sources pane onto your application forms and Visual Studio 2005 automatically generates the appropriate controls and data binding code. Figure 14 shows SQL Server Compact Edition database tables viewed in the Data Sources pane.
Figure 14. Tables from a SQL Server Compact Edition database in the Visual Studio 2005 Data Sources pane
Using the Visual Studio 2005 Server Explorer, you can open a SQL Server Compact Edition database and interactively browse the database contents. You can also open database tables from the Server Explorer to view, add, modify, and delete records.
One of the most important issues that you must address when designing a mobile LOB application is your data synchronization strategy. When data is first copied from an enterprise database to your mobile device, both the device and the enterprise database have the same information; however, it isn't long before the two databases have differing information. Activity on the part of the user may result in changes being made to the data on the device; similarly, activity throughout the rest of the enterprise will likely result in changes being made to the data in the enterprise database. You need to decide just how your application will synchronize the device database and enterprise database to bring the two databases back to a consistent state.
There is no one right strategy for every application, which is why SQL Server Compact Edition supports several different data synchronization mechanism directly out of the box. For applications where the majority of data changes are made to the device copy of the data, for example a utility meter reader collecting information, SQL Server Compact Edition provides Remote Data Access (RDA). RDA is a very lightweight data synchronization utility that tracks changes made to the device database and later applies those same changes to the enterprise database. For more complex situations, SQL Server Compact Edition provides merge replication. Merge replication is a cooperative data synchronization utility that tracks changes made to both the device copy of the data and the enterprise copy of the data. When the data is synchronized, both the device database and enterprise database exchange their respective data change histories to bring the two databases into sync. As part of the data synchronization process, merge replication goes through a change reconciliation phase where the changes on both sides are reviewed to determine the exact data to be exchanged. The change reconciliation phase automatically detects any conflicting data changes that may have occurred and takes the appropriate action. Merge replication's handling of change conflicts is fully configurable and can be customized. Merge replication also includes some advanced data synchronization features not available for RDA: background data synchronization (also called asynchronous replication) and progress events. The background data synchronization feature allows you to initiate the merge replication process to run on a background thread. This leaves your main application thread available to maintain a responsive user interface. Progress events give your application regular updates as to the data synchronization process' status including when the changes for each table are exchanged and the progress of the change reconciliation phase.
Both RDA and merge replication perform the data synchronization process through a Web server with the data changes being sent using either the Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS). Performing data synchronization through a Web server provides tremendous flexibility because it allows the SQL Server Compact Edition database to synchronize with the enterprise database anytime the device is able to connect to the Internet whether through a high-speed connection like WiFi or a slower cellular connection.
For application environments where the data is stored in an individual database on a user's desktop computer rather than in an enterprise database, SQL Server Compact Edition provides the SQL Server Compact Edition Access Database Synchronizer (ADS). Using ADS, you can populate the SQL Server Compact Edition database on your device with data from the Access database on the user's desktop. The SQL Server Compact Edition database automatically tracks changes made to the device database. Later when you cradle the device, SQL Server Compact Edition uses ADS to apply the device database changes to the Access database.
The portability of mobile devices requires that you follow secure practices to ensure that important information is not compromised. To secure the data in your SQL Server Compact Edition database, SQL Server Compact Edition supports password protecting the database and encrypting the database contents. Password protecting and encrypting a database is easily done when you create the database. The following is a SQL statement that creates a database named SafeData.sdf on drive C, sets the password to P@ssw0rd, and configures the database to encrypt all data.
Create Database "c:\SafeData.sdf" databasepassword 'P@ssw0rd' encryption on
All data stored in the database will be encrypted. The only way to successfully access the database contents is to provide the correct password when you open the database. The following example shows how to create a password protected, encrypted database file programmatically from within a C# program.
SqlCeEngine dbEngine = new SqlCeEngine(@"data source=\My Documents\SafeData.sdf;password=P@ssw0rd;encrypt database=TRUE"); dbEngine.CreateDatabase();
In addition to providing secure database contents, SQL Server Compact Edition also provides secure data exchange when synchronizing with an enterprise database using RDA or merge replication. Both RDA and merge replication support using HTTPS to encrypt the change history data when exchanged over the Internet with the back-end database.
Windows Mobile 6 has an updated version of Microsoft Internet Explorer® Mobile that includes the XML DOM and JavaScript support required to run basic AJAX applications. This allows you to leverage your existing ASP.NET, XML, and JavaScript skills to build rich browser-based applications that run on Windows Mobile 6 devices.
Note:
The Windows Mobile 6 SDK Refresh due May 1, 2007 includes the Windows Mobile 6 emulator images with support for basic AJAX applications.
Simplifying Application Deployment
Windows Mobile 6 simplifies deploying both managed and native applications by including both .NET Compact Framework 2.0 SP1 and SQL Server 2005 Compact Edition in the ROM of every Windows Mobile 6 device. Having both the .NET Compact Framework 2.0 SP1 and SQL Server Compact Edition in ROM significantly simplifies application deployment and reduces the level of support you must provide for end-users to successfully install your applications.
The benefits of having both .NET Compact Framework 2.0 SP1 and SQL Server Compact Edition in ROM are numerous. You have a well-defined target platform that guarantees that both of these core software components are always present and always installed properly. The overall size of your application installation package remains small because it contains only your application components. A small installation package provides fast download times and fast installation times, which simplify application distribution and application update distribution. Fast installation times and fast downloads also provide for a positive user experience.
In addition to the improved user, deployment, and support experience, having .NET Compact Framework 2.0 SP1 and SQL Server Compact Edition installed in device ROM also provides for a better runtime environment for your application. With .NET Compact Framework 2.0 SP1 and SQL Server Compact Edition installed in device ROM, they do not occupy device RAM. Less software installed into RAM leaves more RAM space for your application to use for data storage.
The addition of basic AJAX support to Internet Explorer Mobile on Windows Mobile 6 offers new opportunities for distributing applications. For application scenarios where an AJAX-based solution is appropriate, you can deploy your application by simply emailing the appropriate URL. When the user receives the URL they simply browse to the URL using Internet Explorer Mobile. No additional software needs to be installed on the device because Internet Explorer Mobile includes everything necessary to run your basic AJAX programs.
A key aspect of the Windows Mobile security strategy is the use of certificates to sign application executable files and installation files. In larger applications, the process of properly signing application executable files and installation files can be tedious. The new CodeSignTool utility, mentioned earlier in this paper, significantly reduces the effort to sign your application installation files by allowing you to sign all the necessary files with a single command.
Building One Application That Runs on Many Devices
Table 4. Common Windows Mobile device form factors
Size
Resolution
Touch Screen
176x220
96 dpi
No
240x320
131 dpi
No
320x240
131 dpi
No
320x320*
128 dpi
Yes
240x320 / 320x240
96 dpi
Yes
480x640/640x480
192 dpi
Yes
240x240
96 dpi
Yes
480x480
192 dpi
Yes
*New for Windows Mobile 6
With such a wide variety of form factors available, you must be sure to build your application to adapt to device form factor differences. You'll want to remember that the list of form factors that Windows Mobile devices support is growing all of the time. Windows Mobile 6 includes many new features and resources aimed at reducing the effort required to build applications that easily adapt to form factor differences. You'll find that Windows Mobile 6 makes building a single application that takes advantage of the specific capabilities of each device while successfully working on a wide variety of device form factors easier than ever before.
Note:
The 320x320-display form factor introduces a new resolution and a display area that differs slightly from earlier form factors. Be sure to include this new form factor in your application testing; otherwise, the differences from other form factors may result in application display difficulties on devices with this form factor.
The original Windows Mobile Pocket PC devices included very little in terms of device security. As the platform has matured the platform has become increasingly secure. The trend of improving the security of the Windows Mobile platform is something that will likely continue. To minimize compatibility problems with future Windows Mobile versions there are just a couple of security best practices that you should begin incorporating in your applications today.
Windows Mobile devices provide a uniform API set across all Windows Mobile devices. This is a critical factor that makes building a single application executable that works across all Windows Mobile devices practical. Both the Win32® API and the .NET Compact Framework 2.0 are comprehensive and consistent across all Windows Mobile devices. Having a uniform API set alleviates you from needing to manage and distribute separate executables for different device types.
The one area that does require special consideration is the device display; this is the focus of the rest of this section.
The Device Emulator is one of the most important tools you have for developing applications that successfully run across different device form factors. With the Device Emulator, you can test your application across many different device form factors without needing access to the physical devices with those form factors. Visual Studio 2005 and the Windows Mobile 6 SDK offer a combined total of over 25 emulator images allowing you to fully test your application's behavior across a wide range of device form factors. See figure 15 for a sampling of the many device form factors that the emulator supports.
Figure 15. A few examples of Device Emulator form factors
The Visual Studio 2005 form designer provides a fast, easy-to-use mechanism for building your application user interface. Using the designer, you are able to create and modify a form's appearance and immediately see the result. This what-you-see-is-what-you-get (WYSIWYG) design-time experience is not limited to applications with static user interfaces. The Visual Studio 2005 form designer is form factor aware and therefore allows you to view the appearance of your application forms across different form factors. This feature is a great time saver because it saves you from needing to execute your application to see the effect of different form factors.
To see how your form renders when rotated from portrait to landscape, you can right-click on the form and rotate the form 90 degrees to the right or left. You can again click on the form and rotate the form back to portrait. Figure 16 shows a form in the Visual Studio 2005 form designer rotating from portrait to landscape.
Figure 16. Using the Visual Studio 2005 form designer to view changes in a form's layout when rotated from portrait to landscape
To view the view the effect of other changes in the display size and display resolution, Visual Studio 2005 provides a design-time only property, Form Factor.
When you select a new Form Factor value, the Visual Studio 2005 form designer displays your form as it appears within the selected form factor. Figure 17 shows the form in figure 16 when the Windows Mobile 6 Professional Square form factor is chosen. Notice the addition of the scroll bars to reach the controls at the bottom of the form.
Figure 17. Viewing the form from figure 16 in the Visual Studio 2005 form designer within a square form factor
Supporting differences in device form factors is an essential foundation of Windows Mobile application development. To help you implement support for device form factor differences, the .NET Compact Framework 2.0 classes and runtime provide built-in support for dynamically responding to changes in the device form factor. Similarly, native developers have several APIs that provide similar support.
For managed applications, the .NET Compact Framework 2.0 provides several new features that enable the runtime to automatically adjust the size and position of controls: control docking, control anchoring, automatic scrolling, and automatic scaling. A docked control is positioned against one edge of its parent control and fills the whole area along that edge. In response to differences in the display size, the control automatically adjusts its size to always fill the entire edge of the parent control. See figure 11 from earlier in this paper for an example of a docked control.
An anchored control maintains a fixed distance between one or more of the control's edges and the edges of the parent control. In response to differences in display size, anchored controls automatically adjust their own size to maintain the appropriate distance between the control's anchored edges and those of the parent control. Figure 12 from earlier in this paper shows an anchored control.
The .NET Compact Framework 2.0 makes automatic scrolling and automatic scaling available through the AutoScroll and AutoScaleMode properties on the Form control. When the form's AutoScroll property is set to true, the form will automatically add scrollbars when a change in the display size results in some of the form's controls being out of view. Device form factor differences are not limited to variations in size; different device form factors may also have different resolutions. Differences in device resolutions can cause an application form's controls to appear very small or very large. By setting the form's AutoScaleMode property to AutoScaleMode.Dpi, the form's controls automatically scale their size so that they render appropriately on the different display resolutions.
Although not new for Windows Mobile 6, Microsoft C++ provides over twenty functions and macros that address common tasks associated with adapting to differences in device displays. You'll find them in the DeviceResolutionAware.h header file located in the %Program Files%\Microsoft Visual Studio 8\ VC\ce\atlmfc\include folder. Table 5 shows just a few of these functions and macros.
Table 5. A few of the native functions and macros that assist with adapting to device display differences
Function or Macro
Description
GetDisplayMode
Returns a value identifying whether the current display orientation is portrait, landscape, or square.
SCALEX, SCALEY, SCALERECT, SCALEPT
Adjusts the value as required for the current display resolution.
StretchIcon
Adjusts the size of an icon to fit the current display area.
RelayoutDialog
Copies the data from one dialog box to another; useful when a user changes a device's display orientation while the dialog box is displayed. This allows your application to display another dialog box having the same controls as the original dialog box, but is more appropriately sized for the current resolution.
FixupDialogItem
Addresses common issues that occur when an application changes the size of a dialog; for example scrolling a ListBox control's or ComboBox control's selection into view in the event that it is scrolled off the display area.
To reduce the amount of time you spend incorporating form factor adaptability in your application, Microsoft provides several resources to assist you. These resources address many of the best practices to follow when implementing your application. These resources also provide working code that handles many of the common issues associated with handling device differences. You can use the code not only as an example of how to address differences in the device form factors; you can also incorporate the code in your application and immediately take advantage of it.
For managed developers, the Microsoft Patterns and Practices group provides the Mobile Client Software Factory. The Mobile Client Software Factory is a combination of best practices, source code, components, and samples that address many of the most common situations mobile developers face. Specific to the issue of dealing with device form factor differences, the Mobile Client Software Factory provides the OrientationAwareControl. The OrientationAwareControl works with Visual Studio 2005 to enable you to graphically lay out a control containing one or more child controls; as part of defining the control layout, you define separate layouts for each different form factor.
With the OrientationAwareControl you first define the control layout as you would like it to appear on one form factor. Within Visual Studio 2005, you then change the form factor to see how the control appears when viewed using the new form factor. If you're unhappy with the way the control appears when viewed on the new form factor, you can adjust the control's layout for the new form factor without affecting the control's layout for the original form factor. The control maintains the separate layout information for each of the different form factors for use at runtime. When the application is run, the OrientationAwareControl renders with the appropriate layout for the current form factor. For example, if an application is running on a device with a display size of 240x320, 96 dpi resolution, and portrait orientation, the OrientationAwareControl uses the layout you defined for a display size of 240x320, 96 dpi resolution, and portrait orientation. If the user rotates the device orientation to landscape, the OrientationAwareControl then displays with the layout you defined for a display size of 320x240, 96 dpi resolution, and landscape orientation. The OrientationAwareControl works similarly for changes in display resolution and size.
Another key resource for managed developers is the Mobile Line of Business Solution Accelerator kit. This kit provides LOB developers with a resource demonstrating how to build a Windows Mobile LOB application. The kit includes complete source code with extensive commenting, a sample database, and more than 100 pages of documentation. The kit includes application components that target users in different roles including customer service, warehouse worker, and delivery driver. In addition to providing guidance on application development, the kit also includes best practices for successfully deploying a mobile LOB application on an enterprise scale.
For native developers, the Windows Mobile 6 SDK includes the UILayout sample. This sample demonstrates how to implement a native application whose user interface automatically adjusts to device display differences. The sample's ScreenLib class does the bulk of the user-interface related work through the many methods it provides including methods to dock controls, anchor controls, align controls, optimize the layout of the application controls, and much more. The ScreenLib class is designed for reusability so you can incorporate the class directly into your own applications and take advantage of the many features it provides.
For the most up to date information on building applications that work effectively across the entire family of Windows Mobile device form factors, visit the Windows Mobile Adapt Your App page. The Windows Mobile Adapt Your App page is your one-stop resource for all things related to developing adaptable Windows Mobile applications including white papers, web casts, announcements and more.
Windows Mobile 6 has completely rearchitected the device look and feel. The display is much more crisp and clean. One of the areas where the look and feel has undergone the most significant change is the Pocket Outlook screens. The screens not only provide a more crisp and clean display but also simplify viewing and navigating the information. Your applications will benefit from most of these improvements by simply running them on a Windows Mobile 6 device; you don't have to change a thing.
Windows Mobile provides a number of standard dialog forms including the contact selection dialog and the messaging forms. These standard dialogs you use in your application are the same forms used in Pocket Outlook and therefore have the same improved look when viewed from your application as they do when used from Pocket Outlook directly. Similarly, the picture selection dialog benefits from the general display improvements. The same is true for applications that use the.NET Compact Framework 2.0 DocumentList class for users to find and open files. Figure 18 shows the new Windows Mobile 6 picture selection dialog.
Figure 18. The new Windows Mobile 6 picture selection dialog
Similarly, the picture selection dialog benefits from the general display improvements. The same is true for applications that use the.NET Compact Framework 2.0 DocumentList class for users to find and open files.
Windows Mobile 6 includes a lightweight version of the Tablet PC's WISP inking API, called WISP Lite. WISP Lite brings the power and flexibility of rich ink to all Windows Mobile 6 Classic and Windows Mobile 6 Professional devices. WISP Lite provides full compatibility with ink data from Tablet PCs and includes APIs for ink collection, recognition, rendering, and ink data management. WISP Lite provides a much higher fidelity experience than the previous RichInk control.
Windows Mobile 6 includes a new set of sound APIs able to play many sound file formats not previously supported. The new sound API can play MP3, MID, WMA, and WAV files. In response to developer demand, the new sound API includes the option of honoring the device profile so that sounds do not play when the device is set to mute or vibrate.
The new sound API includes functions to retrieve the sound file associated with common events such as the known caller ring tone or roaming ring tone; you can also change the sound file associated with these events. You can play sound files synchronously or asynchronously; optionally the API will notify your application at the completion of asynchronous play. The new API also includes functions that search for the location of sound files in RAM, in ROM, and on installed storage cards.
The State and Notifications Broker allows your application to be informed of changes in the device state and react to these state changes intelligently. In addition to the more than 100 State and Notification Broker state values supported by Windows Mobile 5.0, Windows Mobile 6 adds several more. Windows Mobile 6 provides call state information for Voice over Internet Protocol (VoIP) phone calls including the phone number, operator name, and more. Windows Mobile 6 also adds state information for device locking. State information is now available for changes in the keypad lock state, device lock state, and SIM lock state.
What You Need to Starting Building Windows Mobile 6 Applications
To develop your first Windows Mobile 6 application there are a few things you need to install. This section covers the list of software that you'll need and whether each piece of software is required, recommended, or optional. A short description of the purpose of each is also included.
Prerequisite
Required / Optional
Description
Visual Studio 2005 Standard Edition, Professional Edition, or Team System
Required
Visual Studio 2005 is the development environment that you use to create Windows Mobile applications.
Windows Mobile 6 Professional SDK or Windows Mobile 6 Standard SDK
Required
Provides the tools, header files, emulator images, and Visual Studio 2005 project types to develop Windows Mobile 6 applications.
ActiveSync 4.5 or greater (XP) or Windows Mobile Device Center (Vista)
Required
Provides the necessary connectivity to cradle a Windows Mobile 6 emulator image or device.
Visual Studio 2005 Service Pack 1
Optional (Windows XP)
Required (Windows Vista™)
Incorporates minor fixes and updates all data-oriented dialogs in Visual Studio 2005 to show the SQL Server Compact Edition product name. For Windows Vista users, this service pack updates necessary for Visual Studio 2005 to run on Windows Vista.
.NET Compact Framework 2.0 Service Pack 1
Recommended
Without this service pack, Visual Studio 2005 will deploy .NET Compact Framework 2.0 to your Windows Mobile 6 device each time you deploy your application. Also adds support for command line debugging and provides new utility to review performance data provided by the .NET Compact Framework 2.0 runtime.
SQL Server 2005 Compact Edition Tools for Visual Studio 2005
Optional
Provides tools and assemblies required to develop Windows Mobile 6 applications that use SQL Server 2005 Compact Edition. Before installing this tool, you need to first install Visual Studio 2005 SP1.
If you've ever built a Windows desktop computer application or server application, even if you've never before built a Windows Mobile application, you already have the skills necessary to get started developing Windows Mobile 6 applications. One factor that makes getting started building Windows Mobile 6 applications so easy is Visual Studio 2005. Creating a Windows Mobile 6 application in Visual Studio 2005 is very much like building a desktop Windows Forms application. Visual Studio 2005 maintains the same behaviors and provides the same features for Windows Mobile 6 applications as it does for desktop applications.
If you're a managed developer, you will find that the .NET Compact Framework 2.0 provides the same classes that you use when creating desktop applications and those classes are a rich subset of the full .NET Framework's classes. The .NET Compact Framework 2.0 also provides many of the same Windows Forms controls you use to build desktop applications. These controls provide the same familiar experience you know from developing desktop applications.
The core API for the Windows Mobile 6 platform is Win32 and although a subset, is consistent with Win32 on the desktop. Similarly, both the Active Template Library (ATL) and the Microsoft Foundation Classes (MFC) are available and both are a rich subset of their desktop counterparts. You'll also find that much of the C\C++ code you've written for desktop applications is compatible with Windows Mobile 6. Such a high degree of compatibility exists because Visual Studio 2005 uses the same front-end C\C++ compiler for both desktop and Windows Mobile device applications.
You'll also find that your skills and experience in developing database applications for SQL Server 2000 and SQL Server 2005 transition easily to developing SQL Server 2005 Compact Edition applications. The SQL Server Compact Edition SQL syntax is completely compatible with SQL Server 2005. Similarly, the ADO.NET and OLEDB programming interfaces for SQL Server Compact Edition are consistent with the corresponding programming interfaces for SQL Server 2005. Even creating and managing a SQL Server Compact Edition database is familiar because you use the same SQL Server Management Studio tool to create and manage SQL Server Compact Edition databases as you do when creating and managing a SQL Server 2005 database.
Microsoft provides a number of resources to provide you with the guidance you need to build quality applications on the Windows Mobile 6 platform. In addition to the product documentation. there are a number of places that you can find information about Windows Mobile application development and best practices for being successful on the Windows Mobile platform.
The Windows Mobile page on MSDN® is probably the best place to start. This provides the most up to date information on Windows Mobile development. The Windows Mobile page on MSDN also includes pointers to other resources such as white papers, helpful blogs, and web casts.
The Microsoft Patterns and Practices group provides excellent guidance for Windows Mobile developers in the Mobile Client Software Factory. The Mobile Client Software Factory is a comprehensive set of best practices, samples, source code, and tools for Windows Mobile developers. The topics covered include dealing with differences in device form factors, offline data management, data synchronization, and managing large-scale applications.
The Windows Mobile Wiki is a community-supported project on MSDN's Channel 9 site. The Windows Mobile Wiki is a great way to benefit from the knowledge and experience of other developers. You'll find that the Wiki addresses many of the most common questions.
The Windows Mobile Newsgroup is a community-supported resource where you can post questions about Windows Mobile development and have those questions answered by your peers in the industry including many of the Windows Mobile Microsoft Valued Professionals (MVP).
The Windows Mobile Adapt Your App page provides the most current information on issues related to developing applications that work across the whole family of Windows Mobile devices. You'll find news, announcements, pointers to web casts, and pointers to white papers all focused in this one issue.
What’s New for Developers in Windows Mobile 5.0
Windows Mobile Developer Center: Security, Deployment, and Management
Mobile2Market Frequently Asked Questions
Mobile Client Software Factory
Mobile Line of Business Solution Accelerator Kit
Windows Mobile Adapt Your App Page
MSDN Windows Mobile Page
Windows Mobile Wiki
Windows Mobile Developer Newsgroup