This is an early iteration of the system but I think it’s at a good point to publish. I just saw Mario Klingerman present at the FITC, and now I have a ton of new ideas to continue exploring and experimenting. If only I had some more free time.

Eventually I plan to release the code, but not until I’ve explored the possibility a little further.

For some reason, Flex Builder is not handling Bitmap Data with any sort of consistency when it is included as a class in a SWC exported from Flash. In my opinion, using SWCs to import visual content from the Flash IDE, is for the most part a fluid and excellent work flow. However, every once in a while, in seemingly inexplicable fashion, I get internal build errors.

The insanity of this is that I can’t find a pattern. It happens mainly on library objects exported as BitmapData, but not consistently. In one project for instance, I received an internal build error, and was able to whittle the problem down to one tiny BitmapData culprit in a library of about 40 like classes.

By eliminating the offending class, my Flex ActionScript Project compiles…. if I don’t, Flex blows up and I get an “internal build error.” There are annoying workarounds, like embedding the Bitmap into the ActionScript Class, but this ruins the fluidity of a work-flow between Flash and Flex.

Anyway, the whole thing throws a monkey wrench into the system, and is overwhelmingly irritating. I wish I could post a solution, but I haven’t been able to nail down the real problem. Also, there seems to be next to nothing concerning this problem on the web.

A colleague mentioned that it might have something to do with the sensitivity of the Eclipse Framework, but god only knows at this point. So, there you have it. I may be the only one wrestling with this issue, and I may never receive a comment on this post, but hopefully someone out there knows what I’m talking about and can share in my pain.

————————————

This is a simplified version of including a SWC file in a flex project… you can read the complete document at Adobe’s LiveDocs

Add an SWC file to the library path

1. With a project selected in the Flex Navigator view, select Project > Properties > Flex Build Path.
2. Click on the Library tab.
3. Select the Add SWC option
4. Enter or browse to and select the location of the SWC file, project, or folder. Click OK.The SWC file, library project, or folder is added to the library path.

Lately I’ve been using the Tween class included in the flash ActionScript 3.0 for Flash CS3 library, and I noticed some peculiar behavior with respect to the motion of the Tweens. Often, especially when the program was undergoing points of extreme activity, my tweens would not complete their motions. It was perplexing, and my first attempt to fix the bug was to simply to listen for the tween to stop

(tween.addListener(TweenEvent.MOTION_FINISH,
                   fixPosition)

, and then to force the asset to its intended end point. This worked on a simple application: Selected Works Site, but it completely failed when I tried it on one with heavy processor activity.

So, after trawling the internet in search of others experiencing the same problem, I believe I found the solution in the comments at a blog called Everything Cool. (I aslo found they talked about it on the live docs). Here I’ll explain what the problem is, how to solve it, and at the same time show you how to use the fl.transitions.Tween class in Flash CS3.

A quick tutorial on the Tween Class.
First a few points.

1. You always need to import the tween class when using tweens, even when coding on the timeline of an fla
2. Tweens can be used on almost any kind of object, unlike the transition manager which forces your target to be a MovieClip
3. The Flex framework has its own class of Tweens that work differently than the ones I’m describing here. You will need to search the web to figure out how to use these.

Ok, so I’m providing generalized code. The first 2 lines are the import statements, the 3rd is the variable declaration, and the remaining lines will be the actual tween itself, inside of a function that you can call anywhere. A tween automatically starts when it is called.

import fl.transitions.Tween;
import fl.transitions.easing.*;

var simpleMovement:Tween

private function startTween(e:MouseEvent):void{
   simpleMovement = new Tween(targetObject, "y",
 		      Strong.easeOut,
 		      targetObject.y,
 		      destinationValue,
 		      1, true);
}

You will see that the tween called “simpleMovement” takes 7 arguments. They are as follows (in order):

1. Object to be tweened
2. Value to be tweened. (Can be pretty much anything you desire… even filter values and sound volume)
3. Easing method(you must import the easing class as supplied)
4. Start value (supplied in this example as wherever the target object is currently located)
5. End Value
6. Length of tween in seconds. (a highly precise number… can use 0.3482)
7. Use seconds… either true or false.

Now the problem I was having had to do with the scope of declaring my Tween object. Out of simple cohesion, or laziness I often put my tween declarations and the instantiations in the same function.

private function startTween(e:MouseEvent):void{
   var simpleMovement:Tween = new Tween(
                      targetObject, "y",
 		      Strong.easeOut,
 		      targetObject.y,
 		      destinationValue,
 		      1, true);
}

Well therein was my problem. In ActionScript 3.0, the garbage collector runs whenever there is a high number of discarded objects in the cue. (The garbage collector deletes objects with no reference) Because my tween was declared locally, and thus a weak reference, if the application went through an episode of high activity, it was highly likely that it would be discarded by the garbage collector before it could complete.

So eureka man, all I had to do was declare my Tween globally, and thus ensure the garbage collector wouldn’t mark it for deletion.

For those into OOD/OOP, please read on… This is my attempt to make lucid some very spiraling concepts. I’m no expert, I’m a budding programmer, so as such I may be able to present these ideas with a new perception. At any rate… getting them down on paper solidifies the methods in my mind. That’s why I’m sparse on code, and big on concept. So if I get anything wrong, feel free to send evocative comments, I love the sweet vigor of a verbal joust.

Note: All OOD jargon has been italicized and colored for no good reason at all.

Summary

Getter and setter methods in ActionScript3 differ from regular methods, and resemble characteristics of objects. They do not use regular call statement form, but use dot notation (as a variable would). To use them, you simply call an instantiated object through its variable name and append the getter or setter method minus the function call operator. It’s a prety nice and succinct way to modify states of an object.

Defining The Class

Let’s assume we have a class called “humanEntity()”, and in this class we declare a private instance variable called “lbs” describing its size. Through the constructor method, we pass a parameter called “mass” without an initializer so it is required in the instantiation of the object. In the constructor we assign the value of “mass” to the class’s instance variable “lbs” with an assignment operator.

Great, now all is set to define our getter and setter methods. (These are also loosely known as mutators, accessors, modifiers and retrievers…. what a roguish set of descriptors). Good getters and setters have identical method names and are defined not as actions (as a normal method might be) but as characteristics. So instead of using “changeWeight” or “returnWeight” we would use one variable called “weight”. Through these methods, we can change and return the private variable “lbs” to a main program that uses the “humanEntity()” object. By definition, a getter method explicitly returns a value… in this case “lbs”, and a setter method alters that value. Setters automatically return values, but it is illegal to use a return statement in a setter method.

They are defined like this.

function get weight():Number{
return lbs;
}

function set weight(newLbs:Number):void{
lbs = newLbs;
}

Note that the method name is exactly the same in both. It is the keywords “get” and “set” that differentiate them.

Recap

So to recap, we have a class named “humanEntity()” with a private instance variable named “lbs”. “lbs” is assigned through the constructor method with a required parameter called “mass”. There is one getter method and one setter method, both named “weight”.

Just as an aside, you might want to create another method in this class that would set sensible default values to “mass” if someone tried to pass a value into the object that was too high or low. You would use a conditional statement of some sort. (I guess that’s for another discussion).

Instantiating the Object

Alright, so now we are using the “humanEntity()” class in our application, and we will assign the object to a variable called “conradVonDuchance”. Based on everything I have written thus far, it is instantiated into our main class (or whatever class) thusly.

private var conradVonDuchance:humanEntity
= new humanEntity(200);

The Crux

Sweet, now for the crux of this entire article.

What makes getter and setter methods so cool, is that you can now both reset and return “lbs” (the private variable) by using the method “weight”.

Here are two Examples:
Setting a dynamic style variable to the “weight” getter of our object:

var conradSize:Number = conradVonDuchance.weight;
return conradSize;

To reset “weight”:

conradVonDuchance.weight = 220;

Why this is good

At first glance this might seem like a ton of work to accomplish, but I feel it vastly improves your class’s API.

The idea of setting and returning a characteristic of an object should be as intuitive as possible, and having to call two different methods with different names and function call operators, to accomplish this is a little cumbersome and ugly. Using the methods “getWeight()” and “setWeight()”, do makes sense but do not feel streamlined and sexy.

And after all… isn’t that what programming is all about… making the most streamlined sexy block of code possible so you can appeal to the opposite (or same) sex.