Posts Tagged ‘AS3’

As a developer we are habitual to use commonly used approach in programming. There are several alternate and optimized way are also available and we need to give a chance to them as well. ActionScript 3 introduced various operators for specifying how to combine, compare, or modify the values of an expression. From these operators we used only few common operators. There are several rarely used operator are in list that may provide an alternate and optimized way of programming.

There is an operator named logical OR assignment (||=) , this is not in a frequently use. The use of ||= operator is it assigns expression1 the value of expression1 || expression2. First see the traditional approach with the use of conventional operator. See the below example.

Using If condition

Using logical OR assignment operator (||=) we can optimize this.

Using logical OR assignment (||=) operator

In the above example you can see that the complete logical IF statement is shrink into one single line. This operator work like if object is initialized then use the same otherwise assign the newly created object. Enjoy! and give a chance for this operator in your programming.

ActionScript 3 is an Object Oriented Programming language, and here access modifiers are used for handling declaration visibility. The common access modifiers in Object Oriented Programming are Public, Private and Protected, apart from this in AS3 new access modifier namespace is introduced. This is used when we want more control over who can access class items. A namespace is a context in which names are unique. There are three steps to gaining and sharing special access to items with namespaces. First, declare a new namespace. Second, determine what items belong in that namespace. For those items, use the namespace’s name as a visibility modifier instead of public, private, protected, or internal. Third, in code that needs special access to the namespaced item, open the namespace that we have created.

Flex framework is a very good example of using namespace. In Flex framework for handling internal data they used mx_internal namespace. There are so many variables are marked as mx_internal, these variables are available for developer whenever they use mx_internal namespace. As per Adobe mx_internal is a namespace used by the Flex framework to partition out functions and properties that may change in future releases of the Flex SDK. So before using mx_internal think closely on how to avoid using this, because mx_internal mark property which you are accessing will change in next release of framework. Although this is a very good feature by framework to exposing there internal function to developer, but this is advisable to use this as a reference only not for solving any requirement. In this post I am going to describe this risk area of using mx_internal.

I have simple usecase where I am using “mx:NumericStepper” component. As per requirement we need to provide a checkbox for controlling enable and disable of text input controls of “NumericStepper” component.

Editable Disable

There are no direct property are exposed for end user devleoper for taking a reference of text input controls of “NumericStepper”. In this case we use mx_internal for taking reference of text input. See the code below for reference.

Taking a reference of inputField using mx_internal This implementation will work fine if we not upgrading the flex framework for this application. As per Adobe’s clear statement this is an internal property and may be change in future release for framework version. So we can’t say this implementation will workable always. If you see the below code we are able to access the inputField properties using mx_internal, as this inputField properties is there in <mx> framework based NumericStepper component.

inputField are accessiable in <mx> based frework

But when we upgraded our framework and started using spark component then this properties is not more available and our implementation will go wrong. 

inputField is not available in spark controls

Although “mx_internal” may solve many problem but please take this as a reference and be aware that properties or functions defined under mx_internal may change in future versions of SDK.