Building the Tour Tracker, part 2

The Application
Okay, part 1 gave an overview of the big parts of the Tracker solution. Now, let's take a closer look at how I built the Flex application. The source will be available soon should people be interested, but in the meantime, I want to give a structural overview and provide some details of the architecture and implementation. In part 3, I will then go into more details about specific parts.

For those who care, my Flex project is made of 50 MXML files and 75 ActionScript files. Throw in a couple of SWC files for visual assets and the XML that describes the race itself and that's everything.

Application Visual Tree
Application contains a single Tracker object (pure ActionScript) that maintains all the state of the application and a set of visual components (all MXML): the course map in the background, a navigation bar across the top, a branding bar at the bottom, and one class for each of the "pods" in the user interface. Those pods are the profile display (the mountain range), the play-by-play pod, the live video pod, the tour standings, the GPS rider list, the stage results list and the video/photo list.

Tracker
The tracker class is the heart of the machine and is passed to most top-level visual elements. Since the singleton tracker object is declared in the main MXML file, it is constructed automatically and its constructor begins the process of loading data from servers. It has a number of critical functions:

- has a Tour object which represents everything that is known by the system about the race.
- has a member that represents the stage that the user is currently viewing
- has a set of data managers for communicating with Flex Data Services, the XML web server, and Flickr

At startup, the Tracker coordinates the loading of various data, making sure the required XML files are loaded and process, that connections to Flex Data Services are established, and a bit of bookkeeping.

Tour
The tour class is primarily an in memory representation of the state of the race. It is loaded from an XML file (either embedded or on the web server) and includes:

- the name of the tour
- an array of Stages
- an array of Teams (name, 3-letter code)
- an array of Riders (name, team, location if GPS tagged)

Stage
The stage class contains everything known about a specific day of the race. Half of that information is read from XML files as part of the Tour initialization. Half comes from other data sources (like Flickr). And the third half is real-time race data. It also provides methods for starting and stopping a race. The stage keeps track of:

- name, date, location, start time
- a Course object
- an array on play-by-plays for that day (grows real-time)
- an array of photos and videos from that day (grows real-time)
- actual start time of the race if it has started
- the position and speed of the peleton, broom wagon and break-away cars
- an array of GPS-tagged riders for that day and their positions and speed
- a Results object once the race is over (read from XML posted real-time)

Course
The course class represents the race course itself including the route the race covers (a KML file generated in Google Earth), Markers that represent special points along the course (climbs, sprints). In addition, the course provides methods for mapping between lat/long, elevation, distance and grade.

Okay, enough for one post. Next, I'll get into a few details of these classes and the some of the more interesting stuff: server connections and my favorite, the map and it's overlays...