Getting Coordinates - Smarter Ways

Let’s get our current coordinates in smarter ways. If you haven’t already gone through the previous part, I insist that you read it. It explains the basics of acquiring a location. Here we will build over what we learnt previously and get ourselves smarter.

Coordinate Alert using Thread

Run a new project using CoordinateAlertThread.java It uses a separate thread to access the location info. So the UI remains active with the main thread taking care of it. Now you can exit even when the program is busy fetching the location info. Since threading is a general concept in Java, I am not going to elaborate on that. But remember the following points –

• Threading is important in not only location-based but J2ME application development in general. Actions like getting information from a location provider, loading an image, fetching data from a server often require a significant amount of time. Such actions should be taken care of in a separate thread so that the user can still interact with the UI. Otherwise the user might misinterpret the program to have hanged.
• While doing time-consuming jobs always give a message to the user denoting what the program is doing. In this program “Tracking location ...” is printed to notify the user of the current action.

LocationListener

Why shout every time when the other guy is ready to shout and you just need to listen? Run another project using LocationListenerTest.java Note that now the device asks for location acquiring permission only once.

How Location Listener works?

• The LocationListenerTest implements the interface LocationListener. It has to override locationUpdated() and providerStateChanged() methods.
• Here you get the location provider instance as previously but instead of invoking the getLocation() method, you register the location listener with the location provider.
• The location provider calls the locationUpdated() method in regular intervals as specified while setting the listener.


• If the state of the location provider changes, providerStateChanged() is invoked.

Points to note about Location Listener

• Check the valid values that can be passed as the ‘interval’ ‘timeout’ and ‘maxAge’ arguments to
  setLocationListener(LocationListener listener, int interval, int timeout, int maxAge). ‘-1’ is passed to set default values specific to the provider. Take special care about these values, else it might not work properly. Setting default values is a safe option but should match your application requirement.
• The implementation tries to provide location info at the specified intervals but the interval might not be exact.
• If the provider becomes temporarily unavailable or out of service or if the interval specified is too short for the provider, the implementation might update with an invalid location.
• LocationUpdated() method should be short immediately passing control to a different function before it’s time for the next location update.
• Any synchronization should be taken care of by the application. Say, you should wait for the location info processing thread to complete before you go to the next step. Such synchronizing is to be ensured by the application. Thread.join() often comes handy in such situation.

Other issues

• Note that permissions (not limited to location acquiring permission but also related to file access, sending data to server etc.) for a particular application can be set manually on the device without opening the application. The procedure is device-dependent.
• Nokia 6165 model doesn’t support providerStateChanged() but 6175 will.

Now that we have found our position, let’s try to find out the landmarks. What good is the location info if we can’t get to our desired point of interest?

Created on 01/21/2007 12:39 AM by admin Updated on 02/16/2007 05:29 AM by admin