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… »
This post will show you how to slim down the service layer in your Rich Internet Application after defining RESTful services.
Posts on REST usually begin by claiming that REST architecture involves much, much more than reducing the syntax of web services to database-derived verbs: create, read, update, delete (CRUD). That’s true, but for this post, exactly that supremely useful reduction will be “REST.”
This post won’t explain how to make a REST call or if it’s possible to wrangle http REST for Flex (no, yes with Rails and Flex, kinda with Java and Flex, StackOverflow). I’ll be focusing on RIA structure rather than http. Examples will be drawn from Flex, but my conclusions should apply to any stateful RIA whether Silverlight or Javascript-based, with any kind of services, whether http or rpc. More… »
Today I learned how to use rspec, the Rails plugin. It was my first experience with unit testing, and it seemed eerily familiar.
You know when you write a class and then instantiate it and throw a couple of curveballs at it just to make sure it works? And then you write a related class, and throw both of them in the air for a few compiles?
That’s it. That’s what unit tests do. I had read a few tutorials on it, but their simple data class examples weren’t vivid enough to help me make this connection to my own practice.
It’s turning my stomach a little to realize how much time I’ve wasted. Informal unit testing is hugely inefficient. With informal unit testing, your little experiments are pretty much tossed into a big dark ditch. With formal unit testing, you can always run them again, which is priceless when you make a modification and need to make sure nothing has been broken. I get that now. Amen.
I was talking with my boss tonite about a big project coming up. He was explaining that a client was thinking of building a new site in AS2. I was dismayed. After developing with AS3 for a while, I was doing some AS2 work and hating it. After AS1, AS2 was a godsend, but after AS3, AS2 is a huge pain in the ass.
He patiently explained to me that my personal likings were not the only factors to consider. There was a lot of AS2 code that could be re-used. AS3 developers were rare and expensive, and training takes time. Etc.
In truth, weighing all these factors is above my pay grade. He is probably right in this case. But, of course, that’s not what I said. Instead, I threw out that AS3 development is just faster.
I was 35 when I started to program. And immediately I loved it. It was as if a part of my brain that had been locked away could suddenly cavort in the broad daylight of ongoing life.
Having developed other skills and burnt though other passions, I was self-conscious about the joys of programming; I wanted to know what this new thing was, and why it thrilled me.
Some joys were not specific to programming per se but would attend the learning of any skill. Obviously, it’s cool to know how to do stuff. I remember vividly the stultification of my three brothers (an accountant, a lawyer, an engineer) when they started their careers, and even more vividly how they slowly got pulled into the details and the drama of their craft. As Moby Dick proved with whole chapters on subjects like stripping of whale carcasses, almost anything can be made intriguing. In the future, maybe bird-watching, souffle and design patterns will each have a cable channel devoted to them.
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.
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:
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.
After updating my trial of FlexBuilder to 2.0.1 (OS X), a slew of errors appeared in my AS3 projects.
I had gotten in the habit of using the same name for 1) a package, 2) the most important class in that package, and 3) a reference to that class in another class.
So for instance:
import alertBox.AlertBox;
...
protected var alertBox:AlertBox
I had a queasy feeling about possible collisions, but I found the symmetry clear and effortless, and there were no problems--until the update.
Then, the compiler started disregarding the variable declaration, and treating "alertBox" as the package, instead, so I got a bunch of errors to the effect that "x" (for instance) is not a method defined for alertBox. ("x" is a property of an alertBox instance, but not a class in the alertBox package).
When I renamed the variables ("aBox"), the errors went away.
Just a heads up.
AS2 access modifiers were simple to understand. Each class was like a cohesive object with an outside and an inside. If a property could be accessed from the outside, it was public. If it was used for the inner workings of the class, it was private.
AS3 presents a considerably more jagged picture. Senocular has laid out the new landscape with characteristic economy and astringency in these posts, but I had to read them about five times before I understood them.
The most striking innovation is the new default access modifier, internal. The first question about this modifier is: internal to what?
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.
