Archive for April, 2009
In “Blashphemy! Burn the Flex-hating heretic!”, I likened Flex evangelism to a religious cult. If I pursue this theological metaphor, then Pure ActionScript developers, like myself, are clearly atheists. Our choice is not dictated by faith or devotion to Adobe Flex. Pure ActionScript is IDE agnostic. It’s a pragmatic individual choice. It does not blindly follow the congregation. (Most information on Flex, most blogs and training courses, will focus on MXML.)
It is possible to utilise the Flex-framework and components, via a Pure ActionScript approach. However, I am presenting Pure ActionScript approach here as an ALTERNATIVE to the Flex components. Not a complimentary philosophy.
So, let’s compare the use of Pure ActionScript to the Flex/MXML (Flying Meta-Tag monster) approach.
The Ten Commandments of the Church of the Flying Meta-Tag Monster…
1. Thou shalt use meta-tags.
Flex evangelists will tell you that MXML is simply an equivalent way of expressing ActionScript. (The apples vs. apples argument). While this is true, and you can always express MXML as ActionScript, it does not work the other way around.
It is possible to automatically convert MXML script to ActionScript script. So it is also possible to automatically generate ActionScript from a Flex Design View visual representation. Yet Flex doesn’t include this feature for the benefit of Pure ActionScript developers who want to manipulate, resize and position their components visually. Why not?
2. Thou shalt find me difficult to learn.
Actually, MXML evangelists often claim the opposite. “MXML resembles HTML – therefore it is easy to learn.” But in actuality, this resemblance is superficial, and it certainly does not prepare the novice for the finer points of MXML development. But the similarity between ActionScript and other programming languages is much more profound. For a software developer, the transition to Pure ActionScript is relatively painless. Whereas MXML requires the user to ascend a steep learning curve, irregardless of their transferrable skills.
3. Thou shalt not produce a small file.
The Flex-framework is incredibly bloated! Flex evangelists will claim that file size is irrelevant. But at least the smaller, leaner, files produced using Pure ActionScript don’t keep you waiting, staring at a loading bar, while the application loads.
4. Thou shalt not create applications that run efficiently.
Ok, it depends how you write it. But you have much more control over the computational load with a hand-crafted Pure ActionScript program.
5. Thou shalt not use any other IDE.
A Pure ActionScript application can be developed in Flex, Flash, or third-party IDE. Or you can switch between IDEs, depending how you feel that day, or the phase of the moon. This also means that you are free to re-use your code across IDEs, and collaborate on Flex-based projects, Flash based projects, work with other programmers, or graphic designers.
6. Thou shalt not target multiple platforms.
In Flex you decide at the outset whether your project is for the browser or the desktop. Flex is dogmatically restrictive. Suppose you have a Browser project, and you open a file that references AIR-runtime objects. Flex will actually delete the include statements from your source code!
When I develop a Pure ActionScript AIR application, I write it first without AIR-runtime methods. Then I include those methods within a main class that inherits the main class of the non-AIR program. This methodology enables me to deploy my applications to either AIR or the browser, and to test most of my application without launching the AIR runtime.
Pure ActionScript produces a smaller file-size and lower computational load. These are important considerations for adapting an application to a Mobile device.
7. Thou shalt not port thy applications to any other language.
It is easy to port Pure ActionScript code to another programming language. But it is easier to pass through the eye of a needle than it is to port a Pure ActionScript / MXML hybrid. Some developers have ported ActionScript programs to the iPhone.
8. Thou shalt be required to read the documentation daily.
This is my penance as a Flex contractor. Sometimes, I’m required to make Flex components behave as if they were not Flex components. If I’m very lucky, this can be achieved be overriding a method, or responding to an event. Each Flex object has hundreds of documented properties, methods and events. Each documented with a very brief description. Sometimes, you can hit upon something useful by trial and error, just reading through the list, and trying out things that looks relevant.
The problem with the Flex components is that they are too complicated. Adobe has tried to make them flexible and configurable, adding so many bells and whistles. I would have preferred the Flex components to be smaller, simpler, with fewer parameters. But documented from the point of view of a programmer who might want to override its methods.
9. Thou shalt not change the sacred private methods.
Sometimes, it’s not enough to treat a Flex component as a black box implementation. Sometimes, you need to familiarise yourself with the code, and override private methods. Why did Adobe make them private? Why are they sacred? Why not just protected?
10. Thou shalt not embark on sophisticated projects.
Flex makes simple things a little simpler. But, In the author’s opinion, more sophisticated projects, and highly customised interfaces should be approached using Pure Actionscript. It is easier to write a custom component from scratch than to change and rewrite custom Flex components to do precisely what you want.
As a hard-core Pure ActionScript programmer, it’s often quicker for me to write something that to search for, and understand, a third-party object. (Why use a DataGrid? – when you can write a couple of nested for loops that set up a grid of TextFields.)
. . . . .
I set out to present a polarised and contentious argument, and to promote discussion. But, the process of contrasting two approaches started leading me into constructive ideas about how the Flex environment could be improved for the benefit of Pure ActionScript developers.
Automatic generation of ActionScript from a design view and a simpler set of Flex components designed and documented for the programmer who likes to use inheritance and override methods. If these Flex components were small and simple enough, then perhaps they could be appropriate for mobile devices, and Open Screen deployment.
This is my second video. A quick tour of the features in e2spreadsheet.
This application has been around a long time. It was originally written for flash 5, it was ported to Macromedia Central and then to AIR.
e2spreadsheet can be downloaded from here.
As promised, here is a video tour of e2vector’s features. Occasionally, I’ll also twitter about hints and tips for using my AIR applications.
e2vector can be downloaded from my website.
I’ve always considered the challenge of designing a sophisticated AIR application was to hide that sophistication from the user.
It’s a challenge to make the complicated appear easy.
Conversely, it’s easy to make something simple appear complicated. And Flex is a wonderful tool for making things look difficult. Dazzle your user with DataGrids, List components and Buttons, and glue it together with data-binding and a few lines of ActionScript. It doesn’t take a lot of effort to build something in Flex that really confounds the user with information, and lacks navigational structure.
If you build yourself a showcase of such poorly designed Flex apps – you can probably pass yourself off as a Flex expert. Customers will be so baffled that they’re going to assume you must be some kind of genius!
Personally, I’ve taken the path less travelled. Incredibly sophisticated software projects. Months of intense development. Devilishly clever algorithms. Hundreds of pure-actionscript classes. All hidden behind a deceptively simple and intuitive interface.
e2preadsheet incorporates an algorithm that enables it to evaluate all the formulas in the right order (data dependencies), but avoid unnecessary re-calculations. It refreshes the spreadsheet behind the scenes, yet the naive user would be oblivious to its existence. The automatic scaling on graphs is also something I’m proud of.
e2vector incorporates a very sophisticated algorithm that enables it to splice paths. Pulling apart overlapping arcs so that they split at the points where they overlap. It takes a lot of code to achieve something that seems so simple and intuitive to use. Shape intersection and union are not trivial either.
A potential customer wrote to me recently, saying that he’d seen what was on my website, but was looking for something more sophisticated! I considered spending ten minutes in Flex to impress him with a DataGrid/ListBox monstrosity.
Instead, I’m preparing some online videos about my applications and their features. (Coming soon). Users tend to be too passive when they evaluate internet-related applications. Like watching TV. Actually, more like channel-hopping with a small attention span. That’s a problem with developing software for the browser. I’m sure that users are only impressed by entertaining Flash-like eye-candy. All style and no substance.
I thought that AIR might create a new niche. Running alongside conventional desktop applications would raise the bar. Applications with more substance that would change expectations about what the Flash platform was capable of. But I’m probably just wasting my time here…