Developer Tools‎ > ‎Gemba Libraries‎ > ‎

Design Document

Gemba Design Overview

There is a GUI, which is currently called "Gemba Map Viewer", however the project name is "PlaceEngineTest", for obvious historical reasons.  The map viewer app will likely eventually be renamed. The test map viewer application uses several units which were created for this project and others. The major ones are

  1. PlaceEngine – This does what you would think, and provides a binding between the program and the Sony PlaceEngine client. (Which determines location from available WiFi access points).

  2. OSM – This provides a binding for making calls to the OpenStreetMap service, and includes utility functions, as well as a caching layer.

Both units use the synapse TCP/IP library for networking calls. 

The first prototype version of the MapViewer suffered from severe responsiveness problems. This was due to the large number of time-consuming blocking operations performed in the main thread used by the GUI.

  1. TCP/IP requests to the PlaceEngine client (These take time, because the client will sample the WiFi signal, and then send it's own request to the Sony servers).

  2. TCP/IP Requests to the OSM server for non-cached map tiles.

  3. Disk reads for cached map tiles.

Through experimentation, it was determined that #1 was the biggest contributor to unresponsiveness. The reason is that the requests can take several seconds. Specifically, the query to the server can take upwards of 30 seconds at times.  If we want the display to update every few seconds, then as soon as one request is complete, we have to make a new one almost immediately, which means very little time is available for processing GUI events.

The obvious solution was to use threads, which has been implemented for now, however a better design might use an entirely separate daemon process instead to gain the following advantages:

  1. It could determine the location once, and then update multiple apps at once if needed.

  2. No thread-safety issues.

  3. It could easily be switched out with a different app that uses CoreLocation or another technology.(i.e. new location methods could be added without affecting client programs).

  4. Separate programs make testing easier.

  5. It solves the blocking problem in an easy (if overkill) way.

It does, however, have the disadvantage that the daemon must be launched separately.

A test agent app called “PE Connector” was developed, which connects to the MapViewer app via IPC. The MapViewer app does a quick check to see if there are any pending IPC messages periodically, and if there are, it processes them. The PE Connector constantly scans for the current location, and sends the generic location information to the PET app without doing any processing (in CSV format). The PET app decodes this information, and then handles the conversion to tile numbers, etc., internally via the OSM library.  In this way, any blocking network calls are handled by the PE connector.

Although we have abandoned this approach for now in favor of multi-threading, it will likely be brought back in a more generic form at a future point, so that all of our applications can function simultaneously with just one location sensing process. 

Future Directions:

The retrieval of tile images could certainly also be done by a separate process, or at least thread, by implementing a request/callback system, which would do the HTTP request in the background, save the tile to a temporary folder (Since IPC data is supposed to be relatively small), and then notify the caller of the resulting path when it's ready. (In the case of a thread, the file wouldn't be needed, as the image could easily be stored in memory.)

In fact, downloading of tiles is certainly partially multi-threaded.  (Background downloads are supported without blocking the application, but only one tile can be requested at a time).

Multi-Level tile Cache: Right now, requesting the same tile multiple times may not hit the network, but it always hits the disk. I want to make this into a Memory->Disk->Network cache, so that updates in the same area, which result in the same tiles (and scrolling around in the same area) won't hit the disk every time.  Further, tile images already on the screen could be moved when scrolling without even hitting the memory cache. 

GUI Improvements: The prototype GUI is a bit clunky. It's embarrassing that these days a web browser can do mouse-drag scrolling, but it's still a pain to implement in normal GUI apps. The primary goal of this app is to be functional, not pretty, but being both wouldn't hurt.  (Currently planning collaboration in this area with another developer who is working on a MapViewer Component).

Intelligent Tile Pre-caching: When a tile is requested, the OSM library could check whether the surrounding tiles are present in the cache or not, and download them ahead of time if they aren't. It could also download the tiles for the same area at the zoom-level above and below the current one. This means that the user could scroll, or zoom in or out with no network delay, since the tiles would already be present. This is an argument in favor of a separate tile-server process.

Logging: Logging (in CSV format) will be implemented soon.  Export to KML, etc. would be a nice to have feature as well.  Updating Google Latitude is under consideration.

Actions: There are many situations where it would be useful to run a certain action when the location changes. For example, a pop-up message could be displayed, a certain program could be run, or file or web page opened, status updated, email sent, or program run.