Q&A: Advice for an entry-level ActionScript developer looking for the next challenge
I was recently contacted through my website with a good entry-level question about what to learn next after creating an all-ActionScript Flash application.
Question:
I am an aspiring AS 3.0 developer and was wondering if you could answer a question for me… I am currently just going at it on my own with books and online tutorials… I am wondering if you could tell me what you think I should focus on… I’ve been working on this website constructed entirely in ActionScript. [link omitted.] This is really dull now, but the point is to practice OOP. What do you think? is this the way to do it?
Answer:
Anything that helps you learn and practice programming
on the Flash platform is a good thing. My recommendation if you are
looking for a next focus is to check out Adobe Flex. It is similar to
Flash programming with no timeline, and it adds a wonderful new
dimension to programming with MXML. MXML is a software modeling
language, usually used in combination with ActionScript, and allows
you to express many parts of your application in a way that is more
logical to understand and manipulate. For large Flash applications
where there is a lot of ActionScript, Flex is the leading standard for
“gluing together”, or organizing complex logic. Also, Flex has been a
very easy sell for me when talking to clients who are looking for
Flash development. My best selling points are: It reduces time of
development and is ideal for data-driven web applications.
Question:
Hey Harry,
Thanks for the in-depth reply! I’ve gone ahead and picked up a copy of Flex 3 and am very impressed with mxml… I was a bit nervous about having to learn yet another language, but it seems like its alot like html. I definitely see how this piece of software is the next step in AS development.
So I would like to see other flex sites for inspiration and so forth…do you have a portfolio page by chance? or do you know of any flex pages off the top of your head that you really like?
Answer:
I’m glad you see the path forward with Flex! I didn’t
want to use the “HTML” word because it is more of a Markup language
than a Modeling language, and it has become such a lock-in to a very
limited set of tags and functions, whereas MXML is extensible in ways
that you will continue to learn throughout the first year that you use
it.
MXML is a different kind of language than anything I’ve used before
because it is a software modeling language, not a programming
language. A little known fact that should be stressed from the
beginning is that the Flex compiler first turns MXML into
ActionScript, and then only ActionScript gets compiled into your
completed SWF file. Everything that exists in MXML is essentially a
specific recipe for how to logically create ActionScript out of it.
(This happens behind the scenes and you generally don’t get to see the
resulting ActionScript, but you should be aware that it is happening.)
You will learn a lot of tags as you go forward. The best place to
learn about these tags is http://blog.flexexamples.com/tags/ because
the examples are small, focused, and in the form of completed
applications. Start by clicking on the reddest tags first, then click
through each example until you see one with source code that is at the
right speed for you. Ignore anything that starts with “Fx” because
that is for Flex 4 beta.
The first 3 concepts that I suggest learning about are: States,
Events, and Data Binding.
—
Data Binding is another part where ActionScript is generated behind
the scenes that you don’t get to see, but you should be aware of the
invisible. It works like a pitcher and a catcher.
The pitcher is ActionScript that looks like:
[Bindable] var myVar:String;
The catcher is MXML that looks like:
<Panel title=”{myVar}”/>
Simply put, whenever you have ActionScript that says
myVar=”something”, the Panel title will automatically be updated to
reflect the changes.
What’s REALLY going on in the pitcher is that [Bindable] causes myVar
to get turned into:
var _myVar:String;
function get myVar() { return _myVar }
function set myVar(value)
{
_myVar = value
dispatchEvent(…) // tell the world that myVar has changed!
}
And what’s REALLY going on in the catcher is that code gets added
during the construction of the panel that says: “listen for that event
that gets dispatched when myVar changes. THEN, do this: panel.title =
[the new value]“.
—
Now that I’ve explained some of the invisible parts, it should be
easier for you to understand the visible parts through resources
online. (Too many experienced Flex developers don’t understand the
invisible parts.) For everything else, you can always start with a
google search!
I hope this helps!
If Adobe Made Cars…
Embracing Open-Source is one of the most significant advantages to Adobe in increasing the value of Flex. Open-source components are what make my Flex applications so much bigger and better than applications that I created in other languages. The built-in components made by Adobe are good too, but there is a major advantage to tapping into the development skills of the thousands of Flex developers who aren’t employed by Adobe.
Today, I read an interview with General Motors Vice Chairman, Bob Lutz regarding hybrid cars. Lutz says “One of the major challenges with the car is writing all the software codes for all of the zillions of possible interactions between driver, electric drive, battery, regeneration, when does the internal combustion engine come in, under what circumstances?”
As a Flex developer living lavishly in the Adobe world, I immediately related to this software development problem with this idea:
The solution is to open-source the software, and let me and people like me write the software for them. I know exactly what I would do if I had an API to my Honda Insight, and I would do it better than Honda has done it.
For example, I should have a button that I push before I know I’m am about to drive up a 2,000 foot hill. That button will indicate that I want to favor battery assistance, and don’t ever try to charge the battery unless I step on the brake. When I’m at the top of the hill, my battery will be very low. Then, as I drive back down the hill, there will be opportunity to recharge the battery. But if the battery is full at the top of the hill, then the kinetic energy from my descent will be wasted because it can’t be stored in the already-full battery.
Also, there are times in traffic where my driving actions cause the software to alternate between assist and charge every few seconds because I am slowing and going, even though I’m never braking. In this case, the software is doing more harm than good, and I would have better milage if I could unplug the electric motor completely.
I’ve had these ideas for years, and now I’m just waiting for somebody from a big auto manufacturer to come up with the same ideas so I can have what I want.
The point is that manufacturers should not try to supersede the intelligence of the software development community because then the advancement will be limited to what one single entity believes is a good idea. Sure, Lutz expressed good ideas like the OnStar integration, where the car knows if it is about to return to the home charging station and therefore it knows there’s no point in giving the battery a full charge. But for every one of those ideas, I’m sure the community has many more ideas that are just as good or better. And there’s no way for anybody to know what’s a good idea until experiments are tried. The best way to create a winning situation is to allow the community to experiment for themselves, at no cost to the manufacturer.
If Adobe made cars the way Adobe makes Flex, I wonder how customized we could really make them.
Tripping Over my Own Data Bindings
I just learned about a little “gotcha” in Flex, and I’m writing to warn you about it. A counterintuitive behavior involving Flex data bindings. And of course it’s just my luck to run into this kind of thing when I’m in the middle of trying to learn Cairngorm, (which so far is the greatest feat that I have attempted as a Flex developer).
So here’s the hitch: I have an mxml component. (It’s part of the View layer in the MVC pattern.) It has data bindings to the ModelLocator singleton (the central repository of application data). One of the data bindings needs to invoke a setter so that custom code can be run to react to the data model change. Specifically, here’s the code that I’m talking about:
<mx:Binding
source="model.isStreamConnected"
destination="isStreamConnected"
/>
<mx:Script>
<![CDATA[
private function set isStreamConnected(inConnected:Boolean):void
{
...
}
]]>
</mx:Script>
Next, I want to bind the same data to the ‘enabled’ attribute of my media controls container, so that the controls will be disabled when it’s not connected, and enabled when the stream is connected. So I include this:
<mx:Canvas
styleName="MediaControls"
enabled="{model.isStreamConnected}"
>
...
</mx:Canvas>
Although this seems like a perfectly reasonable way to use data binding, the problem I encountered is that even after the stream was connected, the canvas remained disabled.
