We have been getting a lot of contact from users confused about the new Local File Security Sandbox in Flash Player 8.
Understandably, they tend not to be pleased that hosted SWFs can no longer load data from the clients’lLocal system. My thought is that his is a good thing. It reduces the likely hood a that someone intended on identity theft or just spamming you to no end, would be able to read a file they happen to know the path to on the client machine and send its contents to a server over the internet without the user being aware of it.
Many users new to ActionScript have often asked me, â€œHow do you learn to code?â€? They sulk when I tell them that I have a background in programming and have actually written programs in several languages.
They proceed to convince me that they have done their homework and tired to read the documentation but can rarely figure out how to do the things they need to. They have spent hard earned money on two or three programming books that take them a day or two to find the time to read and when they crack open the cover they quickly discover such material works really well as a sleeping pill. The same can be said for instructor lead classes and even some of the online tutorials.
Feed up with painstakingly searching the internet for canned solutions, and even expensive 3 rd party software they begrudgingly use on their projects with most results leading to the usual frustration of getting things to â€œalmost workâ€? they long for the day when the secrets of coding would be revealed to them.
If this sounds like you at all then don’t loose heart. I have a little practical advice.
Here I hope we can collect some of the most basic and useful tips you can use to make sure you can build successful easy to maintain Flash applications!
You are welcome to offer your opinions, pros and cons of every approach. Just remember this is not right or wrong way to code. There is only that which is more or less likely to cause you unwanted late nights of debugging.
Well I suppose we can start with a quick introduction.
I am the Flash Support Team Lead and the team’s Subject Matter Expert on Flash ActionScript and Application Architecture.
I have been working for Macromedia for a little over two years and decided to create my first Blog to help me keep a closer pulse on the Flash Community.
I hope you find it helpful and I hope you can help me to make each release of Flash the best release ever!
Welcome to my Blog!
While I know it can be difficult; I have always found it best to recommend that programs can and should be written without the use of global variables and without targeting _root. While both techniques are valid and do have their place, the convenience of using them tends to encourage programmers not to place their code in a centralized location or to be smart about their use of memory.
In the case of globals, developers get the convenience of not having to remember the path to their objects or variables and thus can use them freely. This can make it very difficult to debug your code when something goes wrong. Several functions reading and writing from a global variable can often lead to an unexpected overwrites of data in your variable and it can be a nightmare trying to track down exactly the sequence of events that cause the problem.
Furthermore I canâ€™t begin to tell you the number of support cases we get where a user has of created fairly large data structure stored in global objects or arrays not realizing that to make anything global is to disable the automatic garbage collection (of that object or variable) the player does to keep memory being used efficiently. After a few seconds you can literally see the usage of RAM building on the system followed by a dramatic performance drop because the explicit â€œdeleteâ€? statement was not ever used to free up the memory of the objects that were no longer needed.
Use of _root tends to encourage programmers to scatter code in various child movie clips and on handler events. This can make tracking down a problem just as difficult as when you use globals. Also, at some point there tends to be some reason that SWF must be loaded into another. Storing data in _root means you increase the chance of overwriting data stored in the root movie or creating variables in the root that do not get removed when the child SWF has been unloaded or replaced. This leads to a reduction in the available memory in much the same way overuse of global variables does.
So what should you do? Well just avoid the use of global variables and _root. You can always store you data in a specific movie clips (or on the frames of the main timeline) and you can always use relative paths to target those movie clips or whichever timeline contains the code you need to target. Forcing yourself to follow these rules will help you get better and understanding scope and will encourage you to think about structuring your application before you write it. This will help you to keep your code a bit more organized, and eventually will lead to less bugs. Over all it will make it much easer to troubleshoot bugs when you get them.
Questions, comments, let me know.