Flash releases tend to operate on the each-kid-gets-a-turn principle: one for the developers, one for the designers. After reading this article on Gumbo component article, however, I think Christmas might be come early at Adobe. Because if designers will luv Gumbo’s new skinning model, developers will luv luv luv the new component architecture. More… »
In the first post of this series, I explained why I wanted features like long-term flexibility, deep linking, history, and background loading for my new, all-Flash playground site, pet-theory.com. I also explained why I used design patterns to meet these requirements.
In subsequent posts, I explained how it was done, focusing on one design pattern per post: Strategy for navigation, Mediator for application files, Interface for loading, State for loading swfs, Composite for a background loading queue, and Command for history.
In this post, I’ll summarize the entire process. I’ll start by identifying the fundamental problem bedeviling all-Flash sites, and end by suggesting that my solution to this problem can be the basis of a flexible, lightweight, comprehensive framework.
When they implement history at all, all-Flash sites tend to offer history-like gestures like a Back/Home/Before arrow in lieu of the actual, click-by-click back- and forward-tracking of a browser.
This degradation of a useful and universally expected feature usually makes navigating these sites awkward, often painful.
So I decided (after preliminary reflections recorded in this post) that my playground site should be equipped with a full-fledged history.
This decision committed me to a systematic approach to navigation, because I suspected that the more systematic the navigation, the more manageable the history…and this suspicion proved justified. Once I had set up a navigation system in which every navigation was handled by the same piece of code and used the same syntax, adding history was trivial.
The basic operation of the composite pattern is easily grasped. Composite is another wrapper pattern that involves one object rerouting method calls to another object with the same interface.
Graphed, it looks nearly identical to the state pattern. Remember that with state, a wrapping object relays method calls to any one of a number of objects with the same interfaces, depending on its “state.”
With composite, rather than relaying the calls to one internal object, the wrapping object relays the calls to ALL of them.
In a tree of modules, some modules will need to load assets when selected…and some will themselves need to be loaded.
I was acquainted with interfaces before I read
I remember vividly the first time I opened up the Actionscript panel in the Flash IDE and wrote one line in the heretofore untouched panel:
[as]
myApp=new Application(_root);
[/as]
It was a special moment because this lightning-stab of a line both compressed and expressed a week of work. Ctrl-Enter…and…SWISH!
Between that moment and moment I cracked open Head First Design Patterns, I learned surprisingly little about application files per se.
I wanted things for my playground–not only history, but deep linking and persistence (the site wouldn’t automatically reboot when backtracked)–that made a systematic approach to navigation necessary.
At the same time, I hadn’t decided on the what of the navigation (the sections), or the how of the navigation (the transitions between the sections), and I didn’t want to commit to any particulars, since I hoped the site would last a couple of years, and who knows what WHAT or HOW would be fashionable or imperative two years from now? If I look back two years, the shifts are staggering.
So right away, the fundamental question arose: how to plan for flexibility?
I’m doing a week of posts on how I built my new playground site, pet-theory.com. My three-fold aim is 1) to introduce designs patterns to those unfamiliar to them, 2) to give a soup-to-nuts example of architecting a site, and 3) to suggest solutions to some problems common to all-Flash sites.
I’m no expert on patterns or site architecture. Far from it. Before this project, I was where many Flash coders are: comfortable with the techniques of OOP (objects, inheritance, encapsulation), and reflexive about separating the structure of data from its representation and manipulation (Model-View-Controller, not so much a pattern as a worldview), but unsure where to go next.
I always figured it was laziness when Flash designers omitted the back button…until I considered implementing one myself. Then I realized that this is another case where the wide-open freedom of Flash leads you directly to ground-up difficulties.
The back-button works so naturally in a browser because HTML presupposes one kind of transition: one page replaces another. Take for example this navigation strand in a hypothetical medical site:
body.html–>organs_heart.html–>cells_heart.html–>cellParts_lining.html
Because pages are essentially fungible nodes in a network structure, users can swap them with ease. This holds for backwards-and-forwards tracking as well as other types of navigation–jumping back in the history, or up to the home page.
Now imagine that a mop-haired designer is charged with designing a Flash version. The result: As a user rolls over a picture of a body, the body becomes transparent. Clicking on an organ zooms it and brings up text at the side. Clicking on links in the text provoke a pop-up with a model of a cell. Clicking on selected parts of cell fades out the body altogether and reveals longer texts…etc cetera.
