Archives for posts with tag: actionscript
« Older Entries

Public, Private, Protected and Internal

March 5, 11 //
View Comments

Public

Your constructor has to be public in Actionscript 3.0

package {
     public class MyClass extends MovieClip
          public function MyClass():void
          {
          // your code here
          }
}

When sending a message DOWN the display list (say, from stage to a MovieClip to a MovieClip nested inside a MovieClip) making a method public allows you to use that method from the stage or the parent MovieClip.

package {
     public class MyClass extends MovieClip
          public function MyClass():void
          {
          // your code here
          }

          public function start():void
          {
          // start this instance from a parent MovieClip or the stage
          }
}

Private

Most of the time, when you’re not sure what to do, you can just make your methods and properties private and you will be doing the right thing.

Think of it like this…a car has many properties. Something like a steering wheel might be public because the user needs to access the steering wheel. But the user doesn’t need to know about how the engine works in order to be able to drive the car…so the engine can be private.

Protected

Using the protected access modifier comes in when dealing with inheritance. If you have a base class (say, a class called Animal) and you have a variable or method that you want to be available in the subclass (say, the property eyeballs or the method run). Making these properties or methods protected will make them available in the subclasses Cat or Dog.

If you use private this won’t work at all…so if you’re having problems accessing things in your subclasses make sure to change them from private to protected.

Internal

The only time I have seen the access modifier internal used is when writing singletons. Otherwise I know of no real-world use of internal. You can write tons of things in Actionscript without using internal at all…

Methods and Event Bubbling

March 4, 11 //
View Comments

So after a few years of using events, here is my current system:

When sending messages DOWNWARDS, use public methods

If I have say, a MovieClip or my Sprite on my main timeline (many times this is your Document class) and I want to send it a message, I write a public function (method) on the Class file of my MovieClip or Sprite, for example:

public function sendMessageToMySprite(message:String):void
{
     __giveMeMyMessage = message;
}

The downside with this is that public methods are not the most loosely coupled, but as long as you keep variables private in the MovieClip or Sprite, this seems to work okay. This is just how I do it.

Now, say I have a MovieClip on my main timeline, and inside of that MovieClip is another MovieClip. Then I just write a public method in my grand-child MovieClip and use dot-notation to get to it:

my-MovieClip-Child-instance.my-MovieClip-GrandChild-instance.doMyPublicMethod();

Again, there are other ways to do this (AS Signals, NResponder, Central Event Management) but for a smaller project, this seems to work.

When sending messages UPWARDS, dispatch Events

Here is what I do when I want to send messages from my grand-child MovieClip or Sprite, up to my child Sprite, up to the stage – I dispatch events.

dispatchEvent(new CustomEvent(CustomEvent));

Then I use bubbling if I want it to go further than 1 level. For example, if I want the message to go from my grand-child or great-grand-child all the way to the stage, I create an event where bubbling is set to TRUE

package
{
import flash.events.Event;
public class CustomEventThatBubbles extends Event
{

	public static const EVENT_NAME:String = "customEvent";

	public function CustomEventThatBubbles(type:String, bubbles:Boolean=true, cancelable:Boolean=false)
	{
		super(type, bubbles, cancelable);
	}

	override public function clone():Event
	{
		return new CustomEventThatBubbles(type, bubbles, cancelable);
	}
}
}

And in my Document Class (or Main Class), I write

stage.addEventListener(CustomEventThatBubbles, doSomethingNowThatIKnow)

When sending from an instance that’s not on the display list, use a Display Object to dispatch

This might be another “lazy” but it seems to work. If you have a class that doesn’t extend Sprite or MovieClip and isn’t added to the display list via addChild, just pass in the nearest display object through the constructor or other public method

public class MyNonDisplayObject(mc:MyMovieClip):void
{
     _mc = mc;
     _mc.dispatchEvent(new MyCustomEvent(MyCustomEvent));
}

You can also try creating a sprite in your non-display list class, but this seems to defeat the purpose of having a class that does not extend Sprite or MovieClip.

Instances in Flash

March 2, 11 //
View Comments

So now that I’ve been teaching Flash for a few months, I’ve noticed something about the most recent version of Flash that’s totally confusing for a beginner and I’ve had to sort it out more than once:

In the picture above, Instance of means that the above item is an instance (a concrete version of) the class called Example.

The instance name is not Example! Really, Adobe should just take out the words Instance of . No one sees the word “of” – they just see the word “Instance”.

The instance name actually goes where it says Instance Name.

The next equally stupid thing is the button beside where you can enter the Instance Name:

Clicking on the Actionscript panel button will take you to an Actionscript panel where you aren’t allowed to enter any code!

The ? operator

March 2, 11 //
View Comments

Sometimes you want to write:

if (someBoolean == true)
{
 // do this thing
} else
{
// do this other thing
}

But you can also write

someBoolean ? // do this if true : // do this if false
« Older Entries