This article provides a comprehensive guide of how to take advantage of the many features provided by the Device Emulator including the newly available features of Device Emulator 2.0. Topics discussed include emulator configuration, managing emulator state, customizing the emulator bootstrap process, creating custom emulator skins, command line usage, and much more. You’ll also learn advanced techniques for using the Microsoft ARM Device Emulator in your mobile application development. (33 printed pages)

Microsoft® Visual Studio® 2005

Microsoft Device Emulator 2.0

Microsoft Device Emulator 1.0

Microsoft ActiveSync® 4.5

Introduction

The Basics

Managing Emulator State

Creating a New Emulator Configuration

Bootstrapping and XML Provisioning

Changing the Emulator Skin

Device Emulator 2.0

Power State Emulation

Phone Profile Emulation

Cellular Emulator

Conclusion

With the ever-increasing array of mobile devices becoming available today, the Microsoft Device Emulator 1.0, an Advanced RISC Machine (ARM) device emulator, is one of the most useful tools available to mobile application developers. The emulator provides a way to test your mobile application on a variety of devices and platforms even if you do not own a physical device. While using one or more real devices can be a valuable aspect of a testing plan, by using the emulator, you can verify your application’s behavior across a much wider variety of virtual devices and configurations than would normally be practical using physical devices. Testing an application on the emulator is faster, easier, and more convenient than with physical devices because you can easily reproduce consistent testing scenarios.

This article begins by describing the basic concepts of the emulator and related tools, and some common emulator operations. The article then explores more advanced concepts that can be useful when testing applications on the emulator. By learning and using these concepts, you will find that you can improve the overall quality of your mobile applications while reducing the time spent configuring and managing the emulator.

To help ensure a solid foundation in the basic concepts of using the device emulator, this section introduces the emulator-related tools and their common operations.

Tools

To effectively use the emulator for mobile application development, you need to be aware of the various emulator-related tools available to you, including the emulator itself, the Device Emulator Manager, Microsoft ActiveSync 4.5 or higher, the Visual Studio 2005 IDE and various remote tools that are available with Visual Studio 2005.

Device Emulator

The Microsoft Device Emulator is a true ARM emulator, and because it has the same instruction set, memory layout, and drivers as a real ARM device, you can be confident that the emulator behavior is consistent with that of a real device. Whether you are writing native or managed code, the same compiled application assemblies that you generate for an actual device are also used on the emulator when debugging applications in Visual Studio 2005. While the emulator is normally installed with Visual Studio 2005, if you need to demonstrate or test mobile applications on non-developer machines, it is also available as a stand-alone release.

As you can see in Figure 1, which shows the emulator emulating two different devices, the emulator very accurately emulates real devices, right down to the appearance and display characteristics. Visual Studio 2005 comes with four Pocket PC 2003 emulators, including standard-resolution, VGA, and square devices, and two Smartphone 2003 emulators. By downloading and installing the free Windows Mobile® 5.0 SDK for Pocket PC, Windows Mobile 5.0 SDK for Smartphone, Windows Mobile 6 Professional SDK, and Windows Mobile 6 Standard SDK, you get nearly 20 additional device emulator definitions. As you will see later in this article, you can also create your own device emulator definitions, customizing the devices’ appearance, configuration, and memory content.

Figure 1. The Pocket PC 2003 SE Emulator (left) and the Windows Mobile 5.0 Smartphone Emulator (right)

Device Emulator Manager

The Device Emulator Manager provides a consolidated view and control of all available device emulators as you can see in Figure 2. You can launch the Device Emulator Manager by choosing Tools | Device Emulator Manager on the Visual Studio 2005 menu, or by executing C:\Program Files\Microsoft Device Emulator\1.0\Dvcemumanager.exe.

Figure 2. The Device Emulator Manager

The Device Emulator Manager can serve as your central control for all emulators. With it, you can see which device emulators are currently running, start and stop emulators, simulate a warm device boot, clear saved emulator states, and connect with the host network using Microsoft ActiveSync 4.5 or higher.

ActiveSync

Using Microsoft ActiveSync version 4.5 or higher, you can simulate a physical cradling with the host machine, enabling the device emulator to access the local network and the Internet, to synchronize Microsoft Outlook® and file data with the host machine, and enabling the host machine to browse files on the emulated device, just like a real cradled device. You can download the latest version of Microsoft ActiveSync (4.5 at the time of this article’s publication) from http://www.microsoft.com/windowsmobile/activesync/activesync45.mspx.

Note:

The default ActiveSync configuration allows emulator cradling, but if you have any difficulties in cradling an emulator, you should make sure ActiveSync is configured to allow direct memory access (DMA) connections. In ActiveSync, click File | Connection Settings to display the dialog box shown in Figure 3. Make sure Allow connections to one of the following is checked and that DMA is selected in the drop-down list.

Figure 3. The ActiveSync Connection Settings dialog box

When you cradle a device emulator (by selecting the Cradle menu item in the Device Emulator Manager), the standard ActiveSync Synchronization Setup Wizard appears upon device detection. You can use the wizard to set up synchronization with the emulator if you need to, but if you are just using ActiveSync to connect the device to the network, you can simply cancel the wizard; a guest partnership is created in which nothing is automatically synchronized, but you can use all the connectivity features of ActiveSync.

Visual Studio 2005 and Visual Studio 2005 Remote Tools

You can control most of the emulator-related functionality directly from Visual Studio 2005. Using the Device toolbar, as shown in Figure 4, you can select the target of the project’s deployment. You can deploy to a physical device or to any of the installed emulators for the project’s selected platform.

Figure 4. The Visual Studio 2005 Device toolbar

Note:
Visual Studio 2005 can be installed with Pocket PC 2003 SE and Smartphone 2003 SE emulator definitions, and you can install the Windows Mobile 5.0 SDKs and Windows Mobile 6 SDKs mentioned previously for additional platforms.

You can launch the emulator that is selected in the Device toolbar’s drop-down list by clicking the first button on the toolbar, Connect to Device. The second button, Device Options, provides a shortcut to the Visual Studio Device Options dialog box. This article will discuss these device options further in a later section.

The most common feature of integration between Visual Studio and the device emulator is probably the ability of Visual Studio to automatically launch your application on the emulator when you start a project (with or without debugging). While the Device toolbar’s controls can come in handy, you usually do not need to use them to explicitly start an emulator if your purpose is simply to run and test your application on the emulator.

Visual Studio 2005 also includes several remote tools, including the Remote Registry Editor, shown in Figure 5, which are able to connect to emulators just like physical devices. When installed, they are available at Start | All Programs | Microsoft Visual Studio 2005 | Visual Studio Remote Tools. When you connect a remote tool to the selected emulator, the emulator is started if it is not already running.

Figure 5. The Remote Registry Editor

Table 1 shows a list of the remote tools and a brief description of each one. Keep in mind that these tools can be used on both emulators and real devices.

Table 1. Visual Studio 2005 Remote Tools

Remote Tool	Description
Remote Registry Editor	Allows viewing and editing of the device’s registry.
Remote Process Viewer	Displays the details of the processes running on the emulator as well as each process’ threads and modules; besides viewing the details of each process, you can also use this tool to terminate processes, which can be useful for processes that may have become unresponsive or are running in the background on the device.
Remote Heap Walker	Allows detailed analysis of the memory that is used by the device’s running applications.
Remote Spy	Displays the windows instantiated by the device’s applications and the messages received by them; provides search-by-name feature.
Remote File Viewer	Allows browsing and manipulation of files on the device, including copying files to and from the device.
Remote Zoom-In	Allows capturing of screen images from the device.

Common Operations

In addition to emulating the features of a real device, the device emulator also includes features that allow you to customize the emulator’s behavior, interact with the desktop computer file system, and map desktop serial ports to the emulator. This section covers these features and the commonly performed operations that take advantage of them.

Start the Emulator from the Command Prompt

You have already seen several ways to launch a device emulator from Visual Studio and the Device Emulator Manager, but you can also start an emulator from the command line C:\Program Files\Microsoft Device Emulator\1.0\DeviceEmulator.exe. While this command-line method of starting the emulator can be useful and flexible when used interactively, its value is really seen when applied to a scripted testing scenario. When used in conjunction with ROM image files and emulator saved-state files, command-line emulator launching can help ensure consistent loading of an emulator and its configuration for testing purposes.

To familiarize yourself with the various possible command-line options, you can run the DeviceEmulator.exe application without any command-line options, and the Command Line Option Help information is displayed, as shown in Figure 6.

Figure 6. The Device Emulator Command Line Option Help

The first parameter, binfile, is the name of a binary (commonly, .bin or .nb0) file with the kernel image the emulator is to use for ROM. If you would like to load the saved state of an emulator from a saved-state (commonly, .dess) file, use the /s filename option, but do not specify a binfile (in this case, the saved-state file would contain the necessary pointers to the device’s ROM, among other configuration and state settings). If you specify only a binfile, the device cold boots from the specified ROM image and the device’s state is not saved upon closing the emulator. Specifying both binfile and the /s option cold boots the device from the specified binary ROM file, but enables saving of the device state upon closing the emulator. You must specify at least one of these two options in order to load an emulator from the command line.

As an example, take the following command line:

"C:\Program Files\Microsoft Device Emulator\1.0\DeviceEmulator.exe" "C:\Program Files\Windows CE Tools\wce500\Windows Mobile 5.0 Pocket PC SDK\Deviceemulation\0409\PPC_USA.bin" /memsize 256 /hostkey Left-Alt /video 640x360x32

The path used for the binfile parameter in this example causes the emulator to cold boot the standard Windows Mobile 5.0 Pocket PC OS. The /memsize parameter causes the emulator to have 256 MB of RAM. Normally, all keystrokes are consumed by the guest emulator, but by specifying a /hostkey parameter and value, you can use your host machine keyboard’s shortcuts by holding the specified key while pressing the key or keys you want your host machine to process. This example command line specifies the host machine’s left ALT key as the host key. This can be useful, for example, to switch between the emulator and other windows running on your machine with the standard ALT+TAB key combination that would normally be processed by the emulator, not your actual machine, as you would normally expect. Note that whether or not the keyboard shortcut normally uses the ALT key, you need to hold down the key specified by the /hostkey parameter, in this case the left ALT key, for your host machine to receive the keystrokes. Finally, the /video parameter in this example command line causes the emulator’s screen size to be 640 pixels by 360 pixels with 32-bit color depth, which may be useful to emulate a theoretical Windows Mobile device suitable for playing full wide-screen video. As you can see in Figure 7, the device’s physical properties, like its body and any physical buttons, are not emulated when using the /video switch—only the device’s screen is displayed. As you will see later in this article, you can emulate a device’s physical layout with custom skins, which is the method that the standard Pocket PC and Smartphone emulators use.

Figure 7. A custom device emulator launched from the command line

The next few sections will present some additional useful emulator features that can be controlled both on the command line and with the emulator’s or Visual Studio user interfaces.

Access Files on the Host Computer As a Virtual Storage Card

Whether you need the ability to transfer files between the device and your physical computer, or to test the device with a virtual storage card, you can use the /sharedfolder parameter to cause the emulator to mount a specified folder on your computer, including folders on network drives, as a virtual storage card. By adding the following parameter and value to the example command line above, you can cause the host machine’s D:\Emulator\EmuStorage folder to be accessible as a storage card on the device emulator.

/sharedfolder "D:\Emulator\EmuStorage"

As is the case with many of the command-line parameters, you can also use the emulator’s File | Configure menu item or the Visual Studio Device Emulator Properties dialog box to specify shared folders. Figure 8 shows the value being set on a running emulator. Notice that some values can be configured only when an emulator is not running, as indicated by the disabled controls in the dialog box.

Figure 8. Specifying a shared folder from the emulator’s File | Configure menu item

Connect Peripherals

If you need to test physical serial peripheral devices that can be connected to your host machine, you can use the /u0, /u1, and /u2 parameters to map the device’s serial ports to your machines’. For example, add the following parameter and value to specify that the peripheral device physically connected to your machine’s COM3 serial port be available as the device’s first serial port peripheral device.

/u0 COM3

Figure 9 shows the same mapping in the Visual Studio Emulator Properties dialog box. By selecting the Create text console window for serial port 1 check box (or specifying the /c parameter from the command line), you can create a console window to show all input and output of the port selected for serial port 1. If you are using managed code, you should note that all output from OutputDebugString also goes to this console.

Figure 9. Mapping serial ports in the Emulator Properties dialog box

When you open a preset or user-defined emulator from Visual Studio or Device Emulator Manager, a Device Emulator Saved State (.dess) file for that device type is created, using a unique Virtual Machine Identifier (VMID) as the base file name. When you subsequently close the emulator, you are prompted to save any state changes, or you can use the emulator’s File | Save State and Exit menu item to save the current state of the emulator and close it. If you do save the emulator’s state, the next time you launch that emulator, its saved state will be restored, much like a physical device is powered off and then retains and restores its state when powered back on.

Note:

If you launch the emulator from the command line but do not specify a saved-state file with the /s parameter, as in the previous example, you will not be prompted to save changes when you close the emulator. You may think that using the File | Save State and Exit menu item in this situation would first save the device’s state, but it does not, because there is no known saved-state file. When using the command line, if you also want the ability to save a device’s state, you must use the /s parameter.

Using saved state files from the command line can help provide a consistent configuration for testing scenarios. To illustrate this point, consider the following procedure to create a saved emulator state and use it from the command line.

You will start by letting the emulator create a saved-state file based on the standard Windows Mobile 5.0 Pocket PC Emulator and copying that file to a new location for further modification.

You may want to create a custom device emulator configuration that you can launch from Visual Studio or the Device Emulator Manager. You can perform this action in the Visual Studio Device tools options screen as shown in Figure 10.

Figure 10. Visual Studio Device tools options

The easiest way to start creating a new device emulator configuration is to select an existing emulator that is closest in configuration to the one you want to create. For example, to create an emulator based on the Windows Mobile 5.0 Pocket PC Emulator, follow these steps:

1. In the Devices list, select Windows Mobile 5.0 Pocket PC Emulator, and then click the Save As button.
   
2. Name the emulator Widescreen Windows Mobile 5.0 Pocket PC Emulator, and click OK.
   
3. With your new Widescreen Windows Mobile 5.0 Pocket PC Emulator selected, click the Properties button to display the properties window shown in Figure 11.
   
   
   
   Figure 11. The Widescreen Windows Mobile 5.0 Pocket PC Emulator Properties window
   Notice that this screen applies properties to both emulators and actual devices. Here, you can configure the default output location to which Visual Studio deploys your application, the network transport, a bootstrapper, and device disconnection detection. If you are configuring an emulator, the Emulator Options button is enabled so you can further configure the emulator.
   
4. Click the Emulator Options button now to display the Emulator Properties window shown in Figure 12.
   
   
   
   Figure 12. The Emulator Properties window General tab
   You first saw this dialog box in the Common Operations section of this article when configuring an emulator’s shared folder and peripherals at run-time. The same dialog box is used when configuring an emulator at design-time, but at design-time, all of the options are available for modification because the emulator is not running. You have also seen that you can modify most of these parameters from the command line.
   
5. For this custom device emulator that you are creating, check Specify RAM size, enter 256 as the RAM size, change the Host key to Left Alt, and add D:\Emulator\EmuStorage as the Shared folder, making the same configuration choices as you did from the command line previously. You could also specify a custom binary file for the operating system, a ROM address in that binary image, and a file that emulates flash memory on this tab.
   
6. Click the Display tab to display the configuration screen shown in Figure 13.
   
   
   
   Figure 13. The Emulator Properties window Display tab
   
7. Again, to configure the emulator as you did previously from the command line, select Video, and enter 640 as the Screen width, 360 as the Screen height, and 32 as the Color depth.
   
8. Click OK to close the dialog, click OK again to save your configuration changes, and then click OK once more to close the Visual Studio options screen.
   
9. To launch your custom device emulator, return to the Device Emulator Manager, and click the Refresh button to add your newly created emulator to the list.
   
10. Locate and select Widescreen Windows Mobile 5.0 Pocket PC Emulator from the list, and use the Connect action to launch the emulator. It should appear similar to the one you launched from the command line previously.
    

Notice that if you close your custom emulator and save its state, a new .dess file will be created in the standard folder for your custom emulator just like the preset emulators.

Just like a real device, certain aspects of an emulator’s initial configuration, including but not limited to browser favorites, locale, clock, home screen, network connections and registry settings, can be controlled with XML provisioning. For a complete list of settings that can be provisioned, see Configuration Service Provider Reference for Windows Mobile-Based Devices. When Visual Studio deploys and runs an application on an emulator, or when the Device Emulator Manager is used to launch an emulator, you can optionally specify an XML provisioning file that is used to “bootstrap” the emulator’s configuration. This XML provisioning file must conform to the Open Mobile Alliance (OMA) Client Provisioning format; see OMA Client Provisioning Files in the Windows Mobile Version 5.0 SDK for complete details. You can see example files of each type of configuration setting at OMA Client Provisioning XML File Examples in the Windows Mobile Version 5.0 SDK.

You specify the XML provisioning file for a given emulator, whether standard or custom, in the Visual Studio Device Options Properties dialog, which you saw earlier in this article, by clicking the Configure button next to Bootstrapper and then typing the name of or browsing for an XML file, as shown in Figure 14.

Figure 14. Specifying an XML provisioning file for the custom Widescreen emulator

The following XML provisioning file will add a URL to the emulator’s Microsoft Internet Explorer® Mobile favorites list.

<wap-provisioningdoc>
   <characteristic type="BrowserFavorite">
      <characteristic type="Video Store">
         <parm name="URL" value="http://www.southridgevideo.com/"/>
         <parm name="Order" value="0"/>
      </characteristic>
   </characteristic>
</wap-provisioningdoc>

If you need to emulate the physical appearance of custom device hardware, you can easily create a custom skin with a text editor and an image editor. A custom skin consists of an XML skin definition file and an image (.bmp or .png) file that shows the appearance of the device. Optionally, you can create two additional image files, one that shows the appearance of the device’s buttons when they are pressed, and one that maps a unique color to each button. All of these files must be in the same folder. The following XML excerpt partially defines a custom skin that will accommodate the widescreen video device demonstrated earlier in this article. The complete skin definition file and three image files are available as part of the accompanying download.

<?xml version="1.0" encoding="UTF-8" ?>
<skin>
   <view
      titleBar ="Windows Mobile 5.0 Widescreen"
      displayPosX="23"
      displayPosY="21"
      displayWidth="640"
      displayHeight="360"
      displayDepth="32"
      mappingImage="Widescreen_Map.png"
      normalImage="Widescreen_Up.png"
      downImage="Widescreen_Down.png">
       <button
          toolTip="Power"
          onPressAndHold="0x75"
          mappingColor="0x00FF00"
       />
       ...
        <button
          toolTip="Soft Key 1"
          onClick="0x3B"
          mappingColor="0x330033"
       />
       ...
       <button
         toolTip="Up"
         onPressAndHold="0x48"
         mappingColor="0x00FFCC"
         KeyEvent="Up"
       />
       <button
          toolTip="Down"
          onPressAndHold="0x50"
          mappingColor="0x0000FF"
          KeyEvent="Down"
       />
       ...
   </view>
</skin>

You can see that the <view/> element contains attributes and <button/> child elements that define the skin. Table 2 shows a list of the <view/> element’s attributes that are used to define a custom skin.

Table 2. Custom skin <view/> attributes

Table 3 shows a list of the <button/> element’s attributes that are used to define a single emulated button.

Table 3. Custom skin <button/> attributes

Figure 15 shows the normal image used for the custom widescreen emulator. All buttons are in the up position.

Figure 15. The Widescreen emulator’s normal image

Figure 16 shows the down image used for the custom widescreen emulator. All buttons are in the down position. Notice that you do not need to supply the entire image of the device as you do in the normal image, just enough of the area surrounding each button as the mapping image determines, which you will see next.

Note:
The outlining dashed border is not part of the actual image, as you can see from the downloadable sample file, but is included here for visibility purposes.

Figure 16. The Widescreen emulator’s down image

Figure 17 shows the mapping image used for the custom widescreen emulator. Each button’s location is mapped with a unique color, whose RGB value is defined in the XML skin definition file.

Note:
The outlining dashed border is not part of the actual image, as you can see from the downloadable sample file, but is included here for visibility purposes.

Figure 17. The Widescreen emulator’s mapping image

To specify the custom skin that should be used for an emulator, you can use the emulator’s property pages as shown in Figure 18, or you can include the /skin parameter followed by the name of the XML skin definition file on the command line, as shown in the following command line excerpt.

/skin "D:\Emulator\EmuSkin\Widescreen_Skin.xml"

Figure 18. Specifying a custom skin file for the Widescreen emulator

Figure 19 shows the emulator running in the custom skin defined above.

Figure 19. The Widescreen emulator running in its custom skin

Up until now, all of the features discussed in this article are available to developers using both Microsoft Device Emulator 1.0 and Device Emulator 2.0. The Device Emulator 2.0 available as part of the Windows Mobile 6 SDK or as a stand-alone release, builds on these features to provide developers with an even more enhanced and productive development experience. One of the most significant changes to the Device Emulator 2.0 is the re-architecture of the just-in-time execution capabilities to improve performance of Device Emulator. Although it is difficult to quantify the precise performance gains experienced by any given application, a performance increase of up to 40 percent is not uncommon.

Note:
In this case, the just-in-time execution does not refer to the .NET Compact Framework but rather refers to the Device Emulator execution of ARM instructions.

Your desktop computer can have only one version of the Desktop Emulator installed. By installing the Device Emulator 2.0, you automatically replace the Device Emulator 1.0. To replace the Device Emulator 1.0, the Device Emulator 2.0 overwrites the 1.0 version, which results in a somewhat misleading path to the Device Emulator 2.0 executable: %ProgramFiles%\Microsoft Device Emulator\1.0\DeviceEmulator.exe.

The enhancements to Device Emulator 2.0 also include several new features aimed at providing a more complete and true-to-life testing environment. Once the Device Emulator 2.0 is installed, it is used for all of the Windows Mobile emulator images. This means that even older emulator images such as Pocket PC 2003SE take full advantage of the new features of Device Emulator 2.0. The remainder of this article discusses the new Device Emulator 2.0 features.

By their nature, mobile devices spend a great deal of time on battery power. 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 20. The Device Emulator 2.0 power state configuration control

As shown in Figure 20, the emulator configuration dialog allows you to switch the emulator state between battery power and AC power by selecting or clearing the Battery: check box. When on battery power, 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, and 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 21 you can enable each of these profiles by selecting the appropriate check box in the emulator configuration dialog box. When you select the profile check boxes, the emulator behaves just as if you have plugged in a headset, enabled the speakerphone, or connected a car kit. As part of the phone profile emulation, the Device Emulator 2.0 raises all of the appropriate State and Notifications Broker events.

Figure 21. The Device Emulator 2.0 phone profile configuration controls

One of the most significant enhancements to the Device Emulator 2.0 is not actually part of the Device Emulator 2.0. It is instead a separate emulator, the Cellular Emulator, which cooperates with the Device Emulator 2.0 to provide cellular-based features to the Device Emulator 2.0. The Cellular Emulator, shown in Figure 22, emulates a cellular radio and provides the Device Emulator 2.0 with the ability to send and receive calls, send and receive Short Message System (SMS) messages, and establish a General Packet Radio Service (GPRS) connection to the network. As part of the GPRS connection features, the Cellular Emulator can emulate switching between 2G and 3G networks, and can emulate dropping the GPRS connection.

Figure 22. The Cellular Emulator

To use the features provided by the Cellular Emulator you must create an association between the Device Emulator 2.0 and the Cellular Emulator. To create this association, follow these steps.

1. Take note of the COM port number displayed in the lower-left corner of the Cellular Emulator; COM4 in Figure 22.
   
2. Open the Emulator Properties dialog box. To open the Emulator Properties dialog box, select File on the Device Emulator menu, 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 23. If you do not see the COM port number in the drop-down list, you can enter it yourself.
   
5. Close the Emulator Properties dialog box. To close the Emulator Properties dialog box, click OK.
   
6. Perform a soft reset of the Device Emulator 2.0. To perform a soft reset, on the File menu, click Reset, and then click Soft.
   

Figure 23. Entering the Cellular Emulator COM port number to enable cellular service emulation for the Device Emulator

With the Device Emulator 2.0 and the Cellular Emulator connected, you can now make and receive phone calls. To make a phone call, you simply dial the phone on the Device Emulator 2.0. The other phone emulator features are available on the Cellular Emulator Call Manager tab shown in Figure 22. Table 4 describes each of these features.

Table 4. Cellular Emulator Call Manager tab features

The Cellular Emulator Network tab, shown in Figure 24, allows you to control certain behaviors of the Device Emulator 2.0 GPRS connection. Table 5 describes each of these features.

Figure 24. The Cellular Emulator Network tab

Table 5. Cellular Emulator Network tab features

With the Cellular Emulator connected, the Device Emulator 2.0 can send SMS messages. The SMS tab, shown in Figure 25, allows you to see the messages that the Device Emulator 2.0 sends; the SMS tab also provides a facility to send SMS messages to the Device Emulator 2.0. Table 6 describes the SMS tab.

Figure 25. The Cellular Emulator SMS tab

Table 6. Cellular Emulator SMS tab features

Note:
At the time of this writing, the SMS tab misspells the Repeatedly check box. The Network tab currently displays the check box label as Repeatly.

The Cellular Emulator Injection tab, shown in Figure 26, allows you to modify the state of the Cellular Emulator. This tab exposes features intended for developers who need to emulate modifying the state of a cellular radio; most application developers do not need to use the features provided by this tab. For those developers who do need to modify the state of the Cellular Emulator, you can enter your own AT commands on this tab. For the most part, the AT commands conform to the 3GPP standards. Table 7 describes the Injection tab.

Figure 26. The Cellular Emulator Injection tab

Table 7. Cellular Emulator Injection tab features

Note:
At the time of this writing, the Injection tab’s Predefined Events field misspells the Custom Event value. The field currently displays the value as Customer Event.

The Configuration tab, shown in Figure 27, allows you to modify the SIM/USIM configuration of the Cellular Emulator. The features provided by this tab are intended for developers familiar with SIM/USIM file systems; most application developers do not need to use the features provided by this tab. Table 8 describes the Configuration tab.

Figure 27. The Cellular Emulator Configuration tab

Table 8. Cellular Emulator Network tab features

The AT log tab, shown in Figure 28, displays a history of the AT commands sent between the applications running on the Device Emulator 2.0 and the Cellular Emulator. All commands that begin with >> are commands sent from the Device Emulator 2.0 to the Cellular Emulator. All commands that begin with << are commands sent from the Cellular Emulator to the Device Emulator 2.0.

Figure 28. The Cellular Emulator AT Log tab

In this article, you have seen that by effectively using the Microsoft Device Emulator, you can greatly improve your mobile application’s testing coverage, while avoiding the cost of multiple physical devices. You have seen that you can customize the behavior and appearance of the emulator to fit your needs and automate your testing procedures, thus improving your overall testing reliability. Finally, you have seen that the Device Emulator 2.0 provides a number of improvements over the Device Emulator 1.0 that allows you to more thoroughly test your applications.