How to Write a Location-Aware Application Using .NET

As we already mentioned, when using .NET you are using a strongly typed location provider. These are just regular classes that you can initiate. After you obtain such a location provider class, you can simply start using it. In our example, we use the CivicAddressLocationProvider, as shown in the following code snippet:

CivicAddressLocationProvider civicAddressLocationProivder

	= new CivicAddressLocationProvider(1000);

ReportStatus locationReportStatus =

	civicAddressLocationProivder.ReportStatus;

if (locationReportStatus == ReportStatus.Running)

{

	locationListener.PrintLocationReport(

 	(CivicAddressLocationReport)

 	civicAddressLocationProvider.GetReport());

}

//register for location events

civicAddressLocationProvider.Locationchanged +=

	locationListener.LocationchangedEventHandler;

civicAddressLocationProvider.StatusChanged +=

	locationListener.StatusChangedEventHandler;

The locationListener class will soon be used as our event handler for handling the location events. This class also includes several helper functions for printing location reports.

First, you need to create a new instance of CivicAddressLocationProvider. The constructor of all location providers expects an integer (uint) value that defines the initial value of the minimum report interval. You can later change this value using the ReportInterval property.

Next, you can check the status of the report. Any location provider has a ReportStatus value that indicates the operational state of the location provider. We already covered the exact states in the the section called “Understanding the Location Report Status” section earlier in this chapter. Similar to the native API, the Civic Address location report status might be in a ReportStatus.NotSupported state—that is, if the default location is not set.

However, assuming the default location is defined, you can call the location provider GetReport function. This function returns a LocationReport that is the base class for all the reports—again, it's equivalent to the native ILocationReport interface. Therefore, you need to cast the return value to the desired report type, which in our case is CivicAddressLocationReport. Then you pass this location report to a helper function that prints the report to the console application.

The last two lines in the code snippet register an event listener to the two events that CivicAddressLocationProvider exposes. Again, these events are identical to the native events defined in the ILocationEvents interface. The following code snippet shows the implementation of LocationchangedEventHandler in our .NET console application:

public void LocationchangedEventHandler

	(LocationProvider locationProvider, LocationReport newLocation)

{

	if (locationProvider.ReportStatus == ReportStatus.Running)

	{

 	LatLongLocationReport latLongLocationReport

 	= newLocation as LatLongLocationReport;



 	if (latLongLocationReport != null)

 	{

 	Console.WriteLine("new Lat Long Location");

 	PrintLatLongLocationReport(latLongLocationReport);

 	return;

 	}



 	CivicAddressLocationReport civicAddressReport

 	= newLocation as CivicAddressLocationReport;



 	if (civicAddressReport != null)

 	{

 	Console.WriteLine("New Civic Address Location");

 	PrintCivicAddressLocationReport(civicAddressReport);

 	}

	}

	else

	{

 	//handle error

	}

}

Here you can see that LocationchangedEventHandler, called when the Locationchanged event fires, receives two input parameters: a location provider and a location report. Both are abstract base classes for more specific classes. Therefore, you use this function as a more generic event handler that handles events for both the Lat-Long and Civic Address location providers.

First, you need to check the status of the report. Assuming the status of the location provider is in its running state, you can next cast to the desired report type. In this case, you simply try to cast the input location report object, newLocation, into both location report types, using the .NET as statement. First in order is the Lat-Long location report type. If the newLocation object is of type CivicAddressLocationReport, the newLocation as LatLongLocationReport returns null and you try your luck with the second cast, which is the Civic Address report. Then you call the relevant print function to print the report values.

You can test this application in the exact same way we tested the native application shown earlier. However, there is a much cooler way to do so: use the enhanced default location provider.

The enhanced default location provider (eDLP) tool is a Windows Presentation Foundation (WPF) open-source example that the Windows Sensor and Location team put together to illustrate the use of the .NET Location API. The binaries of this tool can be found with the rest of the code samples for this chapter. The entire source code of the eDLP and the .NET Location API, can be found at the MSDN Developer for Windows 7 site (http://code.msdn.mic...sorsAndLocation).

The eDLP displays Virtual Earth maps within a Web browser control, as shown in the following image. You can right-click any location on the map to set the location values. You will see the geographic coordinates (latitude and longitude) change each time you right-click on a different location on the map. The Address values will be set only if you right-click within the boundaries of any known city or town.

The Save Address button saves the current address as your Default Location value in the Location And Other Sensors Default Location dialog, shown in the the section called “Default Location” section earlier in this chapter. Therefore, if you run the eDLP tool alongside your application, each time you save a new address you will see the new address in your console application as a result of handling the location change event. This application requires administrator rights because you are changing the value of the default location.