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 moments 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 positions visited during a walk, mark places of particular relevance encountered along the way, and add to them some additional information. The main functionalities 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 tracking system. The tracking is obtained by constantly registering the user position at a given time interval, through a GPS (Global Positioning System) or alternatively, 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 previously stored coordinates. Then the generator reads at predefined time intervals the lines of the script (consisting of the simulated GPS coordinates), calling every 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 information to the path that he is recording. These additional information are called landmarks. The landmarks are special points of interest highlighting precise 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 definitions. 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 devices. 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 screenshots 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 presentation 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 activity, 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 Funny Tracker

of

the

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 popup 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 displayed. 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 Form

Insertion

(b) Path Saved Message

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 procedures.

4.1

FunnyTracker.java

The F unnyT racker class is the MIDlet class managing the execution of the application. 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 communication. The command handling category is constituted of two methods: the implemented 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 selection 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 initialization of application’s forms and related commands, and the display of displayable 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 different from the current, and if it is the case, asks convertCoordinatesT oXY to convert the absolute coordinates received from the location provider to coordinates 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 landmark 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 tracking 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 computation 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 implemented 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 possibly 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 delivery 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 connection 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 information 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