The singleton pattern is a design pattern that is used to restrict instantiation of a class to one object. If you create the class as a singleton then no way to create more than one instance. But, you can get that single instance in any number of classes. So all the classes will share the same properties and behaviours of that singleton object.

How to implement the singleton pattern?

Implementation of a singleton pattern must satisfy the single instance and global access principles. It requires a mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among class objects. The singleton pattern is implemented by creating a class with a method that creates a new instance of the class if one does not exist. If an instance already exists, it simply returns a reference to that object. To make sure that the object cannot be instantiated any other way, the constructor is made protected (not private, because reuse and unit test could need to access the constructor). Note the distinction between a simple static instance of a class and a singleton: although a singleton can be implemented as a static instance, it can also be lazily constructed, requiring no memory or resources until needed. Another notable difference is that static member classes cannot implement an interface, unless that interface is simply a marker. So if the class has to realize a contract expressed by an interface, it really has to be a singleton.

The singleton pattern must be carefully constructed in multi-threaded applications. If two threads are to execute the creation method at the same time when a singleton does not yet exist, they both must check for an instance of the singleton and then only one should create the new one. If the programming language has concurrent processing capabilities the method should be constructed to execute as a mutually exclusive operation.
The classic solution to this problem is to use mutual exclusion on the class that indicates that the object is being instantiated.

How to implement the singleton pattern in Flex and ActionScript?

• Can we implement the singleton pattern in ActionScript? Why not? Ofcource we can.

• Is there any keyword named as singleton in Flex?. No.

• Can we declare the constructor as protected in Flex?. No. (ActionScript 3.0 will not support protected constructors)

• Can we declare the constructor as private in Flex?. No. (ActionScript 3.0 will not support private constructors)

• Then how can we implement the singleton pattern in Flex ? See the next line.

Steps to  implement the singleton pattern in Flex and ActionScript

Consider the MySingleTon class as a singleton class.

package {
	public class MySingleTon {

    	// Single Instance of Our MySingleTon
		private static var instance:MySingleTon;

	    //DEFINE YOUR VARIABLES HERE
	    public function MySingleTon (enforcer:SingletonEnforcer)
	    {
	    	if (enforcer == null)
	    	{
                      throw new Error( "You Can Only Have One MySingleTon" );
			}
		}

		// Returns the Single Instance
		public static function getInstance() : MySingleTon
		{
			if (instance == null)
			{
				instance = new MySingleTon ( new SingletonEnforcer );
			}
			return instance;
		}
	}
}

// Utility Class to Deny Access to Constructor
class SingletonEnforcer {}

1). We should create one static variable. It will be called "instance" and it will be of type MySingleTon. This will be the variable where we will store our
one instance of our class.

2). Then we should create one constructor. The constructor takes one argument - "enforcer". You will notice that this "enforcer" has a type of "SingletonEnforcer"
which is defined directly after our class. Here is the logic behind that:

• When you put a class in an Actionscript file below the main class, it is only available to that class.

• If the constructor requires this argument – then only our main class can create an instance of itself, because we do not have access to the “SingletonEnforcer” class. Only the main class has this access.

• We will not access our class in the normal way by using the “new” statement because we can’t call the constructor. Once we get inside of the constructor, we have a few lines that make sure things work as planned. The “if” statement ensures that we had a valid “enforcer” passed in. If there wasn’t it throws an Error stating that “You Can Have Only One MySingleTon”.

Then we should create one static function named as getInstance. The “getInstance” function is how we will access our MySingleTon from our application. This function simply passes back the “instance” of the class. If it doesn’t exist yet, it creates it. We can now get the MySingleTon by using the following:

var mySingleTone:MySingleTon = MySingleTon.getInstance();. So you can share this single object in any number of classes.

Sometimes our flex application’s size becomes very large. Due to this, we are facing many problems such as bandwidth, network traffic and it will take more time to load. We have many ways to solve this problem such as

1. Do not embed the assets into the project.
2. Modules.

About Modules

Modules are the swf files which can be loaded and unloaded dynamically by an application. The user cannot run the modules independently in the browser or the flash player. But the user can share the modules in any number of applications.

Benifits of Modules

• Smaller initial download size of the SWF file.
• Shorter load time due to smaller SWF file size.
• Better encapsulation of related aspects of an application. For example, a “reporting” feature can be separated into a module that you can then work on independently.
• Any number of applications can share the modules.

Creating the Modules

To create the modules we should create seperate mxml or actionscript class and an application that uses the modules. We can create the modules in two ways, one is by using the mxml and by using the actionscript class.

Creating the modules by using the mxml

An MXML-based module file’s root tag should be <mx:Module>. Within this tag we can create all our child containers and components.Ofcource we can have our styles and scripts also. We should compile the modules using the mxmlc command-line compiler or the compiler built into Adobe Flex Builder. The swf file will be created after we compile the modules.

<?xml version="1.0" encoding="utf-8"?>
<!-- modules/MyModule.mxml -->
<mx:Module xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" width="400" height="300">
	<mx:Script>
		<![CDATA[
			import mx.collections.ArrayCollection;
	        	[Bindable]
	        	public var expenses:ArrayCollection = new ArrayCollection([
	            		{Month:"Jan", Profit:2000, Expenses:1500},
		            	{Month:"Feb", Profit:1000, Expenses:200},
		           	{Month:"Mar", Profit:1500, Expenses:500},
	        	    	{Month:"April", Profit:2000, Expenses:600},
	            		{Month:"May", Profit:2500, Expenses:700},
		            	{Month:"June", Profit:3000, Expenses:500},
		            	{Month:"July", Profit:4000, Expenses:400}
	        	]);
		]]>
	</mx:Script>

	<mx:DataGrid dataProvider="{expenses}" >
		<mx:columns>
			<mx:DataGridColumn dataField="Month" headerText="Month" />
			<mx:DataGridColumn dataField="Profit" headerText="Proft" />
			<mx:DataGridColumn dataField="Expenses" headerText="Expenses" />
		</mx:columns>
	</mx:DataGrid>
</mx:Module>

Creating the modules by using ActionScript

To create a module in ActionScript, we should create a file that extends either the mx.modules.Module class or the mx.modules.ModuleBase class. Extending the Module class is the same as using the <mx:Module> tag in an MXML file. You should extend this class if your module interacts with the framework; this typically means that it adds objects to the display list or otherwise interacts with visible objects.

package modules{
    import mx.modules.ModuleBase;

    public class ArithmaticModule extends ModuleBase {

        public function ArithmaticModule () {

        }

        public function add(a:Number, b:Number):Number {
            return a + b;
        }

	public function subtract(a:Number, b:Number):Number {
            return a - b;
        }

	public function divide(a:Number, b:Number):Number {
            return a / b;
        }

	public function multiply(a:Number, b:Number):Number {
            return a * b;
        }
    }
}

Loading the modules

We can load the modules in our applications by using the <mx:ModuleLoader> mxml tag or mx.modules.ModuleLoader and mx.modules.ModuleManager ActionScript classes. Typically, we use one of the following techniques to load MXML-based modules:

• ModuleLoader : The ModuleLoader class provides the highest-level API for handling modules.
• ModuleManager : The ModuleManager class provides a lower-level API for handling modules than the ModuleLoader class does.

Using the ModuleLoader class to load modules

We can use the ModuleLoader class to load module in an application or other module. The easiest way to do this in an MXML application is to use the <mx:ModuleLoader> tag. We set the value of the url property to point to the location of the module’s SWF file. The following example loads the module when the application first starts:

<?xml version="1.0"?>
<!-- modules/MySimplestModuleLoader.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:ModuleLoader url="MyModule.swf"/>
</mx:Application>

We can change when the module loads by setting the value of the url property at some other time, such as in response to an event. Setting the target URL of a ModuleLoader triggers a call to the loadModule() method. This occurs when we first create a ModuleLoader with the url property set. It also occurs if we change the value of that property. If we set the value of the url property to an empty string (“”), the ModuleLoader unloads the current module.

Using the ModuleManager class to load modules

You can use the ModuleManager class to load the module. This technique is less abstract than using the <mx:ModuleLoader> tag, but it does provide you with greater control over how and when the module is loaded. To use the ModuleManager to load a module in ActionScript, you first get a reference to the module’s IModuleInfo interface by using the ModuleManager getModule() method. You then call the interface’s load() method. Finally, you use the factory property of the interface to call the create() method and cast the return value as the module’s class.

The IModuleInfo class’s load() method optionally takes an ApplicationDomain and a SecurityDomain as arguments. If you do not specify either of these, then the module is loaded into a new child domain. The following example shell application loads the ColumnChartModule.swf file and then adds it to the display list so that it appears when the application starts:

<?xml version="1.0"?>
<!-- modules/ModuleLoaderApp.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="initApp()">
    <mx:Script>
        <![CDATA[
        import mx.events.ModuleEvent;
        import mx.modules.ModuleManager;
        import mx.modules.IModuleInfo;

        public var info:IModuleInfo;

        private function initApp():void {
            info = ModuleManager.getModule("MyModule.swf");
            info.addEventListener(ModuleEvent.READY, modEventHandler);

            // Load the module into memory. Calling load() makes the
            // IFlexModuleFactory available. You can then get an
            // instance of the class using the factory's create()
            // method.
            info.load();
        }

        private function modEventHandler(e:ModuleEvent):void {
            // Add an instance of the module's class to the
            // display list.
            vb1.addChild(info.factory.create() as ColumnChartModule);
        }
        ]]>
    </mx:Script>

    <mx:VBox id="vb1"/>

</mx:Application>

Note: MXML-based modules can load other modules. Those modules can load other modules, and so on.

Unloading the Modules

We can unload the modelues in two ways:

1. If we set the value of the url property to an empty string (“”), the ModuleLoader unloads the current module.

2. Calling the unloadModule() method of the ModuleLoader instance.
public function removeModule(m:ModuleLoader):void {
m.unloadModule();
}

Modular applications best practices

By default, a module is loaded into a child domain of the current application domain. You can specify a different application domain by using the applicationDomain property of the ModuleLoader class. Because a module is loaded into a child domain, it owns class definitions that are not in the main application’s domain. For example, the first module to load the PopUpManager class becomes the owner of the PopUpManager class for the entire application because it registers the manager with the SingletonManager. If another module later tries to use the PopUpManager, Adobe ® Flash® Player throws an exception.

The solution is to ensure that managers such as PopUpManager and DragManager and any other shared services are defined by the main application (or loaded late into the shell’s application domain). When you promote one of those classes to the shell, the class can then be used by all modules. Typically, this is done by adding the following to a script block:

import mx.managers.PopUpManager;
import mx.managers.DragManager;
private var popUpManager:PopUpManager;
private var dragManager:DragManager;

This technique also applies to components. The module that first uses the component owns that component’s class definition in its domain. As a result, if another module tries to use a component that has already been used by another module, its definition will not match the existing definition. To avoid a mismatch of component definitions, create an instance of the component in the main application. The result is that the definition of the component is owned by the main application and can be used by modules in any child domain.

Because a Flex module must be in the same security domain as the application (SWF) that loads it, when you’re using modules in an AIR application any module SWF must be located in the same directory as the main application SWF or one of its subdirectories, which ensures that like the main application SWF, the module SWF is in the AIR application security sandbox.

One way to verify this is to ensure that a relative URL for the module’s location doesn’t require “../” (“up one level”) notation to navigate outside the application directory or one of its subdirectories.

• It’s not how much and what you know; but what you can do with what you know, which’s important.

• Ability to implement Polymorphism, Inheritance, private, public namespaces, static methods etc is no guarantee you are a good OO developer.

• OOP is useless if you don’t use it to create good software design (architecture).

• Using packages, classes, etc does not guarantee good software design.

• When designing your software, think of it as an electronic device you are designing.

• Sketch out the ‘electronic device’. Label the different components, list their functionalities.

• Stay hungry, stay foolish.

That’s it for today. I hope you are blessed with more knowledge, and the ability to make the best use of them.  Adios!

We can divide the pureMVC as:

• Facade & Core
• Controller & Commands
• Model & Proxies
• View & Mediators
• Observers & Notifications

Steps to follow in PureMVC

1. Main application should call the facade.startup(this). Here facade is the singletone instance of ApplicationFacade class.

2. ApplicationFacade

• Singleton class.
• It extedns the org.puremvc.as3.patterns.facade.Facade.
• It implements org.puremvc.as3.interfaces.IFacade .
• Should override the initializeController() method.
• It defines static constants for Notification names.
• Initializes the Commands used to access and notify the Commands, Mediators and Proxies.

3. MacroCommand(s)

• It extends the org.puremvc.as3.patterns.command.MacroCommand.
• It implements the org.puremvc.as3.interfaces.ICommand.
• Should override the initializeMacroCommand() method.
• Executes the SimpleCommands and MacroCommands.
• User can registerand retrieve the Mediators and Proxies.

4. SimpleCommand(s)

• It extends the org.puremvc.as3.patterns.command.SimpleCommand.
• It implements org.puremvc.as3.interfaces.ICommand.
• Should override the execute( note:INotification ) method.
• User can register and retrieve the Mediators and proxies.

5. Mediator(s)

• It extends the org.puremvc.as3.patterns.mediator.Mediator.
• It implements the org.puremvc.as3.interfaces.IMediator.
• Should override the listNotificationInterests() and handleNotification( note:INotification ) methods    to listen to the notifications.
• Registers the mediators and proxies.
• User can retrieve the Mediators and proxies.
• User can register the notifications.
• Listens for the notifications from other Mediators, Proxies and commands.
• Listens for the events from the component.
• Sends the notifications to other mediators.

6. Proxy(ies)

• It extends org.puremvc.as3.patterns.proxy.Proxy.
• It implents the interface org.puremvc.as3.interfaces.IProxy.
• User can send the notifications.
• Used to access the Delegates and datas.

7. Component(s)

• Views of our application.
• Every component should have its own Mediator. One Mediator per Component.
• Dispatches the event. So the mediator can listen for that events.

Observers

PureMVC applications may run in environments without access to Flash’s Event and EventDispatcher classes, so the framework implements an Observer notification scheme for communication between the Core MVC actors and other parts of the system in a loosely-coupled way. No need to create instance for the Observers and notificatios. These are inbuilt things in the pureMVC.

Notifications
PureMVC implements the Observer pattern so that the Core actors and their collaborators can communicate in a loosely-coupled way, and without platform dependency.

Not simply a replacement for Events, Notifications operate in a fundamentally different way, and work synergistically with Events to produce extremely reusable View Components that need not even know that they are coupled to a PureMVC system at all if engineered properly.

Events are dispatched from Flash display objects that implement the IEventDispatcher interface. The Event is ‘bubbled’ up the display hierarchy, allowing the parent object to handle the Event, or the parent’s parent, etc.

Notifications are sent by the Facade and Proxies; listened for and sent by Mediators; mapped to and sent by Commands. It is a publish/subscribe mechanism whereby many Observers may receive and act upon the same Notification.

WorkFlow of the PureMVC framework

• MainApplication should startup the pureMVC framework by calling the ApplicationFacade(Facade)’s startup method.
• ApplicationFacade Registers the Commands,Mediators and Proxies.
• User can retrieve the Mediators and Proxies in the  ApplicationFacade.
• Two commands are there: MacroCommand and SimpleCommand.
• MacroCommand registers other commands, Mediators and Proxies.
• SimpleCommand registers the Mediators and Proxies.
• Both the Macro and Simple Commands can be used to retrieve the Mediators and Proxies.
• User can send notifications from both the Macro and Simple commands.
• Mediators registers the component with the PureMVC.
• Mediators will listen for the events and notifications.
• Mediators will listen for the events dispatched from the Components.
• Mediators will listen for the notifications sent from the other  Mediators, Proxies and Commands.

• A rich Internet application (RIA) is a Web application designed to deliver the same features and functions normally associated with deskop applications.

• RIAs typically form a stateful client application with a separate services layer on the backend.

• Run in a web browser, or do not require software installation

• Run locally in a secure environment called a sandbox

• Installation footprint is smaller — overhead for updating and distributing the application is trivial, or significantly reduced compared to a desktop or OS native application

• Updates/upgrades to new versions can be automatic or transparent to the end user

• Users can use the application from any computer with an internet connection

• Many tools exist to allow off-line use of applications, such as Adobe AIR, Google Gears, Curl, and other technologies

• Most RIA techologies allow the user experience to be consistent, regardless of what operating system the client uses.

• Web-based applications are generally less prone to viral infection than running an actual executable

• Open source framework used to develop the RIAs

• Highly productive development

• Created applications run across all browsers and desktops

• Highly maintainable and scalable solutions

• Flex is Flash based

• Flex gives powerful environment for data-driven apps using Actionscript and MXML

• Flex has no timeline

• Flex is 100% code based solution

• Flex can be used in parallel with Flash

• 2 languages    ▫ MXML    ▫ ActionScript 3

• Flex  Builder IDE

• Compilers, Debuggers and profilers

• Rich Component Library

• Flex Builder IDE

• Wide range of communication   ▫ HTTPService    ▫ WebService   ▫ RemoteObject

• Web Services Introspection – Generate code from WSDL and enables code hinting

• Data Wizards – Generating both server and client code