Henning Schulzrinne
Andrea Forte
The iPhone Lost application queries for location-based services at a users current location using the Location-to-Service (LoST) protocol. The results returned from the queries provide static and real-time information on each service located.
The LoST application requires an iPhone 3G running iPhone OS 2.0 or later.
Xcode IDE and a valid provisioning file is required in order to install the LoST application on an actual iPhone at this time. The application can also be ran on the iPhone simulator and only requires Xcode Developer Tools which includes the IDE and the iPhone simulator. To obtain a provisioning file, please contact Prof. Henning Schulzrinne for further information. Also consult the iPhone reference library for detailed instructions on installing and running applications on the iPhone device or simulator.
To start the application, tap the LoST icon from the home screen. The details for each view and the available actions are presented below.
After the application starts, the services view is the first view to be displayed and it lists the available services which can be selected to perform a LoST query. The toolbar at the bottom of this view includes a refresh button to reload the service list, an options button to display the options menu, and a location input button to display the view for entering a manual location. The location input button displays the location currently being used for LoST queries. The services view is shown in Figure 1.
Figure 1. Services View
The location input view allows users to manually input their own location to be used for LoST queries instead of using the iPhone's current location. The address entered does not have to be complete and a partial address containing only a zip code or a city name can also be entered as a valid location. If the address entered can not be found or is invalid, a message is displayed to the user telling them so. To go back to using the devices current location, the address fields simply need to be cleared when the done button is pressed. The location input view is shown in Figure 2.
Figure 2. Location Input View
All options in the iPhone Lost application can be set from the options view. The "directed search" option enables queries for services in the user's direction of travel and the "distance in" option displays all distances in the application in either miles or kilometers. To limit the number of results, the "search radius" slider can be used to set the maximum search radius when querying for services. The options view is shown in Figure 3.
Figure 3. Options View
When a response from the LoST server is received, the services located are displayed by the results view in a list ordered by their distance from the search location. These results can then be selected to reveal further information about each of the services returned. The results view is shown in Figure 4.
Figure 4. Results View
The result details view displays additional information of a selected service such as address, phone number, and real-time service information. The address displayed can be pressed to map the location using the iPhone Maps application and the phone number can be pressed to place a call to the service using the iPhone Phone application. The distance displayed in the result details view is the route-based distance between the search and service locations instead of the straight-line distance like the one displayed in the results view. The result details view is shown in Figure 5.
Figure 5. Result Details View
When a user performs a LoST query, the program immediately makes a request for the iPhone's current location using the CoreLocation API provided by the iPhone SDK. This API allows access to the device's GPS capabilities and provides positional data such as coordinates, heading, and speed. As soon as the data from the GPS is received, the program uses it to create a LoST request query for the service specified by the user. The LoST query is then sent to a LoST server for processing and the program waits until either a response has been received or a timeout has occurred. All LoST messages are in XML format and are sent via HTTP using the NSURLConnection class that is contained in the Foundation framework of the iPhone SDK.
Once the LoST response message is received back from the server, the program parses the message using the NSXMLParser class that is also a apart of the Foundation framework. If an error has occurred or there were no results found, an alert is displayed to the user to inform them of such events. Otherwise, a result object is created for each result returned and it contains all relevant data for a given result. The result objects are stored into an array that is then used to either display the results back to the user, or to display detailed information of selected results. The basic work flow of the program after a LoST query has been initiated is show in figure 6.
The remainder of this section details the internal operations of key areas within the program.
Figure 6. Basic work flow
When the program starts, the available service types that can be queried at given location are displayed to the user. The process to retrieve these service types is similar to the basic work flow mentioned previously, however a different request and response type is required. A listServicesByLocation request is sent to the LoST server and the response back contains a list of available service types. If an error occurs and service types can not be retrieved, a default service list that has been hard-coded into the program is returned.
When operating in a mobile environment, network connectivity becomes a major concern. To address this issue, the application caches query results to enhance its usability. After available services have been retrieved, a findService request is sent in the background for each service type displayed. These requests query for the nearest ten services at the users current location and are staggered five seconds apart from each other to prevent overloading at the server. The results returned from the queries are then stored into a cache.
If an interruption in network connectivity occurs while querying for a particular service, cached results are returned to the user assuming the interruption did not occur before results could be cached. To ensure the cache remains up to date, it is refreshed whenever the user has moved more than 100 meters from their previous location. This check occurs every two minutes or whenever the user initiates a query. Figure 7 shows the alert displayed to the user when network connectivity has been loss and cached results are to be displayed.
If a query for a particular service is successful, the results returned are used as the cache results for that service. This allows the results of any successful query to be viewed even when network connectivity has been lost. The results from previous queries can also be viewed at any time without having to send another request over the network. All results returned are cached until the available services list is manually refreshed, the user moves more than 100 meters from there previous location, or its has been over 24 hours since the users last query.
Figure 7. Cached results
The LoST client application utilizes the MapQuest XML API to support service queries at locations specified by the user. When an user inputs address information into the fields of the location input view and selects 'done', the information is sent to a MapQuest geocoding server in XML format via a HTTP request. If the server determines the address to be valid, it responds with the latitude and longitude coordinates of the desired location. Any future findService request made will then use these coordinates until the user clears all the input fields of the location input view. Further information on the MapQuest XML API can be found at developer.mapquest.com .
The LoST client application also uses the MapQuest XML API to perform the route-based distance calculations that are displayed at the result details view. To obtain the distance between a user's query location and the location of a selected result, the program sends a route request to a MapQuest routing server. This request contains the latitude and longitude coordinates of the source and destination and is sent via HTTP in XML format. If a valid route can be found between the two locations, the server responds back with turn-by-turn directions which include the distance to travel on each street along the route. The distance for each direction is then summed together and the final value is returned to the user.
The LoST protocol allows different types of shapes to be specified for service query bounds. Unlike the basic query, the directed search query uses an elliptical shape bound to query for services in the user's direction of travel. Figure 8 shows the difference between the two query types.
Figure 8. Directed and non-directed queries
When using an elliptical shape bound for a query, the request must specify the center coordinates, orientation, semi-major axis, and semi-minor axis of the elliptical. The semi-minor axis length is hard-coded to one meter and the semi-major axis length is set to the user's search radius. Location information provided by the GPS also includes the heading of a user's movement and is used to specify the elliptical's orientation. To ensure services behind the user will not be included in the results returned from the server, the elliptical's center is positioned in front of the user's current location in the direction of movement. The latitude and longitude of this center represents a point that is at a distance equal to half the search radius from the user's location and is calculated using the haversine formula.
The iPhone LoST application has operational limitations that will eventually need to be addressed in order to enhance its functionality. One such limitation is the absence of support for querying service sub-classifications. Currently, only top-level service classifications such as the financial and medical categories have been made available. Service sub-classifications will also need to be supported in the future to allow users to refine their queries and obtain more relevant results.
Other limitations include the lack of real-time service information as well as no ability to query for available service classifications at a user's current location. Both of these features have been implemented on the iPhone LoST client application, however the functionality required by the LoST server to support these features has not yet been implemented. Default information that has been hard-coded is currently being utilized in both cases until support for these features becomes available.
Finally, the number of results returned from a query has been limited to 100. This means all queries have their 'N' parameter fixed and was done so due to the constraints of running the LoST application on a mobile device with limited memory and network bandwidth.
An useful enhancement for the iPhone LoST application would be the use of embedded maps to display the users current location and the locations of the results returned. The embedded maps feature will be available for iPhone applications in the upcoming iPhone SDK 3.0 and would be a great alternative to the list view currently used to display results. Another useful enhancement would be the ability to save the application's state when it is interrupted by a phone call or when the user leaves the application. This would allow available services, search results, and preferences to all be reloaded quickly once the user returns.