Chapter 7. Connectivity issues
- Key success factors for connectivity
- Security of location data
- Examples of location-aware applications
Undoubtedly, one of the key benefits of location-based services is their ability to automatically detect where the mobile user is and offer relevant information based on the user’s location. The requirement to constantly know where the user is brings with it a number of development challenges. Solutions for these challenges should anticipate the likely behavior of the user.
If the application is to be used on an ad hoc basis for very brief periods, then an on-demand approach will offer better performance than an always-on application. An on-demand application will likely require more time to get a location fix for the user than an always-on application. In addition, memory capacity on mobile phones requires smart tactics to be deployed to ensure users can access the location information they require quickly and with the fewest possible number of clicks.
In this chapter, we’ll analyze key connectivity factors for a successful LBS application, such as quick fix times, appropriate accuracy, minimized battery usage, and meaningful and constant feedback to the user during fixes.
7.1. Key success factors in connectivity
Current GPS platforms, such as smartphones, generally deliver a worse experience than dedicated personal navigation devices with the same technology. This lag in smartphones is due to heavy battery consumption, the time required to get a fix on GPS satellites (because the GPS device has to turn on and off to save power), and interference from other electronics inside the devices causing less accuracy and wrong results. Personal navigation devices also have the benefit of better antennas and being single-purpose devices, so that they can use the battery more efficiently.
For a location-based mobile application to have successful and functional connectivity, the following are the crucial factors:
- Quick fix times— GPS takes a long time and may require a TTFF (Time To First Fix) of several minutes to over 10 minutes to initially determine location, thereby causing inconvenience to the users of location-based wireless internet services.
- Appropriate accuracy— High-accuracy location fixes take longer and consume more battery power. Depending on the nature of the location-based service,
the application should always request just enough accuracy, as shown in figure 7.1, from the location service to optimize battery use and minimize TTFF.
Figure 7.1. LBS app displaying the accuracy of the location fix to the user in real time
- Minimal battery usage— Keeping a GPS on constantly will drain its batteries. GPS was not designed to be navigation-centric. If you try to make the location available all the time, you’ll quickly drain the battery.
- Constant and appropriate feedback to the user— The application should always keep the user informed about what’s going on regarding the location fix. Whatever the application is doing, it should always give feedback to the user about the progress through the user interface. An application that becomes unresponsive during a location fix is not acceptable.
7.1.1. Smartphones
Smartphone platforms such as the iPhone,[1] Android,[2] BlackBerry,[3] Web OS,[4] and now Windows Phone 7[5] have transformed mobile application development by providing simple platform-native API calls to retrieve the location of the device. Developers no longer have to do this task themselves using custom databases and algorithms. This disruption helped start the flurry of location-based applications on major smartphone platforms.
5 mng.bz/9jIk
When developing an LBS application on a smartphone, as shown in figure 7.2, all you have to do is call the API to get the location of the user. Still, there are cautions you should watch for:
- Don’t request the location of the user too often.
- Adjust accuracy to the minimum acceptable radius for your application.
- Always tell the user what’s going on in the user interface.
Figure 7.2. An iPhone LBS application asking for permission to access the user’s current location
Now let’s look at some tips for developing location-aware applications for feature phones.
7.1.2. Feature phones
Phones that are running Java ME provide bigger challenges than the smartphone platforms mentioned previously.
Some Java ME platforms have built-in location-provider modules that can provide the location of the device, as shown in listing 7.3.
If the Java ME platform doesn’t provide built-in location capabilities, the application usually has to access the cell towers around the device and do a database lookup to find the locations of these cell towers, and then it must use an algorithm to estimate the location of the device. Cell tower location databases are available commercially and from open source projects such as celldb.org and opencellid.org.
Even if the specific device has location providers, LBS applications should always be designed to work even without a built-in location provider. This definitely makes developing LBS applications on plain Java ME platforms more complicated than developing for smartphones, but with proper design and coding, you can safely alleviate these disadvantages.
Next we’ll look at security issues for location data, which is another major concern for consumers.
7.2. Security of location data
Electronic Frontier Foundation[6] and various other organizations have done extensive studies on privacy and location-based services. One obvious problem is that services may expose your location to others.
The first step for any LBS application is to be very explicit about how the location data of the user is used and where it’s kept, if it’s kept at all. Some LBS applications, such as Centrl, don’t keep the location history of their users. These applications keep only the last-known location of the user for a given period (for example, one week). After this time, the location of the user is removed from the system.
The second step is to always let the users decide how they want to update their location. This can be done easily through settings, as shown in figure 7.3.
Figure 7.3. Settings for updating the user’s location in the Centrl LBS application
The third step is to make sure the application doesn’t accidentally expose the location and location history of a user to those with access to the mobile device or the servers that retain the data.
7.2.1. Caching location files
LBS applications must ensure that third parties can’t access any location files that are cached locally on a mobile device. You can easily accomplish this by encrypting these files and removing old cache files as they become obsolete and unnecessary.
7.2.2. Server databases
LBS providers should employ reasonable administrative, physical, and/or technical safeguards to protect a user’s location information from unauthorized access, alteration, destruction, use, or disclosure. In addition, these servers should always be monitored and tested to make sure that unauthorized persons can’t access the databases.
Now let’s look at some code examples that show you how to get started for various platforms.
7.3. Location-aware platform examples
There are different APIs for retrieving a user’s location on different platforms. These APIs are becoming more robust because the underlying technologies are being improved constantly with the current focus on LBS.
Now let’s look at some examples of how you can get the location of the user on some platforms, starting with the iPhone.
7.3.1. iPhone and iPad example
The first listing is an example of getting the location of the user on the iPhone or iPad.[7]
Listing 7.1. Using the CoreLocation API on the iPhone and iPad
This code example creates the location manager if it doesn’t already exist 
and then makes the request to get the location 
. The didUpdateToLocation function gets the location value 
, stops updating the location request to save the battery 
, and then shows the retrieved location value 
.
Now let’s look at how the same task is done on the Android platform.
7.3.2. Android example
The next listing displays an example of getting location on an Android[8] device.
Listing 7.2. Using the Location API on the Android
This code example has a main activity class that gets the location manager from the system . It creates an intent and starts requesting location updates from it . When the location value is retrieved, updateLocation 
is called. This function gets the last location value 
and displays it on the user interface 
.
Now let’s look at the same task for a generic Java ME platform.
7.3.3. Java ME example
Our next listing displays an example of getting location on a Java ME[9] device, such as a BlackBerry or some models of Samsung, Motorola, Nokia, or Sony Ericsson.
9 mng.bz/o246
Listing 7.3. Getting location in Java ME
This code sample shows how to set accuracy, here to 500 meters horizontally , get the LocationProvider from the system , get the location value and set a one-minute timeout , and use it .
7.3.4. Palm webOS example
On the webOS platform,[10] services enable access to low-level hardware capabilities such as GPS and accelerometer data and higher-level data services such as Palm Synergy, cloud services, and any other web service APIs.
The following listing displays an example of getting location on a webOS device, such as the Palm Pre.
Listing 7.4. Accessing the location service on webOS
This code example shows how to make a location request and how to set the callback functions to be called depending on whether the request succeeds or fails . Note that the onSuccess function may be called multiple times if the service is designed to return a series of results over time, such as GPS tracking
data.
7.4. Summary
Keep the following connectivity guidelines in mind when designing location-based services:
- Handle unavailability of services gracefully. The user’s location may not always be available, for any of several reasons.
- The device is cut off from any of the location methods it supports, for example, in a tunnel or on an airplane.
- The user withholds permission to release the information.
- No location provider that the device supports is available.
- Depending on the method used, determining the location may take a long time. The delay may be so long that the result isn’t useful in, for example, a navigation application. Keep the user informed.
- Location service fees, typical of network-assisted location methods, can add up quickly, so don’t overuse fee-based services.
- Minimize battery use. Turn off GPS when not necessary.
- Always optimize the accuracy of the location fix to the specific purpose of the fix. If low accuracy is acceptable, request low accuracy from the underlying service.
- Always keep the location data of the user safe.