Windows Phone 7.5: Building Location-aware Applications

The concept of location-based services refers to services that integrate a mobile device's location with other topical information, to provide additional value to users. Consider a weather app that shows weather information for all of the United States of America cities. For a user living in San Francisco, this behemoth of information is not very helpful unless he can see the exact weather information for his city. This is achieved by mashing up the weather information with the user's location (generally obtained using a GPS system).

Another example of LBS is local search websites such as CitySeekr.com that presents a user with hyperlocal (read local, nearby, or neighborhood-centered) information about hotels, restaurants, shopping and entertainment venues that makes the user feel connected with the type of information shown to him/her. Still another example is the integrated Bing search in your Windows Phone 7.5 based phone (Nokia Lumia 800 in our case), which fetches the search request for hotels in san francisco with the location angle as well as regular web and image search, as shown in the following screenshot:

The core requirement for LBS is GPS (this will be covered in more detail shortly), a space-based satellite navigation system developed and maintained by the United States of America. Other countries also have similar systems; Russia has the Russian Global Navigation Satellite System (GLONASS) and Europe has the Galileo positioning system. India and China are working on their own positioning system as well, but GPS remains the most popular and preferred choice for device makers and application developers worldwide.

Anyone can use GPS freely by using either a Personal Navigation Device (Garmin, TomTom), an in-car navigation system (Ford SYNC), or using a smartphone.

On the mobile front, LBS also uses Bing, Google Maps, and other cartographic API services extensively (even in cases where the device does not support GPS). This is done using rich map data and geocoding services. Using geocoding and smart algorithms, a user's position can be guessed or approximated. Mobile operating systems such as Windows Phone 7.5 further the cause of LBS by integrating location into the core OS, where the location can be fetched, used, and updated by all applications.

Microsoft Windows Phone 7.5 (code name Mango) supports a Location Service Architecture that can obtain location data from the cellular network, Assisted GPS (A-GPS) that uses the network's data connection in case of weak GPS signals, as well as Microsoft's own Wi-Fi location database providing developers with a plethora of location tools and APIs to work with.

In short, LBS can be described as a combination of two services: location providers and location consumers, with GPS, A-GPS, and Windows Phone 7.5 Location API as the location providers, and GPS receivers, Windows Phone 7.5 devices, and websites as the consumers of location data.

As the book deals with Windows Phone location-aware apps, it is a good time to understand the following buzzwords and key terms used in the location-based industry:

The primary use of location-based services combined with GPS was and will remain the same: Navigation. There are new and exciting (and sometimes crazy!) ideas being implemented using LBS every other day. Research and Markets (http://www.researchandmarkets.com/) has predicted a market of US $10 billion for the LBS industry in 2015, from $2.8 billion in 2010. GigaOM (http://gigaom.com), a technology blog by Silicon Alley veteran Om Malik, has similar views on the LBS industry. Each year new location-based startup companies are being formed to bridge the gap between the vast information on the Internet and its availability for the local consumers/users.

Government and military, navigation, commercial industries such as advertising, social networks and web portals are the primary consumers of location-based services. GPS in fact was funded by the US Department of Defense (DOD) and still is maintained by DOD. It was initially designed for military use; in the late 1980s and early 1990s it was opened up for civilian use. Let us review the common use cases:

Microsoft's Windows Phone 7.5 (Mango) is a fresh new approach to mobile operating systems and user interfaces. In fact Microsoft has got good reviews from every quarter of the mobile phone world. What's different with Windows Phone is the emphasis on an integrated user experience rather than apps. The Metro user interface is clean, engaging, exciting, and different. Keeping the interface relevant and inclusive for the users, Microsoft has kept location as a compulsory hardware requirement for all Windows Phone handset manufacturers. This also signifies the important role of location in current and future Windows Phones. See Hardware Specifications for Windows Phone at:

http://msdn.microsoft.com/en-us/library/ff637514(v=vs.92).aspx)

Let us now understand how Microsoft uses LBS in Windows Phone 7.5. As we learnt earlier, all WP7.5 phones have A-GPS and Wi-Fi capabilities built in the phone. This coupled with the Microsoft Location Service completes the location hardware and software required to build our location-aware apps!

Microsoft Location Service

In order to use the location APIs in your WP7.5 application, you need to include the System.Device.Location assembly in your application. Before you can use location in your app, make sure your device has location enabled; if not, you can enable it from the SETTINGS page on your WP7.5 Phone, as shown in the following screenshots from our Nokia Lumia 800:

The GeoCoordinateWatcher class is the class which exposes the Windows Phone Location Service. It contains methods for both:

• Getting location information on demand

• Sending location information on position change or status change

Lastly, as with all mobile phone platforms, Microsoft has bundled an excellent location sensor simulator with the Windows Phone 7.1 SDK, which can be used to simulate location via live real-time values as well as saved values as shown in the following screenshot:

Let's learn a bit more on GPS as it powers all the current LBS implementations. If you are building the next generation navigation software or your own mapping applications, it is the right time to know more about GPS and how it works, so that it helps you make key decisions for your application.

GPS has three major components as shown in the next diagram (diagram courtesy Jörg Roth: http://www.wireless-earth.de/jr_eng.html): user segment (GPS receivers, mobile phones, car navigation units), space segment (24 satellites in orbit), and the GPS control segment having a base on Earth with the Master Control Station (MCS) in Colorado Springs, Colorado (so now you know where to head to get a clear signal!)

Location-based service implementations are either based on push services or pull services, depending on the way location information is retrieved.

There are alternate ways to detect location from mobile phone devices using their Wi-Fi MAC addresses (access points that connect to the internet) to determine/approximate the user's location.

Wi-Fi based positioning returns the approximate location, which may not be the exact latitude-longitude pair, but it does not provide a high level of precision.

Companies such as Skyhook Wireless and Google (with Google Latitude) were the first to provide this service. Microsoft launched a similar service under the "Managed Driving" name in July 2011, which uses cars driven around cities collecting Wi-Fi information broadcasted by public Wi-Fi access points. This coupled with location obtained from Windows mobile devices completes the data aggregation loop for Microsoft's own positioning database.

Skyhook Wireless location is pretty much public, with provisions for end users to add their location data to its database via a web interface, which is then available to all implementations of Skyhook wireless API users. Their database uses over 250 million Wi-Fi access points and cellular tower information for location analysis. Skyhook deploys data collection vehicles to conduct the access point survey, similarly to the Google Street View cars. The accuracy provided by Skyhook Wireless is 10 meters. To know more about Skyhook Wireless coverage go to:

http://www.skyhookwireless.com/howitworks/coverage.php

To get an idea on how Skyhook Wireless works:

The following screenshot shows my location on loki.com:

Low-cost or price-sensitive mobile phones often come without GPS or Wi-Fi. These phones are meant to do what mobile phones are intended to be used for Talk. However, location of the user can still be detected on such phones using cellular towers. Cell-ID positioning and cell tower triangulation are two different ways to get location information from cell towers. Cell-ID result accuracy is only 200-1000 meters; hence it is used as the last option for most location-detection methodologies.

Cell-ID positioning uses your mobile network's cell tower to find your location. This involves the nearest tower to which your phone connects when you place calls. Cell tower triangulation on the other hand uses all the cellular towers around you to calculate your position, based on the signal strength your phone receives from each of the towers. Triangulation is more accurate, however it is a slower process.

Bing Maps provides a REST API for creating a static map with pushpins, geocoding an address, and creating routes. There are a plethora of options available for Microsoft lovers (http://msdn.microsoft.com/en-us/library/dd877180.aspx) ranging from Ajax controls to iOS controls for using Bing Maps in your application. We will, however, use the REST API to determine the user's location (when Wi-Fi and cellular radio is not available to determine location).

Specifically we will use the Bing Maps API to convert a user address into location; this process is known as geocoding, as described earlier. Bing Maps uses these coordinates to plot the locations on a map. The Bing Maps API provides an option for both geocoding and reverse geocoding.

To illustrate a simple REST API call from the Bing Maps API that finds location by a given address, see http://msdn.microsoft.com/en-us/library/ff701715.aspx. The Geocoding API is consumed by the following API call:

http://dev.virtualearth.net/REST/v1/Locations/US/adminDistrict/postalCode/locality/addressLine?includeNeighborhood=includeNeighborhood&key=BingMapsKey, where the output can be either JSON or XML, and the parameters can be either of the following:

An example geocoding request for Microsoft Corporation office at Mountain View, San Francisco, CA, USA is constructed as:

http://dev.virtualearth.net/REST/v1/Locations/US/CA/94043/San Francisco/1065 La Avenida St?o=xml&key=xxxxxxxxxxxxxxxx, where xxxxxxxxxxxxxxxx is the Bing Maps API key you obtained from https://www.bingmapsportal.com/. This API call returns the following results:

Our interest lies is in the<Latitude> and<Longitude> XML nodes, which hold the location value for the address we specified. If you do not have the exact address, you can use the Find a location by Query API call of the Bing Maps API, where the input can be any query string. Depending upon your app's targeted region, construct the right REST call. As they say, "Read the documentation carefully".

Navigation functionality in cars, airplanes, railways, and mobile phones is mostly optimized for on-the-move functionality. It assumes that the user of such services tends to exhibit movement from one place to another with time. This is classified as outdoor navigation, implying navigation done outside homes, offices, malls, and any place not confined to a building or large area.

This is where indoor navigation sets in. Although GPS and other positioning systems have high coverage and accuracy, they fail when you are indoors, in a mall, or a shopping complex; even airport lounges, stadiums, and office complexes because the radio signals from GPS transmitters cannot penetrate walls. Indoor navigation works in such places using techniques dissimilar to outdoor navigation; in short, there is no GPS for indoor navigation.

There are various implementations of indoor navigation, some using infrared techniques, some using radio signals (RFID), and another implementation using ultrasound. Companies like Visioglobe (http://visioglobe.com) offer an SDK for indoor navigational purposes. Another company WiFiSLAM—is building a Wi-Fi based solution. While the market for indoor navigation is quite big and the outlook for growth is very positive, the implementation and standardization is at a very nascent stage, partly due to the fact that a generic solution that fits all is not possible for indoor navigation. Also, interactive kiosks at malls, airports, and convention centers solve the problem of information management for visitors.

In this introductory chapter, we have identified how location-based services work, the buzzwords behind all things location and the importance of GPS.

Specifically, we discovered location-based services and their applications in the real world, how Microsoft uses location in its Windows Phone 7.5 devices, and GPS and non-GPS based solutions for location. We also discussed new potential in LBS markets, that of indoor navigation.

Now that we've got our feet grounded in location, we can move to the next chapter that covers Windows Phone 7.5 Location Services!