When the Windows Phone 7 developer toolkit came out, .NET developers with and without Silverlight experience tried to work on some applications for the new platform. And since the sub-framework itself is based on existing libraries, it wasn't that hard to start working with a limited subset of Silverlight (in some circles known as Silverlight 3.5). At the time of release, not every (if any) developer outside Microsoft had the possibility to test applications on an existing device. Although it didn't seem too big of a problem since there is an emulator bundled with the dev tools, it is absolutely wrong to assume that it is possible to develop applications in the long-run without an actual device.
Some people might assume that the main reason for this is performance. I should mention - the emulator performance is very close to the one of the phone itself. Since it is running in a virtualized environment, there are specific built-in "rev limiters" that won't let the emulator perform like a full-fledged computer, but rather as a machine with limited resources. So for now we can set this aside (I am saying "for now" because in some cases real device performance matters - e.g. in games).
There are specific conditions that you can only test on the phone itself. These include:
- accelerometer-powered actions
- location services
- ability to work with limited Internet connection (e.g. via EDGE)
- ability to work in Airplane Mode
- ability to work when the phone locks itself after a specific period of time
Below I am going to elaborate a little bit on each of these elements.
Obviously, you cannot tilt a computer screen. And the emulator itself doesn't represent a free-to-move entity that determines the rotation of the window itself, therefore there is no way you can test accelerometer capabilities on your developer machine. I've talked about this already - there are workarounds to this (e.g. mocking the accelerometer service by passing simulated values obtained from a connected mouse), but no workaround will show you the way an actual device reacts to user movement and device manipulation.
Same as the accelerometer, this can be emulated by passing mocked values. However, if you really need to see the precision a device is able to determine the owner location with, you will need to work beyond the emulator.
For obvious reasons, you are not able to use the FM radio in the emulator. Mainly because that would force specific hardware requirements that are complementary (e.g. a tuner card) on the developer machine itself. Unlike the accelerometer and location services, you cannot emulate the radio other than include mock actions that will be used as launchers for the radio application.
Ability to work with a limited Internet connection
This is the interesting part, and what's even more interesting is the fact that you should never make assumptions as to what connection is used on the cellphone. I've seen horrible code that is set to download something and the thread is sleeping for, let's say, 10 seconds. Obviously, on a fast connection this could make sense, but when the connection is a bit slower, this type of code will break like a card house. Not to say that this is a bad practice, you should make sure that the same downloaded/uploaded content can be activated on slower connection. And of course, you might want to re-think some bandwidth strategies when you know that there are large information chunks to be downloaded - the users most likely won't appreciate even a 20MB download on an EDGE connection. There is no way to test this kind of compatibility in the emulator unless you physically limit the Internet connection on your PC.
On a sidenote, you can always check the type of connection and accordingly with the help of Microsoft.Phone.Net.NetworkInformation.
Ability to work in Airplane Mode
As ironically as it sounds, I got an application rejected from the App Marketplace because I didn't test my application in Airplane Mode. When the phone is disconnected from everything (both WiFi and cellular data network), the absence of an active Internet connection might trigger unpredicted consequences. Airplane Mode cannot be triggered in the emulator itself, therefore you need a device to debug on to see how the app reacts in limited conditions.
Ability to work when the phone is locked
When you run your application in the emulator, it is constantly running and you can always see the progress - after all, there is no "backlight timeout" on the emulator itself. But there is such a thing on the phone. After a specific period of inactivity, the phone goes into sleep mode, activating the lock screen and turning off the screen itself. When this happens, you need to make sure that the application correctly stores its current state and is able to resume normal activity when the user unlocks the device. If this is not handled correctly, you might end up with a crashing application. And although you can test deactivation/activation states on the emulator, some applications might act different when this process is triggered almost automatically.
That being said, if you are serious about Windows Phone 7 development, investing some money in an actual device for testing purposes might just make sense. Of course, you will need a paid developer account to actually be able to debug on the phone, but at the end it might result in better user experience.