Gaurav Manoj Patel

Flex :: Metadata tag - Event

2011-09-10T15:52:00.000+05:30

The [Event] metadata tag is used to define the MXML property for an event and the data type of the event object that a component dispatches.

Following is the syntax for [Event] metadata tag

[Event(name="eventName", type="package.eventType")]

name property of metadata tag specifies the name of the event only.
type property of metadata tag specifies the class that defines the event including entire package.

The [Event] metadata tag is inserted before class defination in an Action Script file or in <mx:Metadata> block ina n MXML file.

If the event is not identify using type and name property defined in [Event] metadata tag then MXML compiler generates an error.

Following is an example:

ActionScript Class

[Event(name="custom_event", type="myPackage.events")]
public class MyClass extends UIComponent
{
...
}

MXML Document

<?xml version="1.0"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml">

    <mx:Metadata>
        [Event(name="custom_event", type="myPackage.events")]
    </mx:Metadata>

    ....

</mx:Canvas>

Flex :: Metadata tag - Deprecated

2011-09-05T22:51:00.002+05:30

The [Deprecated] metadata tag marks class or class elements deprecated so that the compiler can recognize it and issue a warning when the element is used in an application.

The [Deprecated] metadata tag syntax is as follow

[Deprecated("string_describing_deprecation")]
[Deprecated(message="string_describing_deprecation")]
[Deprecated(replacement="string_specifying_replaceent")]
[Deprecated(replacement="string_specifying_replaceent", since="version_of_replacement")]

Insert the [Deprecated] metadata tag before a property, method or class definition to mark that element as deprecated.

[Deprecated(replacement="mycomponent.label")]
public function set text( val:String ):void
{
...
}

The [Event], [Effect] and [Style] metadata tag also support deprecation.
These metadata tags support the deprecatedReplacement, deprecatedSince and deprecatedMessage attributes to mark event, effect and style as deprecated.

[Event(... , deprecatedReplacement="string_specifying_replacement",
deprecatedSince="version_of_replacement" )]

Note: For a command line compiler use show-deprecation-warnings option and set it to true.

Flex :: Metadata tag - Bindable

2011-09-03T18:43:00.000+05:30

The [Bindable] metadata tag enables Flex to copy the value of source property to any destination property, when any changes are made to source property.

The [Bindable] metadata tag has following syntax:

[Bindable]
[Bindable ("eventName")]

The [Bindable ("eventName")] metadata tag register the source property with Flex and dispatches event eventName when property is changed. If eventName is omitted, Flex automatically creates an event named propertyChange so that the property can be used as the source of a data binding expression

Example:

[Bindable]
public var audioLevel:uint = 50;

[Bindable ("nameChanged")]
public function get name():String
{
   return myName;
}

public function set name( val:String ):void
{
   myName = val;
   dispatchEvent(new Event( "nameChanged" ) );
}

There are some situation where data binding does not execute automatically

When an item of dataprovider is modified.
When a sub-property of a property that have [Bindable] metadata tag is modified.
When a [Bindable] metadata tag is associated with a property that Flash player updates automatically, such as mouseY.

There are some method that helps to execute binding that do not occur as expected.

The executeBindings() method of UIComponent class helps to execute all the binding for which UIComponent is destinated.
The executeChildBindings() method of Container and Repeater classes of Flex executes all the binding for which child UIComponent of Container or Repeater class are destinated.

The executeChildBindings() method updates user interface after making changes that does not cause binding to execute.

However, it should be noted that above method should be called only when binding do not executed automatically.

Flex :: Metadata tag - Array Element Type

2011-09-02T11:46:00.000+05:30

In ActionScript language whenever we define an Array variable, we never specify data type of elements that Array will hold.

To allow Flex compiler to perform type checking on Array elements, we can use [ArrayElementType] metadata tag. This metadata tag allow us to specify data type of Array element.

The tag has following syntax:

[ArrayElementType("elementType")]

The property elementType of [ArrayElementType] metadata tag specifies the data type of Array elements, and can be one of the ActionScript data types, such as String, Number, uint, class or interface.

Incase of user defined class, fully qualified class name, including package detail is expected.

For Example:

....

<fx:Script>
<[!CDATA[
   [ArrayElementType("String"]
   public var strProp:Array;

   [ArrayElementType("myPackage.valueObject.data"]
   public var dataProp:Array;
...
]]>
</fx:Script>

....

Note: The MXML complier checks for proper usage of the Array elements only in MXML code; it does not checks Array usage in ActionScript code.

Flex Component Life Cycle

2011-08-30T14:41:00.001+05:30

A flex component life cycle can be broadly compartmentalized into three distinct stages:

Initialization
Updating
Destruction

This three stage bundles Six main phases of flex component life cycle which are

Construction
Addition
Initialization
Invalidation
Validation
Removal

Following diagram shows the association of 7 different phase to their respective lifecycle stage

Description of Life Cycle Phases

Stage 1: Initialization

Phase 1: Construction

Construction phase is very first phase of component and is triggered when component is instantiated. For an example

var myComponent:CustomComponent = new CustomComponent();

It should be noted that constructor should perform minimalist operation. Constructor should be zero argument constructors.

Phase 2: Addition

Addition phase of component is triggered when component is added to a parent component.

this.addChild( myComponent );

The process of adding component to its parent component execute large amount of code. This is the phase where life cycle of component actually gets started. In granularity addChild method is further divided in to three method addingChild, $addChild and childAdded method.

The addingchild method initialize parent and document reference for component child object. Also it performs style propagation and management for the component.

The $addChild method actually add component to the display list.

The childAdded method calls initialize method on the child.

Phase 3: Initialize

Initialize phase is triggered by childAdded method of Addition phase of component. The initialize method is future broken down into four sub-methods createChildren, childrenCreated, initializeAccessibility and initializationComplete. When initialize method of the component is called first FlextEvent.PREINITIALIZE event is dispatch first and then createChildren method is called.

The createChildren method is responsible for create any extended component and then adding that child component.

The childrenCreated method is responsible for enabling first Invalidate-Validate cycle of flex component life cycle.

The initializeAccessibility method is responsible to configure the component to use flash player accessibility system.

The initializationComplete method is responsible for dispatching FlexEvent.INITIALIZED event. This method marks end of Stage 1 of Flex Component Life cycle.

Stage 2: Updating

Phase 4: Invalidation

Invalidation is the first phase of flex component life cycle that gets repeated throughout the life of the component. Invalidation phase consist of three method invalidateProperties, invalidateSize and invalidateDisplayList

The invalidateProperties method is called whenever component property is changed and that require before component to re-measure and laid out.

The invalidateSize method is called whenever some action i.e. changes in property or user action which requires the components to re-calculate its size and its children’s size.

The invalidateDisplayList method is called whenever some changes that requires component display list to be updated.

Phase 5: Validation

Validation phase consost of four methods commitProperties, measure, layoutChrome and updateDisplayList. All this method of validate phase are executed in predefined order which is

commitProperties

measure

layoutchrome

updateDisplayList

Each of the invalidate phase method correspond to validate phase method

invalidateProperties ---> commitProperties

invalidatesize ---> measure

invalidateDisplayList ---> updateDisplayList

Thus whenever invalidate method is called LayoutManager of Flex Application keeps track of which invalidate method is called and only calls corresponding validate method during validate phase.

The fourth method of validate phase is layoutChrome, this method is responsible for creating border or padding around children content.

Thus once validate cycle of component is executed LayoutManager will make component dispatch Event.UPDATE_COMPLETE event.

Note: The Invalidate - Validate cycle of component repeat itself as an when any changes are made to the component and component is not removed from its parent.

Stage 3: Destruction

Phase 6: Removal

The last phase of a component life-cycle is removal phase. This phase is triggered when the component is no longer parented i.e., when removeChild() method is called on the parent component, passing in the component to remove as a reference.

When removeChild() method is called on parent component then three methods are fired, removingChild(), $removeChild() and childRemoved().

The removingChild() method does not perform any operation, this method can be overridden to execute tasks/operation that needs to be perform before component is removed from display stack

The $removeChild() method is actually a Flash Player level method that removes component from display stack.

The childRemoved() method removes references of component form its parents and document properties.

Once reference from component's parent is removed component can be re-parented or are available for garbage collection. Also removal of parent refrence of compoenent prevent component fromm entering the Invalidate-Validate cycle.

Difference between Pure MVC Multicore vs Singlecore / Standard

2011-08-17T22:50:00.000+05:30

Recently during interview, my interviewer asks me question "What is difference between Pure MVC Multicore vs SingleCore?" and I was not able to answer even after working on the framework for past 2 years. So after interview got over I set down to find the answer for the question and here are what I found.

The Standard version of Pure MVC use Singletons to provide access to framework core actors (Façade, Model, View and Controller). Access to all the actors is through standard getInstance method. Where as in Multicore version of Pure MVC, Multitons is use to allow multiple instances of framework actors. The access to the various core actors within the framework is provided by passing a unique instance key to the getInstance method. This implies that multiple instances of the core actors may co-exist without interfering with each other.

The Multicore variation supports modular programming allowing the use of independent program modules each with their own independent Singlecore Pure MVC.

For detail description on same topic please visit following link:
http://lowpitch.com/blog/puremvc-multicore-vs-standard-singlecore/

@Embed directive in Flex

2010-12-30T22:29:00.001+05:30

@Embed directive causes flex compiler to trasncode and include images (JPG, PNG, GIF) in SWF file at compile time.
Use of this technique has following advantages

Images are loaded at the start of the application, so that user doesn't have to wait for images to get loaded before displaying when it is needed.
This technique is highly recommendate for offline application where appropriate images are included in SWF file and which will be displayed when needed instead of accessing Server for getting images

Use of this technique has one major disadvantage

@Embed directive increase size of SWF file.

This technique is classical example of trade-off between file size and user experience. Wisely evelaue this techniue before using it.

Adapter Pattern

2010-06-29T23:54:00.000+05:30

In computer programming, adapter/wrapper pattern is a design pattern that translates one interface or class into compatible interface. This pattern enables incompatible classes to work together by providing compatible interface of original class to its client, i.e. this pattern translate calls made by client to interface into a calls to the original class/interface. The adapter class is also responsible for converting data responded by original class/interface to be converted into form easily understandable by client. For example if interface evaluates a call into a Boolean which client expected it to be integer 1/0 then it is responsibility of adapter class to evaluate a call response into format that is understandable by client class.

There are two types of adapter pattern:

Object Adapter pattern: In this pattern, adapter class contain object of class it wraps, i.e., adapter class redirect calls from client class to the wrapped class.
It uses Composition method for adapting Adaptee and this adaption can be extended to sub-class of Adaptee
Object Adapter class delegates execution of behaviour to Adaptee class
Class Adapter pattern: In this pattern, multiple inheritance is used to address the issue. Interface of existing implementation as well as interface of expected implementation is inherited by the adapter class so that it behaves as an expected implementation. This type of implementation is used in situation where existing implementation provide some or all of the services expected but does not use expected interfaces.
It uses Inheritance method for adapting Adaptee hence Adapter class doesn't requires to reimplement entire Adaptee class, but only needs to override the behaviour of Adaptee class that varies.

Flow of control in Adapter pattern

Client makes an request to Adapter class by invoking its method using Target interface.
Adapter object translate this request into single or series of method call to Adaptee object.
Client receive back the response, without knowing that translation is done by Adapter.

Object Adapter Pattern

Class Adapter Pattern

Note: Adapter pattern is never implemented when designing a new system but with the changing requirements we have deferring interfaces then adapter comes into picture.

Object Pool Pattern

2010-06-21T20:52:00.001+05:30

Performance can be sometimes the key issue during the software development and the object creation (class instantiation) is a costly step. While the Prototype pattern helps in improving the performance by cloning the objects, the Object Pool pattern offers a mechanism to reuse objects that are expensive to create.

The Object Pool pattern offers mechanism to reuse/recycle objects that are expensive to create or are no longer need.

Object pool pattern is advisable to use in a situation where several client may need the same stateless object which is expensive to create.

Benefits of using Object Pool pattern are:

Pattern can improve performance of application as it help in reducing time for creation of expensive object.
Pattern helps in sharing unused object between multiple clients thereby improving memory usage and can result I overall reduction in memory footprint of application.
Additional memory management routine will not be required as resource user will acquire and release resource transparently.

The Consequences of this approach include:

In concurrent environment acquisition request for the resource needs t be synchronized in order to avoid race condition and possibility of corrupting associated state.
In case if resource users are involve in eager acquisition polling approach will fail.

Eager Initialization Pattern

2010-06-03T22:29:00.004+05:30

As name suggests Eager Initialization approach creates/initialize an object with anticipation, regardless of whether or not it will be required in program.

Definition: The Eager Initialization pattern describes how run-time acquisition and initialization of resources can be made predictable and fast by eagerly acquiring and initializing resources before their actual usage.

Eager initialization pattern at first glance seems an un-efficient pattern, but in situation where application is required to be reliable and predictable with no downtime this pattern comes handy. As and when an object/variable is declared or when the object in which it lives is created [declaration or constructor] object/variable is initialized.

Eager initialization approach should only be used

When initialization of the instance variable would consume large amount of time and downtime of application is not acceptable.
In pooling solution where it will require pre-acquire a number of resources in order to quickly serve first requests.
A Hamster application. Like hamster which acquires as many fruits as possible before eating them in its cave, Hamster application will acquires as many resources before it’s actually execute application.

The benefits of this approach include:

Increase in predictability of application as user requests for resource acquisition are intercepted and served instantly.
Application response time is very low as resources are pre acquired.
Assurance of the variables been initialized before they are used.

The Consequences of this approach include:

As all the resources are eagerly acquired at the start of the application, the start-up time for the application is longer.
Eager Initialization might initialize many objects upfront, which may not be required by system. This may introduce unnecessary exhaustion or overuse of memory resources.
Management of eagerly initialized object becomes an important aspect as not all the resources might require immediately in application.

Lazy Initialization Pattern

2010-05-28T00:45:00.002+05:30

As name suggests Lazy initialization pattern delays the creation of an object till it is requested for the first time in program.

Definition: The Lazy initialization pattern defers resource acquisitions to the latest possible point in time during system execution in order to optimize resource usage.

Lazy initialization is typically accompanied by a flag for indicating whether the initialization process is executed or not. As and when an object is requested, associated flag is first tested. If the object is created priory by another request then same is returned else it is initialized on the spot.

Lazy initialization approach should only be used

When initialization of the instance variable would consume a significant amount of time.
When initialization of the instance variable would consume a significant amount of resources.
When chance of the variable not been used is very high

The benefits of this approach include:

Increase in performance of application due to avoiding unnecessary creation of an object.
Optimal utilization of memory, as creation of object is postponed till it actually required in application.
The stability of the applications is increased because resource exhaustion becomes less likely.

The Consequences of this approach include:

The execution of the Lazy Initialization can introduce a significant time delay to the regular program execution. Especially for real-time systems such behavior is not advisable.
Lazy Initialization might introduce additional complexity to the program, especially concerning the program logic and distribution of initialization code throughout class.
The behavior of a lazy Initialization pattern can become distinctly non-linear when certain thresholds are reached, e.g. virtual memory systems can end up thrashing. This disqualifies the pattern for usage in real-time systems.

For example, consder a Tax calculation application where calculation of actual tax that need to be payed is posponded till user filled all information and clicked 'Calculate' button.

package
{
   public class TaxCalculator()
   {
   private var grossIncome:Number;
   private var taxAmount:Number;

   public var monthlyBasic:Number;
   public var monthlyDA:Number;
   public var monthlyOther:Number;
   public var yearlyInsurance:Number;
   public var yearlyPPF:Number;
   public var yearlyBonds:Number;

   public function TaxCalculator():void
   {
   }

   pulic function get gross():Number
   {
     // Evaluating user gross income as an when asked, not prior to that.
   grossIncome = (monthlyBasic + monthlyDA + monthlyOther) * 12 - (yearlyInsurance + yearlyPPF + yearlyBonds);
   return grossIncome;
   }
   public function actualTaxAmount():Number
   {
   // Evaluating actual tax amount as an when asked,
   // not prior to that.
   var taxableAmount:Number = (gross-150000);

   if(taxableAmount < = 0)
   {
     taxAmount = 0
   }
   else
   {
   if(taxableAmount < = 350000)
   {
   taxAmount = taxableAmount * 0.1;
   }
   else
   {
     taxableAmount = taxableAmount - 350000;
     taxAmount += 35000;

   if(taxableAmount < = 300000)
   {
   taxAmount += taxableAmount * 0.2;
   }
   else
   {
   taxableAmount = taxableAmount - 300000;
   taxAmount += 30000 + taxableAmount * 0.3;
   }
   }
   }

   return taxAmount;
   }
   }
}

class 1: TaxCalculator

package
{
   public class TaxCalculatorManager
   {
   private static var INSTANCE:TaxCalculator;

   public function TaxCalculatorManager(value:SingletomeEnforcer):void
   {
   }
   public static function getInstance():TaxCalculator
   {
   if(INSTANCE == null)
   {
   INSTANCE = new TaxCalculator();
   }

   return INSTANCE
   }
   }
}
/* Inline class to enforce singleton pattern */
class SingletonEnforcer
{

}

class 2: TaxCalculatorManager

package
{
   import flash.display.MovieClip;
   import flash.events.MouseEvent;

   public class Client extends MovieClip
   {
   private var taxCalculator:TaxCalculator;

   public function Client():void
   {
   init();
   calculateBtn.addEventListener(MouseEvent.CLICK, calculateTax);
   }
   private function init():void
   {
   // Initializing all on screen input text fields
     this.monthlyBasicTxt.text = 0;
     this.monthlyDATxt.text = 0;
     this.monthlyOtherTxt.text = 0;

     this.yearlyInsuranceTxt.text = 0;
     this.yearlyPPFTxt.text = 0;
     this.yearlyBondsTxt.text = 0;

     this.grossAmountTxt.text = 0;
     this.taxAmountTxt.text = 0;

   }
   public function calculateTax(e:MouseEvent):void
   {
   if(taxCalculator == null)
   {
   //Posponding initialization of TaxCalculator object
   //till it is first required;
   taxCalculator = TaxCalculatorManager.getInstance();
   }
   // setting user inputted income in TaxCalculator object
   taxCalculator.monthlyBasic = Number(this.monthlyBasicTxt.text);
   taxCalculator.monthlyDA = Number(this.monthlyDATxt.text);
   taxCalculator.monthlyOther = Number(this.monthlyOtherTxt.text);

   taxCalculator.yearlyInsurance = Number(this.yearlyInsuranceTxt.text);
   taxCalculator.yearlyPPF = Number(this.yearlyPPFTxt.text);
   taxCalculator.yearlyBonds = Number(this.yearlyBondsTxt.text);

   //displaying user gross value along with actual tax value.
     this.grossAmountTxt.text = taxCalculator.gross
   this.taxAmountTxt.text = taxCalculator.actualTaxAmount();
   }
   }
}

class 3: Client

Lazy initialization is often used together with a Factory Method Pattern. This combines three ideas:

Using a factory method to get instances of a class (Factory Method Pattern)
Storing the instances in a variable mapped with a flag, so that same instance is referred when getter is fired with same parameter (compare with a Singleton Pattern)
Using lazy initialization to instantiate the object the first time it is requested (Lazy Initialization Pattern).

Properties that can be set using mm.cfg file

2010-05-24T21:21:00.000+05:30

mm.cfg file is used to configure the debugger version of Flash Player. The Location where this file is available depends on the operating system also if this file is not available at the location then we can create this file.

Operating system	Location of mm.cfg
MS Window Vista	C:\Users\<user_name>\
MS Windows 2000/XP	C:Document and Setting\<user_name>\
Macintosh OS X	MacHD:Library:Application Support:macromedia:
Linux	/home/<user_name>/

Following are the properties that can be set in mm.cfg file for debugging

Properties	Description
ErrorReportingEnable	Enables/Disables logging of error messages. 1: Enables debug Flash Player to write error messages to the log file. 0: Disables debug Flash Player to write error messages to the log file. Default value is 0(zero).
MaxWarnings	Number of flash warnings/error messages to be logged before stopping. The default value of the MaxWarning properties is 100. After 100 warning/error messages are logged, the debug version of Flash Player writes further error messages are suppressed in log file. Setting the MaxWarnings property will override he default messaging limit. For example if set to 500, the log file will record 500 warning / error messages. If MaxWarnings property is set to 0 (zero), limit to record warning / error messages is removed and all the warning / error messages are recorded.
TraceOutputFileEnable	Enables/Disables logging of trace messages. 1: Enables debug Flash Player to write trace messages to the log file. 0: Disables debug Flash Player to write trace messages to the log file. Default value is 0(zero).
TraceOutputFileName	Ignored form Flash Player 9.

Note: Debug Flash Player writes all warning /error messages /trace statements to a file named flashlog.txt, whose location depends on operating system.

Operating system	Location of flashlog.txt
MS Window Vista	C:\Users\<user_name>\AppData\Roaming\Macromedia\Flash Player\Logs\
MS Windows 2000/XP	C:Document and Setting\<user_name>\Application Data\Macromedia\Flash Player\Logs\
Macintosh OS X	MacHD:Users:<user_name>:Library:Preferences:Macromedia:Flash Player:Logs:
Linux	/home/<user_name>/macromedia/Flash_Player/Logs/

Flash Output Log File

2010-05-22T01:04:00.010+05:30

This post is just guide on where the flash log is situated and in case if not available then, how to make it available.

The flashlog.txt is a log file created by the Flash Player. Output of all trace statement along with error reports and warning messages which are generated during compilation and/or running of a flash application are written in this log file by flash player. Existing log file is deleted and new one is created, each time flash application is started.

The flashlog.txt file is located at following location on machine

Operating System		Path
Window XP	:	C:/Documents and Settings/<user_name>/Application Data/Macromedia/Flash Player/Logs/flashlog.txt
Window Vista	:	C:/Users/<user_name>/AppData/Roaming/Macromedia/Flash Player/Logs/flashlog.txt

In case if flashlog.txt file is not available at above mention location [based on operating system], follow below mention steps:

Open command prompt
Type 'echo %HOMEDRIVE%HOMEPATH%' and then press enter.
Above line of code when executed will specify location where macromedia configuration file [mm.cfg] will be found.
Open Window Explorer and traverse to the folder location displayed on command prompt.
If macromedia configuration file [mm.cfg] file is missing at above location then open a Notepad file type in below mention line of code as is and then save Notepad file as 'mm.cfg' at above location and close it.

ErrorReportingEnable=1
TraceOutputFileEnable=1
Close all open flash application [IDE, AIR application and Web Browsers].
Now re-run flash application and all the trace statement along with error reports and warning messages will be displayed in flashlog.txt file available at location mention in table above.

The sets listed above will be useful for debugging and getting all flash logs in flashlog.txt file when flash application is running in the standalone flash player. In order to get trace statement for flash application running through web browser, you need to install Flash Debug Player for web browser.

Steps to install Flash Debug Player

Uninstall Flash player
Install Flash Debug Player location [http://www.adobe.com/support/flashplayer/downloads.html]
Restart your browser and launch any website containing SWF. Right-click [ctrl+click] on SWF, it will display 'Debugger' option in context menu.

Once Flash Debug Player is installed, you will be able to view logs in flashlog.txt file even for flash application running from web browser.

Constructor execution order in Actionscript 3.0

2010-05-19T22:32:00.006+05:30

While working on one of my project, I came across off the track behavior of flash player while executing class constructor. It was observed that flash player while compiling class checks whether the class constructor has explicit call to its super class constructor [anywhere from its constructor], if true flash player does not implicitly calls super class constructor else first statement to be executed in class is call to super class constructor.

To explain above statement, let’s take an example, Base class is the parent class for Child class and their structure is as follows

package
{
   public class Base
   {
      protected var baseClassProperty:String;
      public function Base()
      {
         trace("Base Constructor is called");
         baseClassProperty = "Hello World from Base class";
      }
   }
}

package
{
   public class Child extends Base
   {
     public function Child()
      {
        trace("Child Constructor is called");
      }
   }
}

Now if we instantiate Child class as

var childObj:Child = new Child();

When above statement is executed, following will be the output

Base Constructor is called
Child Constructor is called

As expected Flash player will implicitly add call to super class constructor as first statement and hence we will have base class trace first statement and child class trace as second statement in output panel.

In case if Child class implicitly add call to super class constructor

package
{
   public class Child extends Base
   {
      public function Child()
      {
         trace("Child Constructor is called");
         super();
      }
   }
}

Now if we instantiate Child class, following statement will be displayed in out panel.

Child Constructor is called
Base Constructor is called

As we have explicitly called super class constructor form Child class, Flash player will not implicitly add call to super class constructor as first statement and hence we will have child class trace as a first statement and base class trace as a second statement in output panel.

Accessing Base class variable from Child class.

While accessing Base class variable from Child class, where Base class is parent class of Child class, it is advisable to accessing variable only after explicit call to Base class constructor in Child class when Child class has explicit call to Base class constructor or can be access at any level if call to Base class constructor is implicit in Child class. In cases when Base class variable if access before implicitly/explicit call to Base class constructor may many time give unexpected result.

Cross Domain Policy Files

2010-05-19T21:59:00.002+05:30

A cross-domain policy is a XML document file which is use to grant permission to web client like Adobe Flash Player to access data from different domain. When a client host an application on a domain and makes a request to access content from domain other than its own, the remote domain would required to host a cross-domain policy file which would define and grant access to application from client domain.

Policy file are also used with sockets to grant permission for socket-base connections. It is advisable, to host policy file for both same domain connection as well as connections made across domains.

Normally policy file are host on root directory of a server with file name crossdomain.xml, this is the default location. The following is the example of a typical policy file.

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
   <site-control permitted-cross-domain-policies="none"/>
   <allow-access-from domain="*"/>
   <allow-http-request-headers-from domain="*" headers="*" secure="false"
</cross-domain-policy>

The parent tag for any crossdomain.xml is <cross-domain-policy>tag.

<cross-domain-policy> tag has following elements

<site-control>: <cross-domain-policy> tag can have only one site-control element. This element defines the meta-policy for the current domain. In cases where client needs to have multiple policy file on the domain, master policy file [policy file residing on root directory of the domain] decide the acceptability of the policy files on the domain. This element is of importance only if policy file is master policy file else this element is ignored. If a flash application is instructed to use a policy file in a location other than that of the master policy file, the client must first check meta-policy of the master policy file to determine if the original policy file is allowed. permitted-cross-domain-policies attribute of this elements meta-policies, it can hold following values
- none: No policy files are allowed anywhere on the server other then this file.
- master-only: Only this master policy file is allowed on the server.
- by-content-type: All policy files whose Content-Type is text/x-cross-domain-policy are only allowed. This meta-policy is only available for HTTP and HTTPS servers.
- by-ftp-filename: Only policy files whose file names are crossdomain.xml (i.e. with URLs ending in /crossdomain.xml) are allowed.
- none-this-response: This is a special meta-policy that can only be specified in an HTTP response header. It helps prevents this particular HTTP response from being interpreted as a policy file.
- all: All policy files on this domain are allowed.
By default ‘none’ value is assign to this attribute of the element.

<allow-access-from-domain>: <cross-domain-policy> tag can have any number [zero or more] of allow-access-from elements. Each allow-access-from element can be used to define a domain or IP address from which a Flash application can access the local resources. The attribute domain specifies address of domain/IP address of Flash application which can access. If address specified is ‘*’ then it specifies that the local resource of the domain can be access by Flash application from any domain. In case if you want to grant access to your public resources by a specific domain(s), then that domain address need to be specified.

<allow-access-from domain="www.mySite.com" />

The above example will give access to Flash application hosted on www.example.com domain to access the public resources. Also wildcard ‘*’ can be used to match domains that ends with the given suffix.

<allow-access-from domain="*.mySite.com" />

IP address where Flash application is hosted can also be specified.

<allow-access-from domain="127.0.0.1" />

By default a Flash application hosted on an HTTPS server can only access resources on remote HTTPS servers. So if secure attribute is set to false, then a Flash application on an HTTP server can access resources from an HTTPS server.

<allow-access-from domain="*.mySite.com" secure="false" />

Policy file is also used while granting access to list/range of ports through which socket connection is allowed. Range of ports is specified through a dash (-)between two part numbers. List of ports are separated by comma (,). Wildcard character (*) can be used to allow all ports. The following is the example of socket-based policy file.

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.mySite.com" to-ports="507,516-523"/>
</cross-domain-policy>

The above example will allow socket connections from domain mySite.com, including sub-domains, to ports 507, 516, 517, 518, 519, 520, 521, 522 and 523.

<allow-http-request-header-from>: <cross-domain-policy> tag can have any number [zero or more] of allow-http-request-headers-from elements. The allow-http-request-headers-from element grants a client hosting content from another domain to send user-defined headers to the current domain, i.e., this tag grants permission to push data [in form of header] into current domain.

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-http-request-header-from domain="www.mySite.com" headers="X-My*"/>
</cross-domain-policy>

This policy file allows any header beginning with the characters X-My from www.mySite.com to be sent to this domain.

Making domain resources inaccessible from other domain

If you don’t want any Flash application to access your data/resources form your server then you can create a crossdomain.xml file that does not include ant <allow-access-from> tag

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
</cross-domain-policy>

Domain matching criteria followed by Flash Player

The following rules are used in determining if a value in the domain attribute of the <allow-access-from> or <allow-http-request-headers-from> elements matches an actual domain name:

For named domains, top-level domain names (i.e. com in www.mySite.com), along with second-level domain names (i.e. mySite in www.mySite.com) and subdomains of a second-level domain (i.e. www in www.mySite.com) should match.
Any domain used without a subdomain, are considered separate domains.
Whenever a wildcard character (*) is used as a subdomain, it matches the domain without a subdomain.
Wildcard character (*) is always used in place of subdomain or as an entire domain [All domain access], otherwise domain is invalid.
IP addresses and named domains are considered separate domains, even if they refer to the same host.
Cross-domain redirects are not allowed and, if used, a domain is considered invalid.

Examples:

Domain Values	Match	Not Match
www.mySite.com	www.mySite.com	http://mySite.com www.mySite.net www.mysite.co.in
*.mySite.com	www.mySite.com http://mySite.com http://www.mySite.com http://myExample.mySite.com	http://www.mySite.net http://adobe.com
127.0.0.1	http://127.0.0.1	http//localhost http://127.0.0
www.mySite.*	invalid domain

Flex Builder 3: Optimizing Flex Builder Performance

2010-05-11T21:53:00.003+05:30

Many time while developing large project using Flex Builder, performance of IDE is comparatively slow which always leads to frustration. While finding solution for this issue I came across few Eclipse environment tweaks, which along with certain workflow best practices improves performance of IDE.

Workflow best practice

Turn-off Build Automatically: This feature is best suited for small project or for prototypes, as it save developers from pressing Run button again and again. Developer just need to refresh browser after saving changes. But in case when project size is large, having flex builder to recompile for every small changes save is very taxing.
Having only required project open: Whenever Flex Builder create a build or perform copy-paste/rename operation, it refreshes entire document tree for every open project. Time taken for updating document tree of Flex Builder is directly proportionate to number of open project.
Don't embed too many assets: Project compilation time and size of project SWF file is directly proportionate to number of assets embedded for project. There are two ways to resolve this issues:
1. Use resource bundled for embedded assets
2. Assets that need to be embedded for the application can be embedded into a module, which can be then loaded into application at runtime.
Turn-off Copy non-embedded file to output folder: This option is available under Flex Compiler option of Properties panel. If turn-on Flex Builder will copy all files including one which will be never referenced into build folder of application. This action is waste of compilation time.
Clean your project: When this command is executed for project Flex Builder will reset html-template folder of project along with erasing all the files in debug folder and cleaning cache code i.e., restarting entire project afresh.

Eclipse environment tweaks

Eclipse IDE has several optional command line argument that can used to improve IDE performance. All command line argument are executed when IDE is launched. This command are:

-clean: This argument flushes the registry cache and clear Eclipse setting and framework.
-refresh: This argument instruct Eclipse to refresh the file list in local workspace. This argument is useful if many file changes has occurred between Flex startups or if Flex has shutdown unexpectedly.
-showlocation: This argument displays current location of the workspace in window title bar.
-vmargs: This argument helps to customize the operation of Java Virtual Machine [JVM] that is use to run Eclipse. The following parameters associated with vmargs argument are used for tweaking memory allocation for JVM
-Xms[memory]
-Xmx[memory]
By default Eclipse will be allocated 256MB of Java heap memory. This value can be modify/increase/decrease by assigning appropriate values. -xmsparameter determine minimum assigned memory. -xmxparameter determine maximum assigned memory. It is advisable to allocate same value for xms and xmx to avoid memory resizing.
-XX:MinPermSize=[memory]
-XX:MaxPermSize=[memory]
The above arguments are use to set JVM's PermSpace, which is the area of memory use to store data structure and class information in real-time. By default Eclipse will be allocated 64MB of memory space. Setting MinPermSize and MaxPermSize to 128MB or 256MB can solve OutOfMemoryException.

Note: Sometime by allocating memory for JVM much more than allowed/supported by system, system will throw an error. In such case decrement the assign value a little and try again.

As recommended, assign as much memory as your system will allow to JVM, this will enable your workbench to run as efficiently as possible.

Above Eclipse environment tweaks can be achieve by modifying FlexBuilder.ini or by using the arguments in shortcut for launching the Flex builder.

Under normal circumstances target field under shortcut panel of Flex Builder will look like

Target

"C:\Program Files\Adobe\Flex Builder 3\FlexBuilder.exe"

In case if you want to display location of current project and increase memory allocated to JVM to 512MB thentarget field under shortcut panel of Flex Builder will look like

Target

"C:\Program Files\Adobe\Flex Builder 3\FlexBuilder.exe" -showlocation -vmargs -Xmx512m -Xms512m

When you open the FlexBuilder.ini file, it looks like

1	-vmargs
2	-Xms256m
3	-Xmx256m
4	-XX:MaxPermSize=256m
5	-XX:PermSize=64m
6	-Djava.net.preferIPv4Stack=true

Add clean, refresh or showlocation argument prior to vmargs argument in FlexBuilder.ini file. In case if you want to display location of current project then FlexBuilder.ini file after update will look like

1	-showlocation
2	-vmargs
3	-Xms256m
4	-Xmx256m
5	-XX:MaxPermSize=256m
6	-XX:PermSize=64m
7	-Djava.net.preferIPv4Stack=true

The FlexBuilder.ini file should be in your Flex Builder install folder.

The undocumented [SWF] Metadata Tag

2010-05-05T23:22:00.004+05:30

In Flash authoring environment, developer can control actual width, height, frame rate properties of SWF. But in Flex project, these setting can be configured as a properties of Application MXML tag. Where as in ActionScript project using Flex Builder, this complier setting can be configured using undocumented [SWF] metadata.
[SWF(width='1024', height='768', frameRate='24' backgroundColor='#CCCCCC')]
Following are the list of properties that can be set using undocumented [SWF] Metadata

Property	Description
backgroundColor	This property is use to set background color of the stage.
pageTitle	String used to represent the title of HTML page
frameRate	This property is use to set frame rate of SWF file
width	This property is use to set the width of stage
height	This property is use to set the height of stage
widthPercentage	This property is use to set the width of stage with respect to inner browser width. Note: Value specified for this property needs to be appended by '%' sign.
heightPercentage	This property is use to set the height of stage with respect to inner browser height. Note: Value specified for this property needs to be appended by '%' sign.
scriptRecursionLimit	The maximum depth or stack overflow limit of flash player, i.e., number of time a recursive script will run before flash player stops.
scriptTimeLimit	Maximum duration, in seconds, that an ActionScript event listener can execute before Flash Player assume that it has stopped processing and abort it. The default value is *60 second*, which is also the maximum allowable value.

These properties convey instruction to Flex compiler about how to publish SWF application. backgroundColor,pageTitle, widthPercentage, heightPercentage properties are used by Flex compiler for creating HTML wrapper, while width, height, widthPercentage, heightPercentage, scriptRecursionLimit, scriptTimeLimitproperties are used by Flex compiler for creating of SWF.
Note: Some of this properties can also be configure via compiler option in project properties settings.