Simulating your location within the emulator

For any location-aware application you will start by working with the provided SDK and the emulator. The first thing you will want to do within the emulator is set and update your current location. From there you will want to progress to supplying a range of locations and times to simulate movement over a geographic area.

There are several ways you can accomplish these tasks for the emulator, either by using the DDMS tool or by using the command line within the shell. The fastest way to get started is to send in direct coordinates through the DDMS tool.

11.1.1 Sending in your coordinates with the DDMS tool

The DDMS tool is available in two contexts, either launched on its own from the SDK tools subdirectory or as the Emulator Control view within the Eclipse IDE. (You need to have Eclipse and the Android Eclipse plug-in to use DDMS within Eclipse; see chapter 2 and appendix A for more details about getting the SDK and plug-in set up.)

The simplest way to set your location with the DDMS tool is to send direct latitude and longitude coordinates manually from the Emulator Control > Location Controls form. This is depicted, using the straightforward manual approach, in figure 11.2. (Note that Longitude is the top/first field, which is the standard around the world, but backwards in terms of how latitude and longitude are generally expressed in the United States.)

If you launch the built-in Maps application (which is included with Android on the main menu) and send in a location with the DDMS tool, you should then be able to use the menu to select My Location, and the map will animate to the location you have specified—anywhere on earth.

Try this a few times to make sure you get the hang of it; for example, send the decimal coordinates in table 11.1 one by one, and in between browse around with the built-in map. When you supply coordinates to the emulator, you will need to use the decimal form.

Although the DDMS tool requires the decimal format, latitude and longitude are more commonly expressed on maps and other tools as degrees, minutes, and seconds. Degrees are used because these coordinates represent points on the surface of the globe as measured from either the equator (for latitude) or the prime meridian (for longitude). Each degree is further subdivided into 60 smaller sections, called minutes, and each minute also has 60 seconds (and it goes on from there if need be, tenths of a second, and so on).

Figure 11.2 Using the DDMS tool to send direct latitude and longitude coordinates to the emulator as a mock location
Table 11.1 Example coordinates for the emulator to set using the DDMS tool

Description

Latitude degrees

Longitude degrees

Latitude decimal

Longitude decimal

Golden Gate Bridge, California

37°49' N

122°29' W

37.49

-122.29

Mount Everest, Nepal

27°59' N

86°56' E

27.59

86.56

Ayer's Rock, Australia

25°23' S

131°05' E

-25.23

131.05

North Pole

90°00' N

-

90.00

-

South Pole

90°00' S

-

-90.00

-

When representing latitude and longitude on a computer, the degrees are usually converted into decimal form with positive representing north and east and negative representing south and west, as shown in figure 11.3.

It's not personal, but if you live in the southern and eastern hemispheres, say in Buenos Aires, Argentina, which is 34°60' S, 58°40' W in the degree form, the decimal form is negative for both latitude and longitude, -34.60, -58.40. If you haven't used latitude and longitude much, the different forms can be confusing at first, but they quickly become second nature after you work with them a bit.

Once you have mastered setting a fixed position, the next thing you will want to be able to do is supply a set of coordinates that the emulator will use to simulate a range of movement.

Using the command line to send coordinates

You can also send direct coordinates from within the emulator console. If you telnet localhost 5554, you will connect to the default emulator's console (adjust the port where necessary). From there you can use the geo fix command to send longitude, latitude, and optional altitude, for example, geo fix -21.55 64.1. Again keep in mind that the Android tools require that longitude be the first parameter

11.1.2 The GPS Exchange Format

The DDMS tool supports two formats for supplying a range of location data in file form to the emulator. The GPS Exchange Format (GPX) is the first of these and is the more expressive form in terms of working with Android.

Figure 11.3 Latitude and longitude spherical diagram, showing positive north and east and negative south and west

GPX is an XML schema (http://www.topografix.com/GPX/171/) that allows you to store waypoints, tracks, and routes. Many handheld GPS devices support and/or utilize this format. Listing 11.1 is a portion of an example GPX file that shows the basics of the format.

Listing 11.1 A sample GPX file

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

<gpx xmlns= "http : //www. topograf ix. com/GPX/1 /1" O Define root version= "1.1" <-1 gpx element creator="Charlie Collins - Hand Rolled"

xmlns:xsi="http://www.w3.org/2 0 01/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1

http://www.topografix.com/GPX/1A/gpx.xsd"> A Include metadata

<metadata>

<name>Sample Coastal California Waypoints</name>

<desc>Test waypoints for use with Android</desc> <time>2 0 08-11-2 5T06:52:56Z</time> <bounds minlat="25.00" maxlat="75.00" minlon="100.00" maxlon="-150.00" /> </metadata>

<wpt lat= "41.85" lon= "-124.38"> < | Supply waypoint <ele>0</ele> © elements

<name>Station 46027</name> <desc>Off the coast of Lake Earl</desc> </wpt>

<wpt lat="41.74" lon="-124.18"> <ele>0</ele>

<name>Station CECC1</name> <desc>Crescent City</desc> </wpt>

<wpt lat= "38.95" lon="-123.74"> <ele>0</ele>

<name>Station PTAC1</name> <desc>Point Arena Lighthouse</desc> </wpt>

stanza remainder of wpts omitted for brevity

Supply track element

<name>Example Track</name>

<desc>A fine track with trkpt' s . </desc> © Use a track <trkseg> <-1 segment

<trkpt lat="41.85" lon="-124.38"> <-1 Provide specific

<time>2 008-10-15T06:00:0 0Z</time> </trkpt>

<trkpt lat="41.74" lon="-124.18"> <ele>0</ele>

<time>2 008-10-15T06:01:0 0Z</time> </trkpt>

<trkpt lat="38.95" lon="-123.74"> <ele>0</ele>

<time>2 008-10-15T06:02:0 0Z</time> </trkpt>

. . . remainder of trkpts omitted for brevity

As part of the root gpx element, a GPX file requires the correct XML namespace O and then moves on to metadata Q and individual waypoints © (waypoints are named locations and are defined using latitude and longitude). Along with individual way-points, a GPX file also supports related route information in the form of tracks ©, which can be subdivided further into track segments Q. Each track segment is made up of track points (which are basically related and ordered waypoints with an additional point-in-time property) ©.

When working with a GPX file in the DDMS tool you can use two different modes, as the screen shot in figure 11.4 reveals. In the top half of the GPX box individual way-points are listed; as each is clicked, that individual location is sent to the emulator. In the bottom half of the GPX box all the tracks are displayed. Tracks can be "played" forward and backward to simulate movement. As each track point is reached in the file, based on the time it defines (the times matter with GPX, the file can be run at various speeds using the Speed button), those coordinates are sent to the emulator.

GPX is very simple and extremely useful when working with mock location information for your Android applications, but it's not the only file format supported. The DDMS tool also supports a format called KML.

□sorption

SooLh c1 Moraj 11 j at Oio ilote f^i i OW <t* Wilt if Biitari äoMKLIunnil t ru Point Tim? Comment it Nn.1 15 05:00:00 EST 2009

Log

Time

pid

t»g ^

i MKU9«

11-25 23:11:17 0

175

windwav«

LOfAti&nHelp« 9«QMPoi(W - geoRKPoint - 43.145 -124.329

11-25 23:11:17 0

175

Wjndvva/es

locationHclpct geiGcoPom* ■ geoRssPwnt - 40.294 -124.7«

1125 23:11:17 0

175

WintfVVave*

MapViewAtUvily IwndlcMcssage invoked update ovcilays wllh ik

•ft ddld

11-25 23:11:17 0

175

winftv&ves

M4(Wl«wAC(iivlT/ buoys (Ll«ceuf>y0ver1»yl»rri>) st» ■ 10

11-25 23.13:19 □

'lb

dnlvilcvm

ec frwd 133M objects r ¡jjb-ico byt« in l isms

Figure 11.4 Using the DDMS tool with a GPX file to send mock location information

□sorption

SooLh c1 Moraj 11 j at Oio ilote f^i i OW <t* Wilt if Biitari äoMKLIunnil t ru Point Tim? Comment it Nn.1 15 05:00:00 EST 2009

11.1.3 The Google Earth Keyhole Markup Language

The second format that the Android DDMS tool supports for sending a range of mock location information to the emulator is the Keyhole Markup Language (KML). KML was originally a proprietary format (created by Keyhole, which was acquired by Google), but it has since been submitted to the Open Geospatial Consortium (OGC) and accepted as an international standard. The mantra of the OGC KML is stated as:

That there be one international standard language for expressing geographic annotation and visualization on existing or future web-based online and mobile maps (2d) and earth browsers (3d).

A sample KML file for sending location data to the Android Emulator is shown in listing 11.2. This file uses the same coastal location data as we saw with the previous GPX example.

Listing 11.2 A sample KML file

<?xml version= "1.0" encoding= "UTF-8"?> O Define root <kml xmlns= "http://earth.google.com/kml/2.2"> <1-I kml element

<Placemark> <-1 Capture

<name>Station 46027</name> | information

<description>Off the coast of Lake Earl</description> with Placemark

<coordinates>-124 . 38 , 41. 85, 0</coordinates> <—, D Use a Point </Point>

</Placemark> Supply coordinates |

for Point O

<Placemark>

<name>Station 46020</name>

<description>Outside the Golden Gate</description> <Point>

<coordinates>-122.83,37.75,0</coordinates> </Point> </Placemark>

<Placemark>

<name>Station 46222</name>

<description>San Pedro Channel</description> <Point>

<coordinates>-118.31,33.61,0</coordinates> </Point> </Placemark>

KML uses a kml root element and, like any self-respecting XML format, requires the correct namespace declaration O. KML supports many more elements and attributes than the DDMS tool is concerned with parsing. Basically, in DDMS terms, all your KML files need to have are Placemark elements ©, which contain Point child elements D, which in turn supply coordinates O.

Figure 11.5 Using the DDMS tool with a KML file to send mock location information

Figure 11.5 shows an example of using a KML file with the DDMS tool.

KML is very flexible and expressive, but it has drawbacks when working with it in an Android Emulator context. As we have noted, the DDMS parser basically looks for the coordinate elements in the file and sends the latitude, longitude, and elevation for each in a sequence, one per second (the documentation says one Placemark per second). Timing and other advanced features of KML are not yet supported by DDMS. Because of this we find it more valuable at present to use GPX as a debugging and testing format (where detailed timing is supported).

KML is still important, though; remember it's the international standard, so it is sure to gain traction. Also, KML is an important format for other Google applications, so you may encounter it more frequently in other contexts than GPX.

Now that we have shown how to send mock location information to the emulator, in various formats, the next thing we need to do is step out of the built-in Maps application and start creating our own programs that rely on location.

0 0

Post a comment