4 posts tagged “flash”
At first I was seduced by Tweener's method of making all tweening activity global class functions. After all why would you want two tweens on any singular parameter at the same time anyway? By making class functions, it's easy to prevent it from happening. But upon reflection I think a Tween deserves to be a separate entity that stands on it's own. Robert Penners foundational Programming Flash advocated a Tween be a separate object as well.
There's really not much code in Tweener. It's no insurmountable task to just reproduce...
I much prefer the method devised by adobe for it's Flex 2 mx.effect classes.
But they only work on UIComponents and subclasses, which are flex components, basically. So, for example, mx.effects.Move doesn't work on a Sprite. Pity...there's no reason it shouldn't, from what I see.
I can reimplement most of what I want from their already great design, only to be used with Sprites. That's my plan. No need to reinvent the great architecture. Just a need to implement with Sprites...I'll reuse everything I can, like the built in easing classes and the Tween() class (internally).
By peeling tweens off of Sprites and letting them stand as first class object citizens, we allow ourselves to reuse the same tween on several objects. We can also alter small parts of a tween and apply, over and over, to the same or different Sprites. (We could actually Tween the values of the Tween! boggling!...haha). Also a standalone object like mx.effects.Move incorporates methods like pause(), reverse(), playInReverse() (sorta), and many others that aren't handled as elegantly with Tweener's global function system.
Say I want to slide a button to the right on rollover, and back to the left on roll off. I can instantiate one Tween and then just play it forward and backwards. With each rollover/rolloff, I can reuse the same object I only made once. If I call Tweener.addTween() i'm throwing one-offs each time.
There's also a major design flaw in Tweener as I see it. All it's tween callbacks remain old-school actionscript 2.0 style. You explicitly define singular functions for each different callback....DUDE, where's the EventDispatcher love? AS3.0 loves EventDispatchers and you should too....they are super flexible and they really help design the interaction of objects that must be aware of each other's current state. Plus their functionality is built in! just grab and reuse.
fleh. </rant>
If you are developing anything from scratch, or maintaining anything relatively small, in Flash 8 or below, then please smack yourself.
I think we can all agree that code almost always ends up lasting longer than people anticipate. I still read stats that some 80% of production corporate code remains in COBOL or Fortran and other such craziness.
I also doubt there's any arguing at this point that flash 9 has reached at least 90% market penetration. This link shows 84% back in March, growing from only 55% in December '06. That's an incredible growth rate and it'd be impressive if since March it hadn't crept over 90.
Given that we know that code ends up lasting and hanging around longer than people anticipate, and flash 9 is being adopted at astonishing rates, continuing to generate code in Actionscript 2.0 at this point in time is not wise.
Flash 9 .swfs can be generated with only .as files and a command line compiler. No binary files are needed. So finally Flash can actually be incorporated into build cycles, placed in ant files, etc.
Actionscript 3.0 is also just a much much nicer language. No more hacks. Finally done right. The VM for it will be the background of Ecmascript 4.0, and has also been donated to mozilla to be synchronously developed as the VM for it's Javascript engine! (Link here).
I've been playing with Actionscript 3.0 using the free Flex 2 SDK. It is so sweeeet.
Check this out:
It's using a grid-based detection system for speed, but I've intentionally set the grid huge. Each one of those drawn lines represents a distance and "repellant" calculation per frame...no way could I have gotten that out of AS 2.0...
It's coming up on 2 years now that my full-time job was essentially a "flash-developer". It's only recently hit me how deeply I've already enmeshed myself down the flash and web-front-end developer path. Besides moving within my company, I think it'd be hard at this point to switch jobs to another segment of development without taking a pay-cut. That's because I can be a somewhat-senior "flash developer", but I'd be closer to "entry-level" developing desktop c[derivatives], or back-end java, etc.
I maintain a strong interest in development of other sorts, most notably Ruby and Rails. And I think self-education and then demonstration is vital to successfully shifting your development career-path. But inevitably what I am doing for 35+ hours a week is going to be the area I have the most experience and expertise.
It's odd, and certainly somewhat disturbing, that what started as a very happenstance coincidence has snowballed into such an important reality of my current professional career....and one that will only grow further with time. Initially, I hunted for jobs anywhere across the computer science spectrum. In 2005, the same week I got my first job programming flash, I also interviewed to write C for digital-cable-switchers. It was real-time, embedded-application C-development. I thought I did horrible at the interview, (I couldn't tell them what a "singleton" was!), and expected a prompt "no thanks". But they wanted a 2nd interview. Yet the flash company wanted me more immediately, and they had a really interesting simulation project. So I took it, and never had that 2nd interview with the cable-coders.
Inadvertently stumbling down a certain specialization of development that you may have not intended is something that I think is true for a LOT of developers. What you get into from the start, which is often by luck of which company would hire you, ends up deepening into your "focus". Even those people that get to choose exactly what they want, may still wish to reinvent themselves in the future to avoid burnout.
Of course, many developers just shift into management or other peripheral paths. But for those with the intention to stay in development long-term, I think it's an issue worth considering. Or maybe the same language/tool for 5-10+ years isn't all that bad....
