Location services
Location services in IBM MobileFirst Platform Foundation provide you with the opportunity to create differentiated services that are based on a user location, by collecting geolocational and WiFi data, and by feeding the location data and triggers to business processes, decision management systems, and analytics systems.
Geolocation is a powerful differentiator of mobile apps. Yet because geolocation coordinates must be constantly polled to understand where a mobile device is located, the resulting stream of geographic information can be difficult to manage without exhausting resources such as battery and network. MPF includes location services that handle multiple geo modalities such as GPS, WiFi sampling, and interpolation. We can set policies for acquiring geolocation data and transmitting it to the server in order to optimize battery and network usage.
With location services in IBM MobileFirst Platform Foundation, we can use data that is acquired by a mobile device to trigger events that benefit both our owner of the device and the enterprise that has received the data. For example:
- A fast food outlet could start preparing food for a customer, based on data collected regarding his geographical location, so the food is ready just as the customer arrives to collect.
- A warehouse could improve the efficiency of its processes using locational data from its delivery vehicles to ensure that goods are removed from storage and made ready for collection.
- Shopping outlets could respond more readily to the needs of regular customers using geo-locational data.
Location services can also be used to improve internal efficiency within an organization, for example, by understanding behavior and trends in application usage, and thus driving ongoing improvement.
Location services are currently supported on hybrid Android, iOS, and Windows Phone 8.
The following figure shows how the location services feature works:
Figure 1. Location services architecture
Application code on the mobile device, in the form of an acquisition policy, controls the collection of data from device sensors. The collected data is referred to as the device context. When a change occurs in the device context, such as a change in the geolocation of the device, or the fact that it has just entered a WiFi zone, triggers can be activated. The triggers specify that an action should occur: either a callback function is called, or an event is sent to the server, based on the device context.
Events are created by triggers and application code, and include a snapshot of the device context at the time of their creation. Events are buffered on the client, and are transmitted to the server periodically. The server might process the event much later. During the event transmission process, the device context is synchronized transparently to the server.
To handle the events, the server uses adapter application code. This code sets up event handlers on the server, which filter event data and pass matching events to a callback function. The code also accesses the client's device context (its location and WiFi network information) and sets an application context. Server activities and received events are logged, together with the device and application contexts, for future reporting and analytics.
- Platform support for location services
Location services are supported for hybrid applications on iOS, Android, and Windows Phone 8. However, the level of support for each platform is slightly different. - Location services permissions
To use MobileFirst location services, we must define the correct permissions. - Triggers
A trigger is a mechanism that detects an occurrence, and can cause additional processing in response. Triggers are activated when a change occurs in the device context. - Set an acquisition policy
We can set up a location services acquisition policy based on the requirements. For example, the policy could be set up to maximize positional accuracy, but with the capability of reducing accuracy if the device is known to be low on charge, to conserve battery usage. - Work with geofences and triggers
We can use geofences and triggers to identify users who enter, exit, or stay inside or outside a geographical area. We can initiate actions, such as improving responsiveness for privileged guests at a hotel chain, based on geofence-related data. - Differentiating between indoor areas
We can use visible access points to identify areas in an indoor location such as a shopping mall. After transmitting this data to a server, together with the device context, we can use it for auditing, reporting, and analysis. - Secure server resources based on location
Device context data can tell you whether a user's device is connected to a secure network. If it is not connected, the device context can tell you whether the device is within a required geofence. This data can be used to restrict access to sensitive information or to prevent running specific program logic. It can also be used to require that additional authentication mechanisms, such as one-time pads, be used. - Tracking the current location of devices
We can track the location of devices by ensuring that ongoing acquisition of geo-locational data is taking place. When the position of the device changes, a trigger is activated. - Keeping the application running in the background
When we are tracking a device by acquiring geolocation data, it is important to keep an application running in the background so that data can continue to be acquired.
Parent topic: Develop MobileFirst applications
Related concepts: