This used to be one of those after-midnight rambling posts, but I've boiled it down:
Branden once expressed to me that there can be too much OOP in Flash. Real-world development is about making your user/client happy. When Branden moved the Flash community towards object orientation with ACK, his framework complemented Flash technology. Against all odds, Nigel then laid the foundations for a component model that tried to fit within Flash technology, but Macromedia made the mistake of ignoring all the lessons learned from his first attempt. Instead, Macromedia avoided correcting architectural flaws in the Flash player, resulting in the MX 2004 component framework that fights against Flash technology rather than extending it.
Recent debates with Chris and Devon have led me to several observations: Computers were not meant to create a demand for coders; computers were meant to solve problems.., it's about getting your ideas implemented sooner so you can iterate sooner. Fortunatley, Flash is like the Perl of UI; easy to write, easy to deploy. However it's also difficult to re-purpose, and difficult to maintain. Using Flash as a UI Framework or IDE will result in much pain. Love it for what it is: a kick ass design tool. Creativity is at the heart of Flash. Macromedia will hopefully seize the opportunity to re-architect the flash player one day to support maintainability as well as creativity, but in the meantime for my situation, the most correct way to use Flash is to write incorrect code. That's fine, I still feel the Flash love :)
p.s. This freaks out people who write correct code:
// fake dragging
var offset:Object;
function onPress() {
offset = {x:_x - _parent._xmouse, y:_y - _parent._ymouse}
this.onMouseMove = function() {
this._x = _parent._xmouse + offset.x;
this._y = _parent._ymouse + offset.y;
updateAfterEvent();
}
onRelease = function() {
onMouseMove = null;
onRelease = null;
}
}
Do you do a lot of live concurrent audio/video streaming and archiving on your multi-user applications? Check it out... One of our servers at work has 8Gb of RAM. A Windows Server allows up to 2Gb of RAM per process. To optimize performance, make sure your Server.xml configuration file does not have a stream cache RAM percentage exceeding 2Gb. For example, FCS installs with a default value of 40% RAM, so the server would have a cache size of 3.2Gb on an 8Gb server. A better range might be 25%, or 20% just to be safe. Thanks to Pritham for the tip!
Someone asked, so I posted the answer here as well:
In a loop, it doesn't really matter whether the increment operator "++"
comes before the variable or after the variable. However, there is a subtle
difference in other situations. If the ++ operator is before a variable,
then the expression "a + 1" is evaluated before the variable's value is
assigned. If the ++ operator is after a variable, then the express "a + 1"
is evaluated after the variable's value is assigned. Check out the example
below to see the different results of positioning the "++" operator before
and after a variable.
-----------------------------------------
a = 1;
b = ++a;
trace("a = " + a + ", b = " + b);
RESULT OUTPUT: "a = 2, b = 2"
a = 1;
b = a++;
trace("a = " + a + ", b = " + b);
RESULT OUTPUT: "a = 2, b = 1"
------------------------------------------
In the first case, the variable "b" receives the value of "a" only after the
expression "a = a + 1" has been evaluated. Thus, b = a + 1.
In the second case, the variable "b" receives the value of "a" before the
expression "a = a + 1" can be evaluated. Therefore, b = a, and then a = a +
1.
This behavior also occurs for other assignment operators, such as /= (divide by), *= (multiply by), and -- (decrement by 1).
-Sam
Local Connection kicks ass, and totally relieves the headache of fscommands in netscape, mac IE, and other broken browser platforms. I've created very short demo file which shows you how easily you can use local connections in less than 5 lines of code.
Source Code
View Demo
Macromedia Documentation
The most immediate implications are in Flash architecture, because local connections allow you to put swfs in different HTML frames (or even different browser windows!) and allow them to control each other, or share data back and forth. This approach is preferable to fscommand because it's more reliable, and requires less programming work.
You can download the zipped source code and HTML frameset pages here, or view the example here. Just export all the zipped contents, and double-click on the index.html page. Move your mouse around the left frame, and an identical drawing will appear in the right frame as well.
This tip is probably old news to some Flash programmers, but for others, it'll hopefully clarify an often misunderstood aspect of OOP. Variables actually work differently, depending on whether you're assigning a primitive data type or an object reference. The difference is subtle, but it can cause confusion when you start passing lots of data between different parts of your code.
There are two kinds of variables: a variable containing a primitive data type (number, boolean, character), or a variable reference to an object in memory (Array, String, Object, etc.). The main difference in behavior occurs during variable assignments. If you create an object and assign it to a variable, the variable only holds a reference to the object in memory, sort of like a pointer to a house on a street. If you assign the same variable to another variable, the object doesn't duplicate itself, it merely passes a reference for the same object to the other variable. Like adding another pointer to the same house on the street. However, assigning a variable containing a primitive data type to another variable will actually clone the value to a new point in memory, like building an identical house on the same street.
Here's an example:
myArray = [1,2,3,4,5];
arrayRef = myArray;
myArray[1] = "Hello";
trace(myArray);
trace(arrayRef);
Ok, so here's what's happening: First, we create an array object in memory (RAM), and set the "myArray" variable as a reference to the array object in memory. When myArray is assigned to the variable arrayRef, it actually passes a reference to the same array object in memory. The next line of code re-defines the second element in myArray with the string value of "Hello". When this element's value changes, tracing out myArray and arrayRef will both output the same value of "1,Hello,3,4,5" because both variables refer to the same array object in memory.
But consider what would happen if we applied the same operations on primitive data types instead of objects:
A = 1;
B = A;
A = 3;
Here, the variable A receives a primitive numeric value of 1. When we assign the value of A to the variable B, B doesn't receive a reference to the same value. Instead, another space in memory (or RAM) is created to hold the number 1, which is then assigned to B. Now we have two variables pointing to two numbers in memory, which is very different from the earlier example, where two variables point to the same object in memory. In the last line of code, A=3, the first slot in your RAM, which contained 1, is now assigned a number 3. When you trace out both variables,
trace(A)
trace(B)
the traceout statements will actually output "1" and "3". References vs. cloning are the main difference in how variables handle objects and primitive data types. When you're debugging, keep in mind the possibility of an object being manipulated somewhere else, with a different variable reference.