function onApplicationInit():void{
this.controller=new ApplicationController(this);
}

This is just to initialise the controller. Then CONTROLLER takes charge of everything and controlls the VIEW.But the problem with this is my view and controller are tightly coupled. I have to write the same initialisation code on all my views just to initialise its controller !!
Well on MATE, its the EVENT ecosystem. Upon VIEW creation on Flex, Flex has a sweet 'creationComplete' event dispatched. Now, we can directly bind this event to any eventhadler or make a custom event at this point and dispatch it. Now MATE's event Map can bind this event to any event handler on any class. So what I will get is VIEW dispatches one event and MATE gives this event to my CONTROLLER and CONTROLLER then handles the situation. VIEW does not know really from where it is being controlled :) sweet as very sweet.

How MATE works? Its a three step process.
1. Create a view (dispatch EVENT for every thing you need to controll)
2. Create an EventMap (maps each EVENT to an EVENTHANDLER)
3. Create a controller (Which handles the EVENT)

Thats it?!! YEAH, thats it. Cool, is not it?

Let's face it, Flex basically sucks for complex symbol production, and Flash basically sucks for development. Flash kicks butt for complex symbol production and Flex kicks butt for developing. So use both!

Recently I have had the opportunity to work in an environment that supports engineering best practices. In my years of being an architect and developer, I find that all work in the UI space is iterative and that those iterations also apply to process and best practice development. Having the ability to iterate allows for refinement, clean up, optimization, smarter class hierarchies, and significant satisfaction in ones work. Iteration of production process seems to have real payoff by reducing the amount of work that is duplicated from one stage of a UI's life to the next.

My current projects start life as AI or PSD UI comps that are generally produced for flash consumption. What I mean by that is that the layers that make up an element are often grouped, and elements and components are logically organized. This is a tremendous help and if you are smart and lucky enough to work with cooperative designers, you could even provide a naming convention and layer and grouping scheme that could save *you* LOTS of time. The catch here is that you are not necessarily saving total project time, because the designer is now responsible for at least the first iteration of naming the elements you will be importing. You might also show your designer how to configure AI or PS to snap to the nearest whole number pixel and how strokes are better as shapes instead of shape outlines. Add all of these ideas together and you are going shave some significant Flash production time.

Flash's AI and PSD import filters are a life saver, they provide many options to import the various layer types that AI and PSDs support. The importer allows you to choose just what to do with every bitmap, vector, and text layer as well as every group. You can convert each one of these layers to its compatible Flash symbol type. You can preserve editable text, rasterize it, or create outlines. You can rasterize vector shapes, and you can choose the compression type and amount for each bitmap element. You can create movieclips from a groups. Another nice feature is the import filter respects the visibility of layers in the source file, making it easy to import individual components without having to hunt around for the correct layers within the import dialog. One can use a design comp that has many components and panel backgrounds in it and just switch on the layers that represent a component set, save, then import. Best of all you can set you default import preferences for the various element types in the Flash preferences panel.

The amount of work you have to do from there is based on the complexity of the UI elements, components, and panels, as well as how well you are staged as a result of the designer properly following your production guidelines. You will still have to do some "mechanical" production to achieve your desired interactivity and behavioral capabilities.

Flash's WYSIWYG composition tool is great to make the small adjustments that are often necessary to tighten up a design for production as well as creating symbols for items that are used dynamically. Now all you have to do is give each symbol a unique and logical linkage class (AS3) or identifier (AS2) name and publish the FLA as a SWC and you can then access these library elements as classes from Flex and other tools like Flash Develop. A nice shortcut is to create a symlink from the Flex Libs folder to your Assets SWC. This allows you to put your FLA file where you want it and not have to create a custom path for your SWF/SWC output. More on this later.

Let's all admit that editing code with Flash is not the best experience and leaves a lot to be desired. I have not tried to debug in Flash for a looooong time, but I still believe that debugging in Flash is no where near as capable as debugging in Flex. Another reason to publish to SWC and code in Flex is that Flash does not support adding SWCs to the class path. This simply defeats the OO principal of having libraries that you can "re-use", in this case they are simply UI class libraries. So if you want to share some symbols from one FLA to another you need to either copy the elements from one library to the other, which can require some library maintenance and might cause some collision on symbol and class naming (BAD), or create components to 'share' and import those as compiled clips, this way there is only one library symbol for the various symbols that make up that component (GOOD). My current project requires that I be able to publish in Flash *and* Flex. Flash to create stand alone Mac and PC projectors, and Flex for my preferred development environment. Creating components in my shared UI FLAs and importing those into my main FLA is quite easy thank goodness...

Master Components - A nice shortcut for sharing the entire contents of a SWC (or any subset really) is to create a symbol and drag all of the library items desired into that one symbol. Create a component from that symbol, publish a SWC to the correct Flash folder, refresh your components panel, drag that one component into your main project FLA's library. This SWC will contain every element with their class / linkage names, and they will be accessible from AS. I am not sure what happens if you have a naming collision, but my guess is the symbol in the library will take priority over the symbol in the components 'library'.

On to Flex:

Flex loves SWCs! It hooks all of the classes compiled into a SWC, which in my case are all Flash UI symbol classes. Flex adds these classes to the code hints list automagically, THIS IS HUGE!

I use a "_mc" naming convention on all my UI symbol class names so it is easy to differentiate skins from code classes when coding. I always have a code class that instantiates its companion UI class as its "clip_mc". For example a button skin is a Flash UI class named "btn_close_mc" and this would be instantiated as the "clip_mc" var on the "Btn_close" code class. This way of skinning provides for great flexibility and even inheritance and overriding of skin elements. More to come on this in another post... Stay tuned!

Though I am not using any code classes in SWCs for my current work, SWCs can also be a great way to package and even protect entire code libraries.

Developing in Flex is "real" development. It is Eclipse development. The same development environment used for many languages and by many 'professional' software developers. Flex (Eclipse) has a great editor, debugger, watcher, and profiler. Real time build error detection and the problem report panel save lots of time, just try it! Code hints are absolutely required these days and Flex scans your SWCs and code classes and hints them! Syntax highlighting is great. SVN integration via Subclipse. Multiple project support - Project tree view. Cut and paste files into project view. Refactoring. Find in Files across multiple projects. ASdoc support. Comment and Function collapsing. The list goes on and on...

Now back to the symlink. As I mentioned earlier I have a requirement to be able to use Flash or Flex to compile and publish my project. Ultimately my project is published to Mac and PC projectors and as I understand it, of the two, only Flash can do this. This is where the trickery comes in. If the the FLA file lives in the root of my Flex projects "src" folder and not in the libs folder then I do not have to change any publish settings for the SWC or move the code classes (com) from Flex's src folder into the libs folder to compile the project with Flash.

FEATURE REQUEST! - a separate line in the publish preferences for SWCs.  Log that "issue" in JIRA!

Final Thoughts:

Why wouldn't you use the best tool for the job at hand? In this case, you have to buy (or VM - (try) - ad infinium) both tools, but the time saved and the sanity maintained is more than worth the investment (or not).

Building and maintaining complex components in Flex is a PITA, use Flash.

Flex is a feature rich software development tool that promotes professional development practices, don't use Flash to develop.

Note:

SWCs and Flex are not limited to AS3 project types. MXML provides for pixel accurate reproduction of complex components using the various compatible asset types, but I don't see any advantage to rebuiling entire UIs in MXML when you can use components imported from design files into Flash and published to SWCs. I will have to try this approach on my next Flex framework based RIA and make sure it is the way...

Let's say you want to create a scaled copy of an existing bitmap that is 25% of its original width and height.

Here's a basic example of how to do that using a matrix transformation:

The problem with this approach is that the scaled bitmap data often looks terrible when you load it into an Image control.

BitmapData objects have no concept of smoothing. Transformations performed directly on the bitmap data are not going to look as good as transformations performed on an image or bitmap that loads the bitmap data.

Here's an alternative approach to scaling the bitmap that uses an Image control and a Bitmap object with smoothing enabled:

This approach has two advantages.

One, it uses bitmap smoothing to produce a cleaner image. Two, it prevents the flicker that occurs when you load bitmap data into an Image control with dimensions that are smaller than the original size of the bitmap. In these cases the bitmap data will still scale appropriately, but not before it displays temporarily at its full size.