Well I was going to make it an adventure – and I did have a little one – but TBH it’s pretty well documented (there’s also a document in the download) and there are a couple of crucial limitations which put me off doing a full post about it (which I’ll mention in a moment).
Windows Phone 7 Recipes are a combination of code and guidance for addressing common scenarios. eg there is a recipe for GPS emulation (making it possible to do location testing on the emulator) and there is a recipe for Push Notification services (wrapping boilerplate code to make it neater and simpler to implement).
For the GPS Emulator, the way this works is as follows. You’re given a “fake” GeoCoordinateWatcher class (see right). Instead of talking to the private location API on the device this class listens to a WCF service for location coordinates.
The recipe also includes a WPF application. Using this app you can create a route and then replay it, exposing the coordinates via a WCF service that can be consumed by the client.
(If this sounds familiar it might be because we’ve seen it before)
This allows you to debug location services on the emulator (not possible without some form of mocking). It’s also useful on the device if you don’t fancy wandering aimlessly around your neighbourhood staring at your phone with a laptop under you arm for debugging.
There are a few limitations that became clear quite quickly however (and are borne out in the comments on the original post).
The “fake” GeoCoordinateWatcher implements IGeoPositionWatcher. The suggested way to approach the emulation is to use a #if directive to instantiate the required concrete type as an IGeoPositionWatcher. The trouble is, this interface doesn’t expose all the functionality you’ll want – MovementThreshold for example isn’t part of the interface – so you’re immediately in a bit of a quandary.
I did a quick scan of the “fake” GeoCoordinateWatcher implementation and there doesn’t seem to be any MovementThreshold testing implemented either. In other words, you’ll get status updates whether or not they’re greater than the defined MovementThreshold. That’s a difference from the “real” behaviour.
Also, there appears to be problems with the rate of replay. The device updates location typically at around 1Hz. The GPS Emulator implementation can drive things significantly faster.
I don’t doubt that improvements will be made to the GPS Emulator Recipe to address these issues. Meantime it does offer a useful mechanism for testing location apps – just be aware of the limitations / differences.