Built One of the First Complex Commercial Flash Apps

Project: Slooh Space Camera

Challenge
Build a complex, demanding, extensible Flash app in Actionscript 1 — before micro-frameworks, classes or community knowledge of MVC design!

Comments
The online astronomy app, Slooh, would be massive undertaking today, using modern technologies, even for a team of developers.

In 2002, using the Flash of the day, and one developer, it was extremely ambitious — but succeeded, and ran without significant code updates for around 7 years.

This was when Flash was still at ActionScript 1 and community knowledge for building large Flash apps almost non-existent.

Major requirements for Slooh included:

  • Client-server architecture with Flash Media Server (FMS) back end
  • Lots of streaming data of all major types, including images and audio
  • Numerous latency issues, connection-speeds and time-zone adjustments
  • More than four dozen significant features
  • Asynchronous, two-way communication using several data types
  • Complex business rules and application logic
  • Strategic preloading of images, static audio and data
  • Numerous modules, ability to add additional modules over time
  • Precisely timed programmatic animations
  • Performant and synchronized on all connection speeds and computers
  • Manage two simultaneous audio streams and toggle between 8 streams
  • Client must manage four or more simultaneous instances of everything listed above, maintaining state when pausing and resuming instantly at a progressed point
  • Divide logic between client and FMS and client in a way that strategicially balances the needs for performance, maintainability and minimal updates by the user

Actions

  • Used AS1 OOP prototype-based classes and OOP patterns, as taught by Colin Moock in “ActionScript MX: The Definitive Guide”
  • Early form of “model” — Built special-purpose classes to hold each distinct data set, along with various “get” and “set” methods so that data access was managed by the data classes themselves.
  • Early form of “views” and “view controllers” — The UI was controlled by a hierarchy of parent-child manager classes that mirrored the natural nesting of view widgets inside of other view widgets. Each level managed its own states and behaviors and knew little or nothing about other parts of the application.
  • Early form of “controller” — This very complex application was governed by approximately a dozen “managers” (incoming-data manager, data processing manager, session manager, UI manager, outbound data manager, etc.) each taking orders from and reporting back to a main manager.
  • Communication logic  — The app was entirely event-driven. All entities sent event messages to a central manager class, which then consulted a state manager and business-logic manager to choose an appropriate action, if any.
  • Business logic — Business rules lived mainly in the Business Logic manager, but in some case lived within the various lower-level managers.  However, all business-logic was easily findable through conventions of method- and variable-naming.
  • Service tier — Incoming and outgoing messages were managed by dedicated managers.
  • Multiple simultaneous sessions — Certain top level managers could be instantiated and number of times, and could in turn create new instances of their children. This allowed the app to support multiple simultaneous viewing sessions. Initially, uses could toggle between two different telescopes and one observatory. Later, they could toggle between two observatories, each with two telescopes.
  • Server-side Actionscript — FMS component was itself very complex, managing constant dequeuing and parsing of remote data streams, performing software load balancing, managing user connections, streaming data to users, digesting client messages, and more