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.

Faster Execution

More Emulated Devices

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.

Power State Emulation

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.

Phone Profile Emulation

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.

1. Take note of the COM port number displayed in the lower-left corner of the Cellular Emulator; COM4 in figure 5.
   
2. To open the Emulator Properties dialog box, on the Device Emulator menu, select File, and then click Configure…
   
3. In the Emulator Properties dialog box, click the Peripherals tab.
   
4. Enter the COM port number from the Cellular Emulator into Serial Port 0 as shown in figure 6. If you don't see the COM port number in the drop-down list, you can enter it yourself.
   
5. To close the Emulator Properties dialog box, click OK.
   
6. To perform a soft reset, on the File menu, click Reset, and then click Soft.
   

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.

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.

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.

Windows Forms Controls

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.

MonthCalendar and DateTimePicker Controls

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.

WebBrowser 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

Notification Control

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.

Other Controls

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.

Support for Device Form Factor Differences

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.

Keyboard Interaction and Keyboard-based Navigation

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.

Relational Data

XML

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

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.

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.

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

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.