Monthly Archives: January 2008

Access FlashVars parameters with AS3

Posted on by
14

Many people use FlashVars as a way to send parameters to the flash movie playing in the browser. This way the parameters are imported as root level variables.

Using ActionScript 1 and 2 these variables can be accessed easily from the root level, like this: _root.parameterName. So, if you would send two parameters and their values (xmlFile=setup.xml&imageFile=picture.jpg) to the flash movie, you would access their values like this:

trace(“the xml file is: “+_root.xmlFile);
trace(“the image file is: “+_root.imageFile);

This changes when it comes to ActionScript 3. You cannot access _root.xmlFile or _root.imageFile, simply because these variables do not exist on the root level. They haven’t been declared so the compiler throws an error. The new way to access the FlashVars parameters using ActionScript 3 is to use the LoaderInfo class. Every DisplayObject contains a property called loaderInfo which is an instance of the LoaderInfo class. An object of this class contains a property called parameters. This is an object that enumerates the list of FlashVars parameters and their values. You would access these parameters like this:

var paramList:Object = this.root.loaderInfo.parameters;
trace(“the xml file is: “+paramList["xmlFile"]); // you could also use paramList.xmlFile
trace(“the image file is: “+paramList["imageFile"]); // and paramList.imageFile

Get Flash player version with AS3

Posted on by
6

Recently I’ve posted on jumpeyecomponents’ Knowledge base an item, for the TxEff component, that shows you how to detect the version of the current Flash player, using ActionScript 3 code.

The only difference between AS2 and AS3 in this case is the method to get the Flash player’s version. AS2 has the getVersion() method. In AS3, there is the flash.system.Capabilities class which has a property called version. In both cases you’ll get a String representing the platform on which Flash player runs and the version. The result looks like this: “WIN 9,0,115,0″ (for the 9.0.115 Flash player on Windows).

What does this String mean ? Well, the first letters are the platform on which Flash player runs. This could be “WIN”, for Windows, “MAC” for Mac OS and “UNIX” for Unix based operating systems. Then comes the actual version number of the player. The first number represents the major version number. Next comes the minor version number. Third is the build number and the last one is the internal build number.

The next code snippet, separates the version String into the corresponding parts and displays them:

import flash.system.Capabilities;

// Get the player’s version by using the flash.system.Capabilities class.
var versionNumber:String = Capabilities.version;
trace(“versionNumber: “+versionNumber);

// The version number is a list of items divided by “,”
var versionArray:Array = versionNumber.split(“,”);
var length:Number = versionArray.length;

// The main version contains the OS type too so we split it in two
// and we’ll have the OS type and the major version number separately.
var platformAndVersion:Array = versionArray[0].split(” “);

var majorVersion:Number = parseInt(platformAndVersion[1]);
var minorVersion:Number = parseInt(versionArray[1]);
var buildNumber:Number = parseInt(versionArray[2]);

trace(“Platform: “+platformAndVersion[0]);
trace(“Major version: “+majorVersion);
trace(“Minor version: “+minorVersion);
trace(“Build number: “+buildNumber);

Bee Organized

Posted on by
Reply

Have you ever got in a situation when you needed to review some application or a piece of code you wrote several month ago ? And once you open the file, the code looks like a bunch of random characters rather than a sequence of lines of code that can actually drive an application ? I bet there are plenty of those who had to rethink a part of their application, to remember what that part of code should do and then try to rebuild it. All this, because the code is intelligible and there are no comments to give you a hint on what you were trying to do. That was the moment when you said to yourself: Enough !!! From now on I gotta be more organized, more careful with the code I write… Yes… I bet there are plenty of those who thought that… And I bet there are plenty of those who couldn’t keep their promise of being more organized…

Respect your work and you will respect yourself. Respect yourself and others will respect you… (quite a Zen moment :D )

There are plenty of articles on the web about how to organize your work and how to organize your code. However, I feel this will always be a subject worth reading about. Especially by those who just started coding or by those who feel they are not organized enough. Having been through this, myself, I’ve decided to give some advice to those who need one. Maybe this article could help others…

Organize your code

With OOP (Object Oriented Programming) is a lot easier to organize the projects. The application could be considered a sum of objects that interact with each other. These objects are instances of classes that model similar entities or behavior. Further more, similar classes can be organized into a package. This way you will always know a package what type of classes could contain so even if you don’t know the name of the class, at least you know where to look for it. Once you find your class, you could easily find certain properties or methods that you need.

Also, the flash animations you create could contain quite a lot of code on the time line. It is a good practice to have all your code, when possible, written into the same place: a single frame or even an external .as file. The code shouldn’t be written inside the objects on the stage, try to put the entire code of the frame in one place so you can easily find it.

There are a few articles on the web on how to write ActionScript code, especially for AS2. You could spare some time to read Jen deHaan’s article on ActionScript 2.0 Best practices or Simon Wacker’s article about the methods in ActionScript 2.0. Simon Wacker gives us a great insight about how to correctly write methods and how to write JavaDoc-like comments for them.

Comment your code

If, by any chance, after a few months you’ll need to look over your code to improve it, reuse it or just reapply the algorithm you used and you didn’t write any notes on why and how did you write the code the way you did it, then you’ll spend enough time contemplating on that piece of code, wasting valuable time of your current project. You won’t be able to deliver your part of the work on time. You’ll have to spend extra time at work to try to finish it on time. If you won’t be able to deliver on time, maybe other parts of the project that depend on your part will be delivered late, which in the worst case spells as disaster for you, your team or even the entire company. At the best, you’ll get a bad review from your project manager or team leader (that’s not so good either). All this, because you couldn’t or wouldn’t take the time (just a few minutes) to write down a few notes on the algorithm that you just used.

If you need to write a lot of code, this could mean a lot of notes and, of course, increase the time you spend on your part of the project. However, I believe this to be a necessary evil (I’m talking about the increased production time not about the use of notes or comments). Project managers and programmers should take this into consideration when planning their work, because this could turn out to be a “life saver” in the near or far future. So, my advice to you is comment your code: describe everything you code or you believe it might be important to you or others who could have access to your piece of code. Describe the entire class you are creating, every parameter (or at least every parameter that has a more cryptic name), every method you write for your class, describe each parameter passed to that method and what that method would return. Also, you can write comments inside your methods, explain why or how did you use a certain algorithm. This could turn out to be a real time saver when you or another teammate need to reuse a piece of that code (which isn’t quite easy to understand) into another project you work on.

Discipline, discipline, discipline…

I know it’s easy to tell people how to organize their work or to read about it. But, by far, the greatest challenge is to actually keep yourself organized. For someone who wrote code in a chaotic way for quite a lot of time it will be very hard to change his/her habits. And trust me, this won’t happen over night. This requires a lot of discipline. Discipline to say no, when tempted to write the code very fast and without respecting any rules, just to have it done quickly. Discipline to write your code according to the rules you set. But, again, trust me when I say that after a while, you will see the benefits of this and you’ll be able to keep yourself organized without even thinking about that. This will a be habit that you’ll like to keep.

blist – just like blog

Posted on by
Reply

In December I came upon an interesting article on zdnet.com about a new database/spreadsheet web application. I think the screenshots made me read this article than the title itself (very well designed and clean interface). So I read the article and immediately this blist got my attention. I accessed their web page and found out they were still working on their product but I could still subscribe to their list of people who will get the beta version. Afterwards I started reading the company’s blog. I couldn’t get my eyes off it. Kevin Merrit wrote (the company’s founder) very interesting articles about his experience in the IT world, advices for startup companies and insights of his company and the product they are working on.

I’m really interested to see how the final product will look like and how it will work. I can hardly wait to test it (he’s been promoting blist intensively and Kevin has the ability to get people interested in his work). So if you have a little spare time I recommend you to read blist’s blog.