Blogs

About this blog

The computing industry is undergoing major evolution positioning mobile devices as the primary personal computing device. This blog will identify concepts and observations related to that evolution - missives on the journey to a mobile computing world.

Links

Tags

Developing location-aware apps in IBM Worklight, Part 1: The basics

This blog post is contributed by Hisham Abdel-Hafez, an Expert IT Specialist in IBM Egypt and IBM Redbooks thought leader.

A common requirement for modern mobile applications is to be able to know a device’s current geographic location and act according to this knowledge. We can summarize the basic needs for a location-aware mobile application in the following list:

Getting the current geographic location of a mobile device in the form of latitude and longitude values

Geocoding, which transforms a human-readable address to longitude and latitude values, and reverse geocoding, which completes the reverse transformation

More mature location-aware applications will have more advanced needs like:

Continuous device location tracking

Customizable geolocation acquisition policies

Location change triggers

IBM Worklight has an interesting support system for both the basic and advanced needs of location-aware applications. In this blog post, I will examine how you can develop a Worklight application that addresses the basic needs. In part 2, I will talk about the more advanced topics.

Getting the current geographic location of a mobile device

Modern devices have the ability to get their current coordinates in a few different ways:

GPS—the most accurate way to get current coordinates, but is slow, needs a clear sky view and consumes more of the device’s battery

Mobile networks and WiFi—less accurate than GPS but much faster and have no special requirements other than connectivity

Getting current coordinates comes as part of HTML5 application programming interfaces (APIs) using the method geolocation.getCurrentPosition. If a device does not support this API, the Apache Cordova library bundled with IBM Worklight implements it for you. The code snippet below shows how it can be used:

Since getting the current location is done with an asynchronous call, it is always safest to set a timeout for it. You can do this by adding a timeout value to the options object.

To get all of this working on Android, you have to make some changes in the AndroidMainfest.xml file. Add the following permissions to the file in order for the Android operating system to give you access to the needed device resources.

Geocoding is the transformation from human-readable addresses into longitude and latitude values. Reverse geocoding is the opposite of this transformation. To do geocoding and reverse geocoding, you will need to use an external location API. Many vendors offer such services now. We will use Google Maps APIs in this post.

To add Google Maps support to your IBM Worklight application, add this line to your main application HTML file:

Both geocoding and reverse geocoding requests use the same object google.maps.Geocoder and the same function geocode. How the app will operate depends on what you pass in the request. If you pass the coordinates, then it will perform a reverse geocoding operation, and the response will be a human-readable address. If you pass an address string, then it will do a geocoding, and the response will be the coordinates along with a better-formatted address. So, first create the Geocoder object.

var geocoder = new google.maps.Geocoder();

Then, depending on what operation you are doing, construct the request object.

The results format is the same for geocoding and reverse geocoding operations, so parse it for the output data you need.

Conclusion

IBM Worklight leverages open web standards that make building location-aware mobile applications easier than ever. This gives application owners a huge opportunity to reach out to users in very unique and unexpected ways.

How has your experience been with location-aware apps? Leave a comment below or reach out to me on Twitter. And please stay tuned for part 2, where I’ll cover the more advanced needs of mature location-aware applications.