Welcome to the final part of this review of the Pluralsight course Android Location-Based Apps by Jim Wilson

Jim has over 30 years of software engineering experience, with the past 15 years heavily focused on creating mobile device and location-based solutions. He has co-founded multiple software-related startups and has served in a consulting role at several more.

After nearly a decade as a Microsoft Device Application Development MVP, Jim now focuses on developing Android and iOS device applications. Jim’s passion is mentoring software developers. He blogs at hedgehogjim.wordpress.com.

Also in this series:

Part 1 – Android Location-Based Apps

Part 2 – Android Location Providers

Part 3 – Android Location Management and Threading

Part 4 – Controlling Android Location Frequency

Human Readable Location Information

Location information – people vs computers

Computers rely on latitude and longitude, whereas people prefer location names.

Rather than divide these into two distinctly separate representations, Android provides an Address class.

This class describes everything there is to know about the location, and we can retrieve the individual components of the location using a series of get methods, including:

• getThoroughfare (for the street name)
• getLocality (usually town or city)
• getAdminArea (usually state, province or county)

The Address class also has methods for displaying the address in the most human readable way, and provides latitude and longitude coordinates.

Geocoder class

The Geocoder class populates instances of the Address class.

Geocoding is taking a human readable address and fetching the latitude and longitude coordinates from that.

Reverse Geocoding is taking the coordinates and giving back a human readable address.

With the Geocoder class, no matter which one we start with, we always get back a full address containing both the coordinates and the human readable description.

We need to be aware that it may replace our human readable input data with the data that Google has in it’s database. So this data could either be cleaned up or expanded.

The two methods responsible for this are:

• getFromLocation
• getFromLocationName

Jim says working with location is not an exact science: we are tying our data back to the real world and there might not be an exact match for our inputted data.

The final parameter of both of the above methods is the maximum number of results that we would like to receive. We could get back a null list, a zero list, or we may get one or two results back when we ask for five locations.

The first result returned tends to be the closest match.

How Geocoder class works

The Geocoder class relies on some of Google’s custom libraries, and it’s not guaranteed that every Android device you run your program on will have a Geocoder class implemented!

There is the fully Google version of Android, and there’s also the open source version of it. The Google libraries sit on top of Android.

The good news it as long as the device uses Google Android there is a very high chance that it will work.

The other things to know is it relies on web services provided by Google.

So we need to program defensively when working with Geocoder, and be prepared for all the ways Geocoder indicates failure:

• Call Geocoder.isPresent
• Handle IOException
• Handler null or empty return value

Using Geocoder in a UI friendly manner

Jim says it is very important that we never call getFromLocation or getFromLocationName on the UI thread.

Both of these methods rely on blocking network calls – they can be long delayed calls.

Jim finds the AsyncTask offers one of the easiest solutions.

This class is designed for offloading specific bits of work from the User Interface.

You can gain an even more detailed understanding of AsyncTask in his course Android Async Programming and Services

Jim course concludes with a demonstration of using the Geocoder in a UI friendly manner.