The WinRT environment provides the application developer with access to the user's location via the location sensor. The location API is described in detail in my blog post, "The WinRT Location API: Where did my location data come from?", but the quick summary is that the location sensor gathers location data from a variety of hardware devices and chooses the best one to present to the user. While Microsoft has not published the exact algorithm, observation suggests that it selects the location result with the smallest, non-zero positional accuracy.
Getting the device's location from the location sensor is fairly easy, and can be done on-demand via the Geolocator.GetPositionAsync() method, or through an event handler on the Geolocator.PositionChanged event. Either way, however, it would be wise for the application developer to check the Timestamp property of the resulting Geoposition object before acting on the location data. Why? Because it's very possible that the location may be out of date.
Stale location data
Consider the following scenario: your Ultrabook has both a GPS receiver and a wireless network connection, and you use your mobile phone as a network hotspot so that you can have internet connectivity in your car. You are getting ready to go on a trip, and you want to use a cloud-based mapping app to follow your position as you drive.
You turn on your Ultrabook inside your house. Because you are indoors, it takes a while to get a GPS fix (if you can get one at all) so the location sensor turns to the Windows Location Provider which uses Wi-Fi triangulation to estimate your position. After a few seconds, your location shows up as being roughly near your house with 350 meters of accuracy.
Now, you get in your car and start driving. Since you are now in your car outdoors, your Ultrabook's GPS receiver is able to get satellite locks fairly quickly and the location sensor starts tracking your position using the GPS data. You drive for a while and note that your map application is tracking your movements pretty accurately. You continue on your journey and eventually enter a heavily tree-covered area. When you look down at your map application, your position has jumped back to your house!
Well, it's complicated. The immediate issue is that GPS signals are blocked by water, and trees contain plenty of water. A few seconds after driving under the tree cover, your GPS receiver lost satellite reception and was no longer able to determine your position.
Now the location sensor in Windows comes in to play. Because the GPS receiver is no longer providing a position, the location sensor falls back to the Windows Location Provider which attempts to use Wi-Fi triangulation. Maybe you are in a remote area where there are no wireless access points in range, or your phone has lost its data connection. For whatever reason, the Windows Location Provider is not able to determine your current position and so instead it presents you with-- you guessed it-- old data, which is your last known position. The end result is that your Ultrabook thinks you are back in your house, several miles and several minutes away.
This situation is not that uncommon, particularly in rural areas where access points are sparse and phone service potentially spotty. And there are more ways to lose GPS reception than just heavy tree cover: you could be in a tunnel, or driving through a heavy rainstorm, or maybe someone in the car just moved the laptop and temporarily blocked the GPS antenna.
If you were to look at the Timestamp property in the Geoposition object you would see that it's set to the time that you left your house. As the software developer you need to decide if stale location data is acceptable for your application. For a low precision application like a weather app, a position report that is 15 minutes or even a half hour old is not a serious problem since weather affects large areas and a device is unlikey to travel very far in such a short amount of time. For a car navigation or tracking app, however, you probably want up-to-date information at all times. A position report that is more than a few seconds old is not one that you want to use, and you are better off telling the user that you cannot determine their location than to accept a position report that is several minutes old (or older)!
The moral of the story
Always, always check the time in the Timestamp property in the Geoposition object before taking action. It is, of course, up to you to decide how old is too old, but it's an important decision and one where you, the developer, need to be in control.
Here are some other blog posts you might find useful for developing location-aware apps for Windows 8: