FlashThisMofo

Using the Ternary Operator in ActionScript 3.0

2008-09-05T09:32:00.000-07:00

There's no shame in shortcuts, and when you're combing through massive amounts of code each day, every line helps! Many programmers across a variety of languages have long enjoyed the benefits of the ternary operator, a convenient shorthand that can be used in lieu of a standard if/else statement. The ternary operator (pronounced "toy-nairy opratuh" in New York) provides an elegant method of compacting down code where a basic true/false conditional is needed.

Let's taken an everyday scenario: You're at the breakfast table eating Cheerios (or Fruity Pebbles, if large amounts of sugar and food dye are your thing), and suddenly realize you have to test the value of a Boolean variable in your code to shut the visibility of a display item on or off.

A possible and typical solution to this would be as follows:

if(displayBox == true) {
box_mc.visible = true;
} else {
box_mc.visible = false;
}

While this is perfectly legitimate code, you've burned 5 lines of perfectly good white space to accomplish it. Enter the ternary operator.
The ternary operator provides a shorthand, single line method of writing a basic if/else statement. The ternary operator is written as follows:

(condition) ? true result : false result;

The condition appears in parentheses before a question mark, and the two possible outcomes are listed afterwards, separated by a colon. Let's look
at how the condition shown earlier can now be written using the ternary operator:

(displayBox == true) ? box_mc.visible = true : box_mc.visible = false;

We can even shorten this a bit more: Since displayBox is a Boolean value, to test its value we can also simply reference it, like so:

displayBox ? box_mc.visible = true : box_mc.visible = false;

Setting values with the ternary operator
Another cool way to utilize a ternary statement is to assign it to a variable to conditionally set a value. For instance, you may want to set one of two possible values
to a new variable pending the outcome of a specific condition. Using an if/else statement, we would take this approach:

var memberType:String;

if(isAdministrator == true) {
memberType="admin";
} else {
memberType="subscriber";
}

Once again, perfectly good code, but a bit of a mess to look at. Let's tidy this up with the handy ternary operator:

var memberType:String = isAdministrator ? "admin" : "subscriber";

Much cleaner, much nicer, and all in a single, slick line.

Speed demons rejoice..well, not so much
By the appearance of the ternary operator, you'd think that performance-wise it should run circles around other conditionals. Unfortunately, this is not
so true. Many benchmarks have shown that there is no speed improvement (in some cases a decrease is reported) compared to traditional if/else statements. However,
these same benchmarks have also proven that it's not enough of a difference to be an issue. The ternary operator has shown to be an elegant way to write
code and save space, and can be a valuable technique when used in the right situations.

Putting a Face on ActionScript 3.0 Interfaces

2008-08-23T11:35:00.000-07:00

Understanding Interfaces in ActionScript 3.0

When most of us hear the word "interface" we think of a set of visual controls that lets us work with something, like a computer application or operating system. Some of us may be "interface designers", which means we put fancy skins on otherwise complex applications.

In programming, interfaces take on a different meaning altogether, and can be useful in making sure that different chunks of ActionScript code all follow a standard for how they should look and behave.

A review of classes
An ActionScript class is best described as a code 'blueprint' which is used to build several more objects just like it. We create classes in ActionScript 3.0 (an even in ActionScript 2.0) to create an object with very specific properties, methods and behaviors.

An example would be to use an ActionScript class to create a flexible button that can be used to build several more buttons just like it. We can add properties to our button class so that it stores its own URL, can set its own label, or even change size and appearance.

While a class can be built to generate a single object, ideally you generate multiple copies or instances of a class so that you have several objects that look and behave the same in your Flash/Flex application.

What is an interface?
An interface is an ActionScript file which allows you to determine specific behaviors, or methods which a series of classes must follow and use. This guarantees that multiple developers can all contribute parts to your application that all follow the same guidelines.

For example, automobile manufacturers know that no matter what type of car they build, it must include the ability to accelerate, brake and steer. It must also include certain safety features, such as a seatbelt and airbag. To guarantee something like this in the programming world, we'd define an ActionScript interface that sets these guidelines, like so:

package {
public interface Automobile {
function drive():void;
function brake():void;
function setMaxSpeed(s:Number):void;
}
}

This standalone Actionscript file, just like a standard class file, is saved under the same name/location as determined by the package and interface name: Automobile.as.

Note: You will notice in addition to having no body {}, the methods defined in an interface have no access modifiers such as public or private defined. This is because it is assumed that any method required by an interface must be public.

Now, any developer who wants to create some type of Car class can not only extend Car (if such a super class exists), but also implement the new interface, like so:

package {
public class Honda extends Car implements Automobile {

}
}

In order for the new Honda class to compile without errors, the developer must include public methods that match each method defined in the interface:

package {
public class Honda extends Car implements Automobile {
public function drive():void {
//Do something here...
}
public function brake():void {
//Do something here...
}
public function setMaxSpeed(s:Number):void {
//Do something here...
}
}
}

If the compiler doesn't find all of these methods in your new class (or if any of them are set to private) it will throw an error. The Automobile interface now guarantees that any developer who wishes to create some type of Car will have to include methods that match the ones defined in the interface. This guarantees consistency while allowing a developer the flexiblity to define how the drive method works to set their car apart.

Keep in mind that you are free to add methods beyond what's specific in the interface to make your Car have unique abilities - as long as the ones defined in the interface are included.

ACEing the ACE: Is it possible?

2008-02-24T15:30:00.000-08:00

Ah..the dreaded ACE exams. Adobe's Certified Expert exams have been regarded as a benchmark of one's ability (and in some cases, viability) in Adobe's industry standard applications such as Photoshop, InDesign and Flash. However, the ACEs have been a subject of much debate throughout the professional community; are they indeed a real demonstration of proficiency that employers use to measure up potential candidates, or are they a cryptic series of gymnastics in test-taking ?

At 150 a pop (50 for recertifications) the ACE Exams are no laughing matter; The full exams are administered in a testing center sans cellphones, electronics and human contact in some cases. Roughly 75-80 questions (30 for recertifications) are presented in a timed manner covering a variety of topics from beginning to obscure.

Recently, the big complaint across the board for the available ACE exams and recerts has been the quality of the questions - issues including errata, vague questions and answer options that seem blatantly wrong no matter what. The Flash CS3 exam, which I recently had the pleasure of taking, didn't seem as flawed as what I've heard about the InDesign and Illustrator tests, but is definitely not free and clear of problems.

Are you a Designer or a Developer?
The obvious existence of two core audiences for Flash CS3 has caused a big rift between designer and developer skillsets. While Adobe has obviously tried to close this gap through some nice new CS3 features, this has no effect on the exam, which will be nearly impossible for someone with limited or no ActionScript experience to pass.

A smart approach that Macromedia took for Flash 8 (which unfortunately, has been phased out) , was to divide the exams into two distinct tests - Designer and Developer - allowing experienced media designers with limited programming background to prove proficiency in the application. Developers of course, had their own exam where they could demonstrate knowledge with Flash's ActionScript with less focus on the "IDE" features (as many devs like to call the Flash Cs3 app).

However, if you're strictly a designer, you're basically SOL (kids, don't look this one up) when it comes to taking the new CS3 ACE, as it's chock full of ActionScript 3.0 questions including advanced topics such as class building, inheritance and other fun stuff more suited for experienced OOP programmers than your average site and banner designer.

What are you KIDDING me?
That's what I said when I saw a few of the 30 questions presented to me on the re-certification exam. While many seemed reasonable, there were some that were worded in such a way that even a seasoned Flasher would grab his/her skulll in frustration.

Here's one:

You have selected a blue stroke and a green fill from the tools panel and have drawn a shape with the Brush too.
Which two statements describe the shape (Choose two):

A) The Shape has a green fill and no stroke
B) Brush tools are not available in Flash CS3
C) The shape has a blue stroke and green fill
D) Shapes drawn with the Brush tool cannot have a stroke applied to them
E) Shapes drawn with the Brush tool can only have strokes applied to them after being drawn with the Ink Bottle Tool.

The answers are A and E - but if you look at E, it's gramatically so awkward that I had to stare at it for a while. Is it after being drawn with the Ink Bottle tool, or by using the Ink Bottle Tool after being drawn? Geez. yes, nitpicky, but really confusing (especially if English is not your first language). At first glance, Answer E seems wrong.

Here's one on the ActionScript side:
You want to create a custom class called SuperArray that is a subclass of the dynamic Array class. Which class declaration should you use?

A) public class SuperArray extends Array{}
B) public class SuperArray overrides Array{}
C) public dynamic class SuperArray extends Array{}
D) public dynamic class SuperArray overrides Array{}

Now, some programmers may disagree, but in my eyes both answers A and C are right. While you have to use the 'dynamic' keyword in order to make a subclass of any dynamic class, well... dynamic, it's not necessary. Both answers A and C will work and compile properly. So my question is, is this a question of knowing the syntax, or leaning a certain way when it comes to OOP practices?

They've got the IAB after me:
This question just plain aggravated me. Obviously, the ACE exams have now spanned beyond application knowledge and into the world of advertising practices:

You want to create a full ad banner in Flash for a Web page. You also what [sic] to comply with the Interactive Advertising Bureau Guidelines for the dimensions of the advertisement.

Which size should you use for your banner?
A) 480x72
B) 468x 60
C) 728x90
D) 800 x 60

Ok, a couple of things with this one. First of all, what if you don't design ad banners for a living? Many experienced Flash designers don't touch ad banners, or at least enough to rattle off the IABs 'net advertising specs.

Secondly, both answers B and C are technically correct - both 468x60 as well as 728x90 are considered standard banner ad sizes by the IAB - the difference is that the latter of two is included as part of the 'Universal Ad Package', so it's slightly MORE standard than the former.
I do want to mention that 468x60 is referred to as 'Full Banner' by the IAB, so if this were to be
interpreted a certain way choice B would be the most correct. But again, like many questions on the ACE, the wording is vague (and often contains spelling/grammar errors).

http://www.iab.net/iab_products_and_industry_services/1421/1443/1452

ACE Test-taking recommendations:

DO NOT RUSH. Read each question very carefully - if you are unsure about a certain question or your selected answer, the exam has a 'Review' checkbox above the question to allow you to bookmark and return to that question later.
GRAMMAR. Whether by design or not, many of the questions feature very awkward grammar or in some cases, typos, that could trip you up. Be wary of this.
PROCESS OF ELIMINATION. Just like the old high-school SAT exams, if you are unsure of the correct answer, try and identify the obviously incorrect answers - using the process of elimination to strike out bad answers increases your chances of selecting the good ones.
WASH, REPEAT, RINSE. If you fail the first time around, make sure to do whatever you can to identify the fuzzy areas that you think contributed to this. You'll at least have a guideline as to what to study and prep for next time around.

The Summary of All things
Whether or not you decide to take an ACE exam (or several) should be based on your career goals as well as your needs. If you feel that a potential employer will look favorably upon this, or give more consideration to candidates with certification, then it's worth taking the time and money to do it.

As a technical trainer, I keep my certifications current as both a requirement of my job as well as a reassurance for my students and potential clients. However, I do advise you - do your homework.

While Adobe provides exam prep guides online for free on their website, surf around and see what other people are saying. Some test takers are kind enough to post additional questions, recommendations, or like I'm doing here, wierd snags that you may run into along the way.

In some cases, be prepared to take a test twice. It's not a sign of 'failure' to fail an ACE exam; even for subject matter experts it's a tough run. Consider the first time a 'practice run', but make sure to use that opportunity to identify any areas where your knowledge is thin, so you know what to study before going for Round 2. Oh, and for the record - I scored an 84 on my recertification for Flash CS3 - and I've been using the application since it's introduction...

Getting Buttons to Work in ActionScript 3.0

2008-02-12T16:02:00.001-08:00

In versions of Flash prior to CS3, even the ActionScript novice could easily get buttons to be functional within a movie. Whether it was via the Actions panel’s Script Assist feature, or the forgiving Behaviors panel, it was fairly easy to script buttons to handle the most basic tasks such as navigating the timeline or launching external URLs.

Enter ActionScript 3.0, the newer, shinier version of ActionScript packaged with Flash CS3: Major revisions to the language render many “plug and go” features useless, such as the Behaviors panel, and make it less intuitive to use the Script Assist for even basic tasks such as button scripting. In addition, scripts can no longer be placed directly on button or movieclip instances – this was a discouraged practice among seasoned developers, but a common shortcut for the novice programmer just looking to ‘make it all work’.

All of these major changes are due in large to the new Event model in ActionScript, which controls how objects (such as buttons) receiving and handle events such as clicks, rollovers and keyboard presses.

Let’s look at how actions were assigned to buttons in the past. One possible example was to select the button instance itself, and via the Script Assist (or by hand), apply code such as the following:

on(release) {
gotoAndPlay(1);
}

The preferred and other method, was to assign the button an instance name via the Properties Panel (now Property inspector), and target it via a script on the timeline:

my_button.onRelease = function() {
gotoAndPlay(1);
}

This method targeted the button by its instance name, and uses an ‘anonymous’ function to contain all of the code the button should run when clicked. An issue with this method, of course, was that an ‘anonymous’ function cannot be reused or called again by another button or object later on. For this reason, anonymous functions (and in turn, this code) can no longer be used in ActionScript 3.0.

So…what now?
The principle is more or less the same, but now call and response are separated into two distinct blocks of code: an event handler, and an event listener. Event handlers are named functions that group together code that needs to run when (or if) an object receives an event (ie. Is clicked, rolled over, etc.). These can contain anything as simple as a gotoAndPlay script, or something as complex as several lines of code that do a series of things across your movie. I like to think of an event handler as a ‘job description’ of sorts – one which is carried out when and if an object (such as a button) is asked to do it. A sample event handler, based on the earlier example, would look like this:

function goSomeplace(event:Event):void {
gotoAndPlay(1);
}

Now that a job description is created, something has to be added to let a button (or any other object) know when to carry it out. In your workplace, you typically listen for emails, phone calls or direct verbal requests as a signal to do specific tasks. In a Flash movie, objects can listen for button clicks, rollovers, key presses and several other events. To tell a button (or anything) to listen for something like this to occur, we add an event listener to it:

my_button.addEventListener(“click”,goSomeplace);

This line of code tells a button instance called “my_button” to listen for a click (equivalent to ‘on release’ in AS 2.0 and earlier), and to respond using an event handler named goSomeplace. Call..and response.

Anatomy of an event handler
If you haven’t used or created functions before, you may find most of this code to be way out there..but don’t fret. I’ll break it down a bit further so you not only understand what a function is, but how a special type of function, referred to as an event handler, plays a role in getting buttons to work in ActionScript 3.

What is a function?
A function is a group of related code that is all slated to run together at once. Most tasks (even in real life) can consist of multiple actions carried out at once – for instance, “open car door, insert key, start car, put car into DRIVE”. A function groups statements together – for instance, we could create a function called “goDrive”, which groups the previously mentioned statements together into one related set of actions. In ActionScript a function groups together related actions together into one, named block of code which can be called at any time:

function goSomeplace() {
gotoAndPlay(1);
myFirstMovieClip.stop();
myOtherMovieClip.play();
}

To run this function, and all of the code inside of it, we can simply call the function by name rather than having to recopy or reiterate the same code over and over:

goSomeplace();

Functions make it possible to easily reuse code by packaging it inside a tidy, named bundle that can be called easily at any time. Event handlers are functions just like this, except they are specially slated to respond to events, or behavior that can trigger other events (ie. mouse clicks).

To return or not to return?
Generally, functions can be broken down into two categories: Functions that do something, and functions that return something. A function that does something for example, can navigate the timeline, set a value or change the appearance of something on the stage. A function that returns something, or instance, can total two numbers and return the sum as a finished value. An example of a ‘doer’ vs. a ‘giver’ is shown below:

Does something (and nothing more):

function goSomeplace() {
gotoAndPlay(1);
}

Returns something back:

function addNumbers(firstNumber, secondNumber):Number {
return firstNumber + secondNumber;
}

Since functions can often be thought of as little machines, a good example of something does vs. something that returns would be the comparison between a copy machine (which gives back a copy) vs. a voting/ballot machine (which receives your vote but gives you nothing back).

So what does all this mean to you? The important thing to remember is that event handlers are functions that do, but never return anything. They can perform any number of actions in response to an event, but will never return a product, such as a sum, a value, or a piece of data.

Creating an Event Handler
Let’s move ahead and write our first event handler. To follow along, click here to download the sample files.

Select the first keyframe of the ‘Actions’ layer, and open the Actions panel (Window > Actions, Opt+F9 on MAC, F9 on Windows, or double-click with the Opt/Alt key down). Make sure Script Assist is disabled (upper right hand corner button).
Type in the following to set up the framework for your new function/event handler:

function playMessage() {

}

This creates an empty function called playMessage, and leaves us some room to add scripts in between that will give it functionality. Next, add the following code in between the curly brackets:

function playMessage() {
gotoAndStop(10);
myMC.play();
}

The new code, when run, will tell the current timeline to go to frame 10 and stop, and instructs a movie clip with the instance name “myMC” to play.

Now, in order to have this respond to events, we need to add a couple of things to complete this function and make it a true event handler. First, as mentioned earlier, event handlers never return anything – they only do something. For this reason, we must explicitly tell ActionScript that our new function returns nothing, by adding the following right after the function name:

function playMessage():void {
gotoAndStop(10);
myMC.play();
}

The :void statement tells ActionScript that the function returns nothing at all. Other functions, however, may be created to return something, in which case :void could be replaced with the type of info beings returned (ie. :Number, or :String). Event handlers, however, always will display that :void statement.

Next, we need to let the new function know to expect some incoming information. Functions can be designed to accept parameters, or additional information that helps it do its job. This coud be two numbers to add, a list of names, or a message to display on the stage.

Event handlers, however, can only receive one piece of information (parameter) – which is the summary of the event itself. This summary contains information about where the event occurred, what object fired it off, and more. In the parentheses after the function name, we add a placeholder for that information as follows:

function playMessage(event:Event):void {
gotoAndStop(10);
myMC.play();
}

event is an arbitrary name, as where :Event specifies the type of information that event will hold. Note: Although event highlights in the actions panel in blue, in ActionScript 3.0 it is no longer a reserved word.

Adding the event listener
An event listener is a directive to an object (ie. a button) to listen for and respond to a specific trigger event when it occurs. In addition, an event listener tells that object which function (referred to as an 'event handler') to use as its response. Since event handlers now exist as named functions (not “anonymous”), several objects in one movie can use a single event handler as its response.

First, we need to make sure the button we are adding an event listener to has an instance name, which enables us to refer to it from within ActionScript. Select the button on the stage, and via the Property inspector, use the field to give it the name of play_btn.

Return to the Actions panel (you should have it open on frame 1 of the Actions layer), and underneath the event handler you created earlier, type the following:

play_btn.addEventListener(“click”,playMessage);

Let’s take a look at what was just added. addEventListener is a function itself (often called a method) which assigns an event listener to a specific object, in this case, our button. addEventListener takes two pieces of information: first, the exact event that will trigger a response. In this case, the shorthand click is used to refer to a simple mouse click. The second piece of information tells the button to use our playMessage event handler as a response.

The complete code should look as follows:

function playMessage(event:Event):void {
gotoAndStop(10);
myMC.play();
}
play_btn.addEventListener(“click”,playMessage);

Choose Control > Test Movie to preview your movie. Clicking the button should advance you to the message at the end of the timeline, and also prompt the animation in the movieclip to play.

Navigating to web pages: The death of getURL()
You may or may not have noticed that the trusty getURL() command we used to use to open web pages and navigate to outside sites, is well…gone. Phased out of existence in favor of newer, sleeker, younger code. So if you’re a Flash designer just looking to build a menu or nav button, what do you do now? The answer lies beneath.

Building a new event handler
To script a button for page navigation follows the same approach that we’ve used so far. The internal scripting in your event handler will differ slightly, however. First, let’s create an empty function that will become our event handler. Enter the following code:

Function gotoPage(event:Event):void {

}

This sets up the framework for our event handler. Notice that we include the mandatory :void statement (which tells us that the function returns nothing) and a placeholder for the event information that will get fed to the function when it’s called (event:Event).

Now, the meat of our event handler. We need to tell it jump to a URL, so we’ll do this using two new things: URLRequest and navigateToURL. Let’s start with the new URLRequest class, which acts as a wrapper for any string that represents a URL. In previous versions of AS, there was no obvious difference between any other string (text) and a URL. So, most any function that needed a URL accepted just about anything in quotes – like so:

getURL(“http://flashthismofo.blogspot.com”);

Now, however, any string or text that represents a URL must first be wrapped inside of a new URLRequest object. You can think of this as a new, fancy packaging for a URL that distringuishes it from any other text. Every function in ActionScript that requires a URL now only accepts URLRequest objects – a plain string will produce an error. To format our URL inside of a new URLRequest object, add the following code to your event handler:

function gotoPage(event:Event):void {
var myurl:URLRequest = new URLRequest(“http://www.cre8summit.com”);
}

Notice that our URL is included inside of a new URLRequest object, which acts basically as a wrapper. Next, we’ll utilize the new navigateToURL command to have our event handler launch a browser with our URL in it. Add the following code:

function gotoPage(event:Event):void {
var myurl:URLRequest = new URLRequest(“http://www.cre8summit.com”);
navigateToURL(myurl);
}

navigateToURL takes at least one piece of information – a URLRequest object with a valid URL in it. We simply feed it our myurl URLRequest object that we created on the line above.
navigateToURL directly replaces getURL from previous versions of ActionScript. The biggest different to note, of course, is its use of a URLRequest object, versus a standard string to specify the URL. Like getURL, you can also specify a target where the new URL can be loaded. To have it launch the URL in a new browser window, add the following parameter to navigateToURL:

function gotoPage(event:Event):void {
var myurl:URLRequest = new URLRequest("http://www.cre8summit.com");
navigateToURL(myurl,"_blank");
}

The completed code should get you up and running. Feel free to modify this code and place it in your projects. Like anything new, this may seem a bit foggy at first – but don't worry, it'll clear up in time. For now, do what most of us do and utilize this code as a template to get up and running while you figure out the nuts and bolts behind it.

Understanding 9-Slice Scaling

2007-12-16T11:27:00.000-08:00

Scalability is always an issue for the interactive designer - whether it's creating buttons, backdrops, word balloons, content frames or otherwise, certain things (ie. rounded corners) seem to go to hell in a handbasket when it comes to free transformation or dynamic scaling (ie. via ActionScript). The addition of the 9-slice scaling option in Illustrator, Flash and Fireworks overcomes this by allowing you to set scaling restrictions for an object via a set of 2 vertical and 2 horizontal guides that form a 'tic-tac-toe' style division. Let's take an example of a word balloon backdrop:

On the left, the word balloon looks good at its original scale and size. On the right, however, you see what happens when the poor guy gets scaled down and disproportionally. The corner radius looks way off, and the stem shrinks down (which you may not want). Enter 9-slice scaling. When you convert an item to a symbol in a Flash document, the expanded Convert To Symbol options (Advanced) allow you to check off a discrete box marked Enable guides for 9-Slice Scaling:

Double-click the symbol in the Library or on the stage to edit it; you'll notice the appearance of 2 sets of guides (horizontal and vertical) that divide the image into a tic-tac-toe grid (hence, 9 slice). The idea is to move these guides to divide the image up into a 4-corner, 4-side and 1-center set of areas - the corners you create will remain fixed during any scaling performed on the image - the sides will only scale respective to the direction they flow ...the left and right side will only scale vertically, and the top and bottom will only scale horizontally. The center becomes fair game, and will scale normally. Here, i've divided up the balloon on the Flash stage so the corners and the stem at the lower left corner remain fixed:
The results will now be vastly different when the word balloon is scaled on the stage..as shown in the example below:

The corners and their radius and stem remains perfectly uniform, while the image itself sizes much cleaner and can now be re-used for any purpose!

Note: This option is available in Fireworks and Illustrator CS3 alike. When creating symbols in Illustrator, you can specify this option, which will in turn carry over if imported into Flash. Rawk!

Flash*This*Mofo

Using the Ternary Operator in ActionScript 3.0

Putting a Face on ActionScript 3.0 Interfaces

ACEing the ACE: Is it possible?

Getting Buttons to Work in ActionScript 3.0

Understanding 9-Slice Scaling

FlashThisMofo