What happened to _global, cost physician _root, _level?

I rarely used _root or _level just because some projects would end up getting loaded into other swfs. Sometimes I didn’t know this until halfway through or in the end. So I started using global instead. That way I could still target the main timeline, which is where I would try to keep all my code, without having to worry about root moving somewhere else later. When I built components I would also use global, from time to time, to target them from anywhere in the application being developed.

The best workaround I have come across on the web for storing global variables, is to create a class object and throw all your variables in there. Some great information about this can be found here: http://www.uza.lt/codex/as3-global-object/

A brief simple example is something like this:

package {
public class global{
public static var Vars:Object = new Object();
public static var Arrs:Object = new Object();
public static var _locked:Boolean;
 
public function global(){
 
}
}
}


Notes: If you want to store dynamic variables (ones that are not predefined in the global Class) then you will need to send them to the Object Vars or Arrs (global.Vars.newVariable = “yo!”). Adding and updating arrays can be a little tricky, but I will write a lot more about this in the future. I am working on a watch/listener Class for AS3 that uses some of this functionality.

Like I mentioned earlier, it works great for variables, but not so much for global functions, which is what I used global for the most.


So Let the Griping Begin:

I know it is 3:00 am and you have deadlines. Now is not the time to re-think how to build your application. What in the world was Adobe thinking with AS3 anyway. Flash is a designers/animators tool to build pretty applications right? How in the world do they expect designers to learn this stuff. It took years to get the hang of AS2, now it feels like they have pulled the rug out from underneath us. Plus, now that programmers are the only ones able to program in Flash, expect a bunch of new Flash sites full of ugly stuff that moves.

Before I get too carried away, we should realize things aren’t so bad. Actually they are pretty good.


The Real Answer : Events

AS3 is much more of an Object Oriented Programming(OOP)d language then AS2. We can work around that fact, or we can embrace it. In an OOP mindset, we have to think of our project as made from objects (duh) that are children or siblings of other objects and communicate with each other using events. The new event and child systems are really powerful, it just takes a little getting used to.

When we have multiple objects that need to pass information to a central location, and parent or stage do not work the way _global did, here’s what you do.

Use a Dispatch Event and write a custom event for your application. The cool thing about using events is they can act like _global events used too, but even better. You can call them from anywhere in you app, and you can listen and handle them almost anywhere you need to. This will open lots of doors in the way you can program your apps.

Lego Blocks


Think legos:

So let’s look at our object model. Like legos or blocks, some pieces have special functionality. like the window or door frame. These pieces are special and will function the same no matter what kind of crazy contraption we build with them.

I want to add some smart home functionality to my door and window. When I close the door, I want the window to close as well. Then when I wake-up and open my window, I want the door to open, to let all that beautiful air and scenery in, because this Lego home will be built in hawaii. Cool!

To show off the global variable class, I will add a locking variable that I can check from both the window and door. Not sure if you need locks in Hawaii, but you sure do where I come from.

package {
import flash.events.Event;
 
public class globalEvent extends Event{
public static var OPEN:String = "Open";
public static var CLOSE:String = "Close";
public static var UNLOCK:String = "Unlock";
public static var LOCK:String = "Lock";
public var targ:Object;
public function globalEvent(type:String, targ:Object, bubbles:Boolean = true, cancelable:Boolean = false){
super(type,bubbles,cancelable);
this.targ = targ;
}
}
}


Events:

So let’s put this into practice.

Custom events can have as many arguments as you want and are a very powerful way to communicate to other objects in your application.

One of the arguments in dispatch event is bubbles. Goofy name, but makes sense. This argument tells the dispatcher how far we want this shout-out (or bubble up) to be heard. We can keep it private, within our class or all the way to the root or stage (now we are talking _global baby!). Remember, Events can bubble up, not side to side. I can listen for an event at the container of the object dispatching the event, but not from another sibling or its children.

Event Bubbles Property


Better then _global:

In our Event we need to know when something is being opened and closed. So we will add OPEN and CLOSE as our public static vars. When the event is called, it will get dispatched to the super Event class, and we will be able to listen for OPEN and CLOSED events and build handlers to act accordingly. We can add listeners to the container (and above) for our window and door.

The way I used _global in AS2 for something like a navigation system, was to wait for a button press, loop through all the buttons, turning things on and off (rollovers and on-states) and other code. But, what would be even cooler, is if we could listen listen for our events from the siblings. All I have to do is target the listener to the parent of the object, like parent.addEventListener(). Wow!, no more looping through objects. Each object can listen for the event and act accordingly. My movie-clips just got smarter.

package {
import flash.display.Sprite;
import flash.display.MovieClip;
import flash.events.Event;
import flash.events.MouseEvent;
import global;
 
public class legoClip extends MovieClip{
public var Status:String = "Close";
public function legoClip(){
stop();
init();
}
function init(){
this.addEventListener(MouseEvent.MOUSE_UP,mouseup);
parent.addEventListener(globalEvent.OPEN, getClicked);
parent.addEventListener(globalEvent.CLOSE, getClicked);
}
function mouseup(ev:MouseEvent):void{
 
if(Status == "Close"){
if(!global._locked){
dispatchEvent(new globalEvent(globalEvent.OPEN,this));
gotoAndPlay("clipOpen");
Status = "Open";
}
}
else{
dispatchEvent(new globalEvent(globalEvent.CLOSE,this));
gotoAndPlay("clipClose");
Status = "Close";
}
}
function getClicked(e:globalEvent):void{
if(e.target != this){
//trace(e.target.name + " / " + e.type + " / " + this.name);
if(e.type == "Close"){
gotoAndPlay("clipClose");
Status = "Close";
}
else{
if(!global._locked){
gotoAndPlay("clipOpen");
Status = "Open";
}
}
}
}
}
}


Classes:

This app is so simple, writing class files are an overkill right? Wrong, the door and window look different, but the functionality and code to run them are exactly the same. So in this case, I only had to write the code for those two classes, once. One of the down-sides to using class files is it requires export to First Frame. And if you have a loader on the first frame, it will not show up until everything else loads. This kind of defeats the purpose of having a loader, but more about this later (I have some cool loader classes I will share). I like using class files as much as possible, for the sake of re-usability, (Code Once, Use Often, that’s my motto) plus it really is the best way you can animate and do code on a laptop without 2 monitors.


Dispatch Event:

Once everything is loaded and working using dispatch event, our event handlers need to tell out door and window to initiate their animations. The event class keeps track of the object that initiated the event, so we can easily test to see if this is the object that caused the event, if not, then it can respond.

Now we have super-smart clips that can be plugged in or out of our app, and everything will still work. Global does not look so cool any more. It kind of is easier, but not as cool. Now go and build some cool stuff!



source

The Happy Frog Illustrator Tutorial Video (HD)

Here is my first screen cast with an introduction to illustrating in Illustrator. Included are some very important tips in creating great illustrations in less time as well as an overview of the illustration process. We will create a Happy Frog character almost completely using the ellipse tool.

There are 5 rules to Illustrating in Illustrator, this Better Faster. They are mentioned in more detail here, viagra order including four reasons for cleaning up strokes in your final artwork.

1. No Strokes!
A. strokes on centered on the pixel grid, so when the stroke is rasterized, anti-aliasing causes the stroke to look fuzzy. This may not occur if your stroke weights are all even numbers, but that is limiting.

B. Strokes do not transfer to other applications perfectly. Ether because of the pixel grid or applications like Flash handle paths differently. I have exported much vector artwork to Flash only to see that half my strokes missing.

C. Strokes cut into the integrity of your shapes. Half the stroke pushes into the shape while the other half expands the shape. You can only add so much stroke to a font, before it starts losing shape fidelity.

D. Miters can creep up especially on text. Converting strokes to full shapes allows you to clean up any miters.

2. Never Draw the Same Path Twice.
When adding details we may trace over paths that were previously drawn. Illustrator provides many tools that should allow us to use existing paths which is more efficient.

3. Draw Paths, Don't Tweak.
An exception to the previous rule is when you have a line you do not like, don't tweak it, most of the time it is faster to delete and redraw it. Even if you are not that fast with the drawing tools, with practice you will get there. What better way to practice then by forcing yourself to draw more paths.

It is OK to tweak a curve here and there, that is what the handlebars are for, but not whole paths. If you use the pencil tool or brush tool, these tend to add extra nodes to paths. tweaking them can be a nightmare. Use the Pen tool for clean paths.

4. Illustrate Clean & Not Destructive.
When dividing paths, keep as many shapes intact incase you decide to edit them later. use a copy of a shape to divide from, not the original. If an edit is needed, it is easier to tweak one shape then two or more shapes or paths.

5. Use Keyboard Shortcuts & Actions Where possible.
As soon as you make new actions, save them.

UPDATE:

New video posted, fixed some typos.

Technorati Tags: , , , , , , , , , ,

Leave a Reply