One of the key components of a mobile development environment is the emulator that will allow developers to test their applications (to some extent) without an actual device. In fact, this is a logical approach – you probably wouldn’t want to connect the phone to the computer each time you want to debug an app.
The next article in the "Android and Windows Phone 7 comparison" set describes the Windows Phone 7 emulator and some of its capabilities and interesting features.
The Windows Phone 7 emulator is bundled by default with the development tools provided by Microsoft and it is located in C:\Program Files (x86)\Microsoft XDE\1.0 (for 64-bit systems) and C:\Program Files\Microsoft XDE\1.0 (for 32-bit systems). It is started from the command line, the OS image being passed as a parameter. The actual image that is bundled with the tools is a locked ROM and is located in C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.0\Emulation\Images (for 64-bit systems) and C:\Program Files\Microsoft SDKs\Windows Phone\v7.0\Emulation\Images (for 32-bit systems). Or you cna always start the emulator from Visual Studio, when working on a Windows Phone 7 application.
To start the emulator, start the system console and type the path to the XDE executable, passing the path to Windows Phone 7 OS image as the first parameter.
The default ROM doesn’t come with a lot of pre-installed software – the only default program you will be able to work with is Internet Explorer, but it is fully-functional. I would highly recommend avoiding any "unlocked" images for two reasons:
1) Support - if you encounter any issues, you are on your own. Since it is untested and unspupported by Microsoft, you won't be able to really have help in solving those issues.
2) Performance / Stability - this should come as obvious, but the performance and stability of an OS that is not provided by Microsoft is at least questionable.
Therefore, for development and testing purposes, the official OS image is the way to go.
The situation in the actual RTM build of the tools might be different, but for now you aren’t able to access any other default functionality, like messaging or calling services.
Generally, the emulator is not customizable. However, if you launch it through the command line, you can set some of its basic properties via the following parameters:
- /battery – specify whether the emulated device runs from battery or is connected to a AC source
- /batterycharge <percentage> - the battery charge percentage
- /cpucore – defines the type of CPU used (ARMv4, ARMv5 or ARMv6)
- /flash <filename> - defines whether the device is using flash memory storage, and if yes – where is the information stored
- /memsize <size[MB]> - defines the emulated RAM size for the emulated device
- /rotate <0/190/180/270> - defines the device rotation
- /video <width>x<height>x<bit depth> - defines the parameters for the emulated device display
There are some more parameters you can use. The complete list can be displayed if you launch XDE without passing BIN image as a parameter. However, the ones outlined above are probably the most important for testing purposes in the majority of experimental cases.
The current version of the emulator doesn’t enforce strict limits on device storage. It also lacks support for accelerometer and additional hardware, so experimenting with those would require an additional data simulation layer in the tested application. That being said, the SDK still provides tools to interact with hardware elements and services that are not supported by the emulator. You will need an actual device to test those for now.
It runs quite fast, however it is highly dependent on available system resources. Generally, if there is 1.5 GB free RAM and the CPU load is lower than 50% (tested on a Core 2 Duo 2.0 GHz / 3GB RAM machine), the emulator will work fine. If these requirements are not met, then there is a high chance that the deployment will fail. While testing on various applications, I noticed that when there are not enough system resources, and I will try launching the deployment process for a XAP package, it will start loading in the emulator but eventually will fail on reaching the page loading stage.
Resource-wise, the Windows Phone 7 emulator mostly loads the CPU and not the RAM (tested on a dual-core machine with 3GB RAM):
The toll on the CPU and RAM is generally constant and doesn’t really depend on the application that is used. Small variations (+/- 10% maximum) are possible but not likely unless a highly resource-consuming application is used (for example, a game).
I can think that the emulator will have major improvements in the final build of the devleopment tools since it is quite limited for now. Users aren't able to create multiple instances of the same emulator that will have various characteristics (like, various hardware elements turned on or off). At this point it is safe to say that all Windows Phone 7 devices will have very similar characteristics and follow the outlined requirements to be WP7-compatible, however it is always easier to see how your application would behave in an environment that could be more or less limited, resource and hardware-wise.