Java Reference
In-Depth Information
increasing alphabetic order. In my anonymous inner
RecordComparator
class, it's a little
goofy that
String.compareTo
's results—negative if the receiver precedes the argument,
positive if the receiver succeeds the argument, and zero if they're lexically equivalent—
need to be converted to
RecordComparator
values, but that's the way it works. Once you
obtain the enumerator, you can simply walk the enumerator and insert each record's
location in the appropriate field of the result array. Because this method simulates hav-
ing the entire list of locations in memory, you can wrap the entire sequence of events in
an exception handler.
The
getLocation
method, on the other hand, returns a
Location
instance when
provided with the name of a location. It, too, uses a
RecordEnumeration
and looks up the
Location
using the
RecordEnumeration
's
matches
method. It then uses the resulting enu-
meration to create a
Location
instance.
■
Tip
The inner classes for both
locationStrings
and
getLocation
use the same record-parsing
code contained within the
Location
class. This is sufficient in this example, where you may have 10
or 20 locations, and likely no more, but it may not be efficient enough to process truly large collections
of records, especially on slower handsets. If you're developing an application that must manage a lot
of records, consider breaking out field deserialization in such a way as to permit your use of
RecordEnumeration
to only deserialize what it needs to get the job done. Doing so will make your
application perform better.
The
addLocation
and
updateLocation
methods are similar, because they must both
deal with existing records (you don't want to clutter the record store with duplicate loca-
tions of the same place). These methods rely on a
Location
object's
toBytes
method. The
addLocation
method begins by determining if a record for the existing
Location
already
exists, and if it does, it uses the
updateLocation
method instead to update that record's
contents. Otherwise, it simply gets the bytes corresponding to a serialized version of the
indicated
location
instance and adds the record to the database, closing the record store
when it finishes.
The
updateLocation
method is a little more complex. It must handle three different
cases:
• The
Location
already exists in the database and has an ID (the location was created
using the
LocationStore
's
getLocation
method).
• The
Location
already exists in the store but doesn't have an ID (the location was
created programmatically but is a duplicate of one in the store).
• The
Location
does not exist in the store and must be added.
