Funny Tracker:

A Functional Tracking System On Your Mobile

Phone
Johannes Martin, Daniel Trivellato, Timoty Weis
Mobile Services - June 2007

1 Introduction
A tracking system is a useful instrument for recording and revisiting some mo-
ments of our trips. The basic functionality of a tracking system is to record the
positions visited by the user in a given amount of time.
The Funny Tracker is a tracking system implemented as a mobile application
(MIDlet). It registers the user paths providing at the same time the possibility
to add information of places of particular interest, storing all the data as a file
on the device file system. The stored files can be afterwards sent to a server
station at any moment.

2 System Functions
The Funny Tracker is a tracking system enabling the user to register the po-
sitions visited during a walk, mark places of particular relevance encountered
along the way, and add to them some additional information. The main func-
tionalities of the Funny Tracker are the following: (i) record the user positions,
(ii) add descriptions of locations, (iii) store the path locally, and (iv) send the
path to a server.
Each functionality is examined in details in the following subsections.

2.1 Path Tracking

Tracking (recording) the user path constitutes the main functionality of a track-
ing system. The tracking is obtained by constantly registering the user position
at a given time interval, through a GPS (Global Positioning System) or alter-
natively, as in our case, through an external event generator.
The interface between the MIDlet and the GPS is provided by the location
API. The GPS invokes the locationUpdated method specifying the new position
of the user. It is up to the application then to decide what to do with the
coordinates received.
The Funny Tracker displays to the user a map of his location, and implements
the locationUpdated method by updating the user position on the map when the
new coordinates are received. The sequence of coordinates are stored internally

1
by the application, and the user may then save the collection or delete all the
tracked information, if they are not of much interest for him.
The external event generator simulates the behaviour of a GPS. It requires
the user to load a script, i.e. a simple xml file containing a sequence of previ-
ously stored coordinates. Then the generator reads at predefined time intervals
the lines of the script (consisting of the simulated GPS coordinates), calling ev-
ery time the MIDlet’s locationUpdated method specifying the coordinates read.
Each line of the XML contains a waypoint tag, including the latitude, longitude,
and altitude of the new coordinates, as well as the time interval.

2.2 Landmarks
As mentioned before, the Funny Tracker allows the user to add additional in-
formation to the path that he is recording. These additional information are
called landmarks. The landmarks are special points of interest highlighting pre-
cise places in the path of particular relevance for the user. Moreover, there is
also the possibility to add some textual description (even in html format) to the
landmark, in order to have exhaustive information of the visited locations that
the user wants to remember.
During the execution of the application, the phone displays the user’s current
position on the map. At any moment, the user can decide to add a landmark,
which combines the actual coordinates and possibly a textual description of the
location.

2.3 Path Storage

Once the user decides to stop the tracking of his walk, he has the possibility
to save the data collected, or to discard them entirely. The saved paths are
stored on the file system of the mobile device as kml files. Kml is the standard
file format adopted by Google, to save information that can be visualized using
their software Google Earth1 . A kml file combines the xml syntax with specific
tag elements including style settings, coordinates sequences, and landmarks def-
initions.
Saving the file on the device file system makes the file available also outside
the application. In this way, the user can perform additional actions on the file,
such as deleting it, renaming it or sending the file to a computer via bluetooth.
Up to now it is not possible to visualize the information stored in a kml file
directly on the phone via a Google Earth or similar application for mobile de-
vices. For this reason, we give the user the possibility to send the file to a server
station (see section 2.4).
Google recently deployed a mobile version of Google Maps, namely Google
Maps Mobile2 . It is a MIDlet working in the same way as the standard web
application, providing the possibility of visualizing a path directly on the phone,
after uploading the kml file on a web server. This means that Google MAps
Mobible does not allow to read a file directly from the phone. However, saving
the file on the mobile device remains an important functionality, in forecast of a
Google Earth Mobile MIDlet, or a kml read option on the actual Google Maps
Mobile application.
1 http://earth.google.com/kml/
2 www.google.it/gmm

2
2.4 Server Side Functions
From the Funny Tracker MIDlet, a user can send the saved path to a server.
On the server side, a servlet implements additional functionalities which enrich
the utility of the application. More precisely, once the user sends the path to
the server, the servlet (i) creates a local kml file, (ii) uploads the file to an ftp
site, and (iii) sends an e-mail to a user defined address.
The goal of saving a kml file on the server is to enable a user with server
access rights to later revisit the path using Google Earth3 . Google Earth is a
program which maps a set of coordinates to actual locations on the earth. The
sequence of coordinates in the kml file is represented as a line in the program,
and the landmarks in the file are represented as symbols on the line. Clicking
on the landmarks cause the landmark description to appear.
The kml file created is then uploaded via an FTP connection to a private
server that is constantly connected to the Internet. This step is essential to
visualize the path from any web browser using Google Maps4 . In fact, it is
possible to show a path on Google Maps only if it is stored on a server accessible
from the web. To see the uploaded path from a browser, it is necessary to enter
in the browser the Google Maps url, followed by specific parameters, i.e. the
private site url ending with the kml file name. For example, in our case a possible
valid url could be: http : //maps.google.com/maps?f = q&hl = en&q = http :
//www.noisyroyaldirt.it/M S/path1.kml.
The final action performed by the servlet when receiving a file from the
MIDlet is to send an email to a user previously defined address (set in the
Funny Tracker MIDlet settings form). The email message will contain the kml
file as attachment (for viewing the path with Google Earth on a private PC),
and a link to the url from which the path is visible with Google Maps. The
reason for sending the email is to allow the user to share the path with some
friends, colleagues, or simply to make the data available outside the central
server.

3 Interaction with the Funny Tracker

In this section we will present how a sample interaction with the Funny Tracker
MIDlet might proceed. The sequence of steps is accomplished with the screen-
shots of the application, in order to always have a reference to the real output
of the actions performed.
When the application is launched (cf. Figure 1(a)), the user is displayed
the initial application form (Figure 1(b)). The form contains some textual pre-
sentation of the application, an image of the world and the main menu of the
MIDlet. The menu of the initial form has four entries: an Exit command
on the left menu, to quit the application, and three commands on the right
pop-up menu. These three commands are: Start, to start the tracking activ-
ity, ShowP reviousP aths, to load and manage the previously saved files, and
Settings, to set some application settings.
Let’s assume we want to start tracking the path of a walk. By selecting the
Start command, the map of our location is loaded. We also need to open the
3 http://earth.google.com/
4 http://maps.google.com/

3
 (a) MIDlet Start Screen (b) Initial Form of the
Funny Tracker

Figure 1: The Application Start Screen and the Initial Application Form

external event generator and load the script containing a sequence coordinates,
in order to simulate the communication of the MIDlet with a GPS (cf. Figure
2(a)). The first time we select the Start command, all elements necessary to
the tracking activity are generated. From that moment on, the tracking activity
does not stop until the application is quit. This implementation choice has two
fundamental reasons: (i) to avoid the loss of data in the case we erroneously
press the back button (cf. Figure 2(b), i.e. we go back to the initial form), and
(ii) to allow the user to navigate through the main menu elements while still
recording his positions.
The menu commands of the map form are all grouped in the right pop-
up menu and are four (cf. Figure 2(b)): BackT oStart, to go back to the
initial form, ResetT rackedInf o, to reset all the information recorded up to
now, SaveP ath, to save the recorded information on a kml file in the device file
system, and SetLandmark, to add a landmark to the current location in which
we are positioned.
Assume we want to set a landmark specifying that we are entering the main
street. By selecting the SetLandmark command, the landmark form is dis-
played. We can enter our comment in the description box and then press the
SaveLandmark command (cf. Figure 3(a)). Once we finish our walk, we can
select the SaveP ath command in the map menu if we want to store the path.
In the case there is some error in saving the file, or we try to save an empty
file (i.e. we press save before any information is registered) an error message
is displayed, otherwise the user is prompted with a confirmation message (cf.
Figure 3(b)). We can now go back to the main menu to send the saved path to
the server.
Before sending the path to the server, it is better to check that the email
address to which the servlet will send the email is correct. To check this, we

4
 (a) Location Map and External Event Generator (b) Map Form and Form
Menu

Figure 2: Application Display when Tracking the Path

(a) Landmark Insertion (b) Path Saved Message

Form

Figure 3: Landmark Insertion Form and Response of the Save Path Command

5
enter the settings form, by selecting the Settings command from the main menu.
If the address is correct, we simply go back to the initial form, otherwise we can
modify it and press the SaveSettings command (cf. Figure 4(a)). After that,
we can enter in the previous paths form (ShowP reviousP aths command in the
main menu) to send the path to the server. The form contains a list of all the
paths stored in the device file system. Files written in upper case are those which
have already been sent once to the server. The last saved path is the selected
element of the list (cf. Figure 4(b)). By selecting the SendP athtoServer we try
to send the file to the server, at the url specified in the MIDlet properties (not
modifiable by the user). If the operation succeeds, we will get a confirmation
message, otherwise and error message will be displayed.

(a) Settings Form (b) Previous Paths List

Figure 4: Settings Modification Form and Previous Paths List

If the path is correctly sent to the server, the specified email address will
receive an email with the kml file of the path, and an url with which to see the
tracked path from any web browser. In Figure 5, we show what is displayed to
the user by entering the url into a web browser (Google Maps), and in figure 6
we show the map obtained by opening the kml file with Google Earth.

4 System Implementation
In the Funny Tracker we can identify two separate implementation areas: a
client side and a server side area. Both sides are made up of several Java
classes which collaborate for performing the application functions. In the client
side implementation there are four Java classes: F unnyT racker.java (MIDlet),
F unnyM ap.java, F unnyEventsM ap.java, and ServletConnection.java. On
the server side, the Java classes are three: T racker.java (the servlet class),
SimpleF T P.java, and EmailM essage.java. In the next subsections we will
present each application class singularly, and illustrate the most important

6
Figure 5: The Tracked Path Displayed with Google Maps

Figure 6: The Tracked Path Displayed with Google Earth

7
methods of each class. All the methods presented include error handling proce-
dures.

4.1 FunnyTracker.java
The F unnyT racker class is the MIDlet class managing the execution of the ap-
plication. Except for the MIDlet standard methods (startApp, pauseApp, and
destroyApp) and the class constructor (where the main commands, the main
displayable elements and the location provider are instantiated), we can identify
different super-categories for the methods of the class: (i) commands handling,
(ii) initialization/display, (iii) server communication, and (iv) file system com-
munication.
The command handling category is constituted of two methods: the im-
plemented commandAction method of the CommandListener interface, and
method raiseEvent. The second simply handles the event generated by some
key pressure on the map form, by invoking commandAction for the appropriate
command. For example, by pressing the back button or key number 1 in the
map form we go back to the initial screen, or by pressing 4 the landmark form is
displayed. Method commandAction handles the actions in response to the se-
lection of any application command. For example, command Start in the main
menu causes the location map to be load, or SaveP ath in the map form causes
some methods of the file system communication category to be invoked. For an
overview of the actions in response to all application commands, see section 3.
Methods in the initialization/display category simply deal with the initial-
ization of application’s forms and related commands, and the display of dis-
playable elements on the device screen. Form initialization methods create
instances of displayables in the case they are not yet existent. Among these
methods we have initializeM ap, which also instantiates classes F unnyM ap and
F unnyEventsM ap, and initializeLandmarkF orm() (the settings and previous
paths form are initialized in the constructor). Display methods are used in the
other methods to display wait messages with an appropriate textual explanation
(e.g. ”Loading map...”’), or action result notification (e.g. ”Data have been sent
to the servlet!”).
In the F unnyT racker class a single method manages the communication
with the server. The sendP athT oServer method creates an instance of the
ServletConnection class, if not existent, loads the requested file from the file
system, and uses a the methods of the ServletConnection class to send the file
to the server. The server url is specified in the application properties (JAD file).
Lastly, in the file system communication category we include all the methods
reading from and writing to the device file system. Among these methods, the
most important are createF ile and loadF iles. The first creates a kml file on
the device when a path is saved by the user. The file name is given in such a
way not to overwrite existent files. The second load all previously saved ”.kml”
files from the file system, to be displayed in the previous paths form. loadF iles
automatically selects the last saved file of the list (only if the path is saved in
the last usage of the Funny Tracker).
All methods requiring network communication (e.g. sendP athT oServer), or
which can be particularly time consuming (e.g. initializeM ap) are implemented
on a different thread.

8
4.2 FunnyMap.java
Class F unnyM ap handles the interaction of the MIDlet with the GPS (or in
our case with the event generator). It implements all the methods necessary for
the communication with the generator, a bunch of utility methods, and stores
the temporary tracked coordinates, the landmarks, and the map image. To
implement some of the class’ methods we referenced to the CityGuide MIDlet,
which is included in the sample MIDlets of the Wireless Toolkit.
In order to communicate with a location provider, the class implements the
LocationListener interface. The methods interacting with the external event
generator are locationU pdated and providerStateChanged. The first method is
called when the user location is changed. It gets as parameter the coordinates of
the new position, which are used to update the position of the user on the map
on the phone display. The second method is used by the location provider to
inform the MIDlet that its state is changed (e.g. that the provider is temporarily
not available).
The methods responsible for managing the newly received coordinates and
adapting them to the map image are setV isitorCoordinates and convertCoor−
dinatesT oXY . setV isitorCoordinates checks whether the new position is dif-
ferent from the current, and if it is the case, asks convertCoordinatesT oXY
to convert the absolute coordinates received from the location provider to co-
ordinates relative to the stored map image. Once the adapted coordinates are
available, we can redraw the user position on the map (section 4.3).
Among the utility methods, the most important is getV isitedCoordinates −
KM LT ext. The method returns the content of the kml file for the recorded
path as a string, including the sequence of coordinates and the landmarks. This
content will be saved in a file by the F unnyT racker class. Other important
methods are addLandmark, which adds a landmark and related description to
the current location, and clearSavedData, which resets the tracked information
when the relative command is raised, or after a path is saved in a file.

4.3 FunnyEventsMap.java
In the F unnyEventsM ap class all the drawing activities over the map image
are performed. The map displayed during the tracking activity is obtained by
the elaboration of the initial map image by the F unnyEventsM ap.
This class extends the Canvas class, and implements the paint method.
In the paint method, an image representing the user is drawn on top of the
map image, in a position reflecting the current user coordinates. paint is called
by the F unnyM ap class every time the user position is updated. Another
method, calculateV iewportOf f set, tries to center the user position with respect
to the phone display. These two methods are taken from the CityGuide MIDlet,
included in the sample MIDlets of the Wireless Toolkit.
As additional utility, we added to the class the overridden method keyP ressed.
In particular, we link the menu entries available while tracking to some phone
keyboard buttons. For example, we can go back to the initial menu with the
back button of the keyboard joypad or with key number 1, we can add a land-
mark with key number 4, etc.

9
4.4 ServletConnection.java
The last class of the client side implementation is the ServletConnection, which
is responsible for connecting and sending the file to the server. The class includes
four methods: connect, which connects to the server via an http connection (the
url is specified in the MIDlet JAD file), setData, to set the destination email
address for the data and other file related information, sendData, to actually
send the data stream to the server, and closeConnection to close the http
connection once the communication is finished.

4.5 Tracker.java
The T racker servlet class is the entry point of the server side implementation of
the Funny Tracker. Once it receives the data from the Funny Tracker MIDlet,
it (i) creates a local kml file on the server (method createF ile), (ii) upload the
file to an ftp site, and (iii) sends an email to the specified email address with a
link to the url of google maps from which to see the path on a browser, and the
kml file as attachment.
Class T racker extends the HttpServlet class, and performs all operations in
the doP ost method. Steps (ii) and (iii) are performed by using the SimpleF T P
class and EmailM essage class respectively.

4.6 SimpleFTP.java
The class responsible for uploading the kml file to the ftp server is SimpleF T P .
This class is a modified version of a class available online5 , and includes all
the required functionalities of an ftp client: authenticated connection, working
directory setting, and file upload.
For connecting to the ftp server, we need to provide user name and password
to the connect method. Once connected, we can set the working directory with
the cwd method and proceed with the upload by passing the kml file to the stor
method. After that, we call method disconnect to close the connection.

4.7 EmailMessage.java
The last step of the servlet activity is to send an email to a specified address.
This is accomplished by two methods of the EmailM essage class. In particular,
we pass to method sendM ail the address of the sender, of the recipient, the url
of the kml file to attach, and the link to the google maps site from which to
check the path. Method setM ailP arts creates the mime multipart message
which is later sent to destination.
The mail server used to send the e-mails is the OWA SMTP server of the Free
University of Bozen-Bolzano. EmailM essage requires the JavaMail API6 to be
installed. The code of class EmailM essage is partly taken from the SMILE
peer-to-peer application7 .
5 http://www.jibble.org/simpleftp/
6 http://java.sun.com/products/javamail/
7 Computer Networks course project - Free University of Bolzano - Academic Year 2005/06

10
5 Major Implementation Problems
In this section we will review the major technical problems faced during the
implementation of the Funny Tracker MIDlet, and how this problems have been
solved. Basically, we can identify four major problems encountered during the
development: (i) displaying a map and adapting the coordinates to it, (ii) show
the content of a kml file on Google Maps, (iii) reading and writing files to the
mobile device file system, and (iv) sending an e-mail message.

5.1 Coordinates Computation

One of the first big problems we had to solve in the implementation of our track-
ing system was, starting from a map image, how to compute the coordinates
on that map. More precisely, we needed a way to convert a pair of coordinates
(latitude and longitude) from the absolute scale to the image scale. This com-
putation is necessary to correctly display the user position on the map in the
application.
The solution is achieved in two steps: first, we need to set the absolute
coordinates of the top-left and bottom right corners of the map image; then,
given a pair of valid coordinates (inside the latitute/longitude map interval),
the position of the user on the map is obtained by computing the distance of
the pair from the two corners, and relating it to the width and height of the
image. This solution was found by looking at the code of the CityGuide sample
MIDlet.

5.2 Kml File Visualization

The main problem of visualizing a path on Google Maps is that the kml file
of the path has to be stored on a server accessible from the web. Initially, we
tried to find a way to display the path directly from the file. For example,
we downloaded the Google Maps Mobile application, but also for that it was
necessary to first upload the file on a web server. The only program able to
open and display a kml file is Google Earth, but the fact that the user needed
to have it installed was too limiting.
Finally, we decide to adapt our code to the Google Maps needs. We im-
plemented an ftp client, to upload the kml files to an ftp server constantly
connected to the internet. In this way, the path can be visualized with Google
Maps by entering the appropriate url (Google Maps url, followed by the private
server url ending with the file name) on any browser. An example of possi-
bly valid url is: http : //maps.google.com/maps?f = q&hl = en&q = http :
//www.noisyroyaldirt.it/M S/path1.kml.

5.3 Storing and Accessing Files on a Mobile Phone

A hard implementation choice was to decide what to do when the user saves
a tracked path on the mobile device. The different options included: sending
the path immediately to the web server and managing the collection on the
servlet, temporarily storing the coordinates sequence on the mobile as a string,
and giving the user the possibility to send them later on (before quitting the

11
application, otherwise temporary data would be lost), or storing the collections
as files on the file system.
At the end, we decided to implemented the last option, considering it the
one giving more possibilities. First of all, this allows not to lose the data after
we quit the application, and to reload them when the MIDlet is launched again.
Furthermore, storing the data on the device file system makes the files available
also outside the MIDlet. In this way, the user can transfer a file from the mobile
to a computer in different ways (e.g. via bluetooth).

5.4 E-mail Message Delivery

Most problems encountered in the system implementation came from the deliv-
ery of the e-mail messages. In particular, we were not able to deliver messages to
addresses external to the servlet. Initially, we used the JAMES8 SMTP server
for sending multipart messages. With this solution, we were able to send e-mails
to other internal users, but not to addresses on other mail servers. The problem
persisted even by turning off the firewall.
After several useless attempts to overcome this limitation, we decided to
switch to an alternative solution. The final implementation of the EmailM essage
class uses the OWA SMTP server of the Free University of Bozen-Bolzano. To
do this, we need to enter some user’s credentials in the properties for the connec-
tion to the mail server. In order for the e-mail service to work, it is necessary to
have the JavaMail API installed and to copy the mail.jar file into the runtime
library folder of Tomcat.

6 Conclusion
We often feel the need to record some moments of our holidays, or some informa-
tion about our trips. The Funny Tracker gives you this possibility. The Funny
Tracker is a mobile application enabling the user to record the path covered,
add comments on the visited locations, and eventually send all these data to a
server station. In this way, we can store the information on a fixed device and
revisit them at any moment.

8 http://james.apache.org/

12