Java Reference
In-Depth Information
The
WeatherWidget
uses a separate thread to obtain your position, although the code
for that thread is within the
WeatherWidget
class itself rather than a separate class. The
determineLocation
method creates and starts this thread in response to you choosing
“Use this location” from the list of locations or the location-entry screen. As this thread
finishes execution, it schedules a
Runnable
task on the main thread to add the new loca-
tion to the list of locations, and it sets the MIDlet to show the
locationTextBox
so you can
see the results of the location request.
Locating the User
The MIDlet uses a one-shot positioning request to determine your location; the location
thread does this work when you invoke
determineLocation
by spawning a new thread that
executes the
run
method in Listing 17-2. This code is an extension of the pseudocode you
saw in Listing 17-1; it has only a few important differences.
The application sets specific criteria for the location request, indicating that it's OK
for the location request to incur cost, that an
AddressInfo
should accompany the request,
and that it's OK to set a relatively high margin of error (100 meters). The
run
method
validates the resulting
Location
instance, using the resulting
AddressInfo
structure if it's
available to provide the
WeatherLocation
structure with a real city, state, and country, just
as if you'd entered this information directly. In most cases, however—and certainly in the
Sun Java Wireless Toolkit—all that you receive is a
QualifiedCoordinates
instance, and the
code just uses that instead, building up a
String
that consists of the tag
GPS Coordinates
followed by the latitude and longitude. This is admittedly a hack, but a reasonable one: it
uses the existing implementation of the other classes in the MIDlet and permits me to
focus on showing you the Location API, rather than how to refactor the other classes to
work with either coordinate data or its human-usable counterpart.
Once
run
builds up the
String
containing the location data, it uses a separate
Runnable
to update the UI on the main thread. This isn't strictly necessary, because the
locatingAlert
obstructs the
locationTextBox
's input anyway, so there's no possibility for conflict between
the two threads. However, it demonstrates to you how to schedule an action on the main UI
thread. The private inner class
LocationUpdater
actually performs the work necessary to
update the UI, which could have been an anonymous class, since it only occurs here. Its
constructor takes the new location, while its
run
method adds the new location to the loca-
tion list, sets the current location to the new location, and changes the display from the
locationAlert
to the
locationTextBox
, which shows the determined location.
Simulating Location API Data in the Sun Java Wireless Toolkit
The Sun Java Wireless Toolkit supports the Location API in simulation; you can specify
either a fixed location or a script of locations that the emulator will use over its lifetime.
Figure 17-1 shows the configuration screen (select MIDlet
➤
External Events from the
emulator's main menu, and choose the Location tab).
