Posts Tagged ‘Flex’

Reflection / Introspection in Flex ActionScript

Wednesday, July 15th, 2009

As part of an effort to create enterprise components, libraries, and architectures, a company may want to take advantage of reflection. For example, a company may want a consistent way to create and populate various components. This might allow your developers to work more quickly since all of the components are handled in the same manner. However, many of the components in Flex (and, likely, many of a company’s custom components), have differences in how they’re created and populated … even when the functionality is conceptually similar. In order to accomplish a consistent interface, you may need some abstraction that allows you to dynamically create and populate objects at runtime. To that end, I thought it might be helpful to discuss the low-level how-to’s of reflection within Flex / ActionScript.

The Flex framework includes an implementation of the Class Factory pattern in mx.core.ClassFactory. This class allows you to instantiate classes determined at runtime.

Here are a couple of examples of how to instantiate a class determined at runtime:

INSTANTIATE AN OBJECT FROM IT’S CLASS

import mx.core.ClassFactory;
public static function instantiateUsingClass(classToInstantiate:Class):* {
	var myClassFactory : ClassFactory = new ClassFactory(classToInstantiate);
	var myObjectInstance : * = myClassFactory.newInstance();
	return myObjectInstance;
}

INSTANTIATE AN OBJECT FROM IT’S CLASS NAME (i.e., from a String like “com.domain.Person”)

import flash.utils.getDefinitionByName;
import mx.core.ClassFactory;
public static function instantiateUsingClassName(className:String):* {
	var classToInstantiate : Class = getDefinitionByName(className) as Class;
	var myClassFactory : ClassFactory = new ClassFactory(classToInstantiate);
	var myObjectInstance : * = myClassFactory.newInstance();
	return myObjectInstance;
}

At a basic level, mx.core.ClassFactory does the following to instantiate the class:

public var generator:Class;
...
this.generator = classToInstantiate;
...
var instance:Object = new generator();

There are other times when you need more than to simply instantiate a class. For example, you may need to query the class definition to find out what methods, properties, etc. are declared on that class. The flash.utils package provides some package-level functions for introspecting classes and objects. Here is a link to the flash.utils API: http://livedocs.adobe.com/flex/3/langref/flash/utils/package.html. For the purposes of reflection, the describeType() method is one of the best places to start (the call to getDefinitionByName() that was used above is another package-level function provided by flash.utils). Here is a way to find out what “accessor” methods (get/set methods) are declared for a class:

RETRIEVE NAMES OF ACCESSOR METHODS FOR A GIVEN CLASS

import flash.utils.describeType;
public static function getNonstaticAccessors(classOfInterest:Class):Array {
	var xmlDescriptionOfClass:XML = describeType(classOfInterest);
	var nonstaticAccessorsXML:XMLList = xmlDescriptionOfClass.factory.accessor;

	var accessors:Array = [];
	for each (var accessorXML:XML in nonstaticAccessorsXML) {
		accessors.push(accessorXML.@name);
	}
	return accessors;
}

In order to obtain the static accessors, use xmlDescriptionOfClass.accessor, instead of xmlDescriptionOfClass.factory.accessor. In addition to @name, you might also be interested in information contained in @access, @type, and @declaredBy.

When you modify a public property on an object using dot notation (i.e., myPerson.name = “Fred”;), Flex does exactly what you’d expect and modifies the public property value. But, Flex offers an additional convenience. If you decide, at a later time, that you’d like to make the properties private and force them to be accessed through accessor methods (i.e., public function set name(myName:String):void {…}), Flex will automatically call your accessor method (without having to change your code to call the accessor, instead of the property). Hooray!

When it comes to reflection, however, the factual separation between properties (class attributes … class variables … whatever term you prefer) and accessors is maintained. The point of this tangent is that your public properties (that do not have declared accessor methods) will not be returned by the above method. Instead, in order to discover the properties of a given class, you’ll need to query for them specifically (using the “.variable” notation).

Here is an example of how to query for the attributes of a class:

RETRIEVE NAMES OF PROPERTIES (CLASS ATTRIBUTES) FOR A GIVEN CLASS

import flash.utils.describeType;
public static function getProperties(classOfInterest:Class):Array {
	var xmlDescriptionOfClass:XML = describeType(classOfInterest);
	var nonstaticPropertiesXML:XMLList = xmlDescriptionOfClass.factory.variable;
	var properties:Array = [];

	for each (var propertyXML:XML in nonstaticPropertiesXML) {
		var property:Property = new Property(	propertyXML.@name,
							propertyXML.@type.toString(),
							isStatic );
		properties.push(propertyXML.@name);
	}
	return properties;
}

In order to obtain the static accessors, use xmlDescriptionOfClass.variable, instead of xmlDescriptionOfClass.factory.variable. In addition to @name, you might also be interested in information contained in @type.

Accessor methods (discussed earlier) are also kept separate from all of the other methods. Here is an example of how to query for the non-accessor methods of a given class

RETRIEVE NAMES OF METHODS FOR A GIVEN CLASS

import flash.utils.describeType;
public static function getMethods(classOfInterest:Class):Array {
	var xmlDescriptionOfClass:XML = describeType(classOfInterest);
	var nonstaticMethodsXML:XMLList = xmlDescriptionOfClass.factory.method;

	var methods:Array = [];
	for each (var methodXML:XML in nonstaticMethodsXML) {
		methods.push(methodXML.@name);
	}
	return methods;
}

In order to obtain the static accessors, use xmlDescriptionOfClass.method, instead of xmlDescriptionOfClass.factory.method. In addition to @name, you might also be interested in information contained in @type.

OK, great! We now have a few tools (I’m sure you’ll discover more as you begin experimenting with the reflection capabilities provided by Flex) to help us with introspection of ActionScript classes at runtime. But, hey, maybe we actually want to DO something with that information. Here is an example of how to trigger a method call on a class and method discovered at runtime:

INVOKE A METHOD ON AN INSTANTIATED OBJECT

public static function invokeMethod(objectContainingMethod:*, methodName:String, parms:Array):* {
	var method:Function = objectContainingMethod[methodName];
	var returnValue:* = method.apply(objectContainingMethod, parms);

	return returnValue;
}

= = = = = = = = = =
Now that I’ve taken your time discussing some basics of how to implement reflection within Flex / ActionScript, I’m now going to suggest that you do it differently!

I was discussing writing a blog on reflection awhile back with Justin Shacklette (Justin’s blog) and Jon Rose (Jon’s blog). Justin immediately pointed out that Spring was splitting their reflection functionality out into a separate library. This reflection library improves on some of the above techniques by implementing work-arounds for some known bugs, etc., etc. behind the scenes. In addition, it allows you to deal with objects that might be a bit more intuitive than the XML object that is returned by describeType(). On the other hand, this means that you’ll occasionally need to step down through the object hierarchy to find the desired value. I found it pretty easy to investigate the various classes and source code at this site: http://as3-commons.googlecode.com/svn/trunk/as3-commons-reflect/src/main/actionscript/org/as3commons/reflect/. The best classes to start with are Type.as and ClassUtils.as.

To get started, download the AS3 Commons Reflection library (as3commons-reflect-1.0.0.swc) from http://code.google.com/p/as3-commons/.

Add this SWC file to your Flex project’s lib folder.

Now, let’s revisit the above examples to see how they might differ when using the AS3 Commons Reflection library.

INSTANTIATE AN OBJECT FROM IT’S CLASS

import org.as3commons.reflect.ClassUtils;
public static function instantiateUsingClass(classToInstantiate:Class):* {
	var myObjectInstance:* = ClassUtils.newInstance(classToInstantiate);
	return myObjectInstance;
}

INSTANTIATE AN OBJECT FROM IT’S CLASS NAME (a String like “com.domain.Person”)

import org.as3commons.reflect.ClassUtils;
public static function instantiateUsingClassName(className:String):* {
	var classToInstantiate:Class = ClassUtils.forName(className);
	var myObjectInstance:* = ClassUtils.newInstance(classToInstantiate);
	return myObjectInstance;
}

RETRIEVE NAMES OF ACCESSOR METHODS FOR A GIVEN CLASS

public static function getStaticAccessors(classOfInterest:Class):Array {
	var type:Type = Type.forClass(classOfInterest);
	var accessors:Array = type.accessors;
	return accessors;
}

RETRIEVE NAMES OF PROPERTIES (CLASS ATTRIBUTES) FOR A GIVEN CLASS

public static function getProperties(classOfInterest:Class):Array {
	var type:Type = Type.forClass(classOfInterest);

	var nonstaticProperties:Array = type.variables;
	var staticProperties:Array = type.staticVariables;

	var properties:Array = nonstaticProperties.concat(staticProperties);
	return properties;
}

RETRIEVE METHODS DECLARED BY A GIVEN CLASS

public static function getMethods(classOfInterest:Class):Array {
	var type:Type = Type.forClass(classOfInterest);
	var methods:Array = type.methods;
	return methods;
}

INVOKE A METHOD ON AN INSTANTIATED OBJECT

public static function invokeMethod(objectContainingMethod:*, methodName:String, parms:Array):* {
	var methodInvoker:MethodInvoker = new MethodInvoker();

	methodInvoker.target = objectContainingMethod;
	methodInvoker.method = methodName;
	methodInvoker.arguments = parms;

	var returnValue:* = methodInvoker.invoke();

	return returnValue;
}

Ultimately, the AS3 Commons Reflection library makes a few things easier or more intuitive. Moreover, it handles some complexities and bug work-arounds for you. But, the nuts-and-bolts are still basically using the the same techniques that I discussed in the upper-half of this post.

Enterprise Reuse of Flex Components and Classes

Wednesday, April 8th, 2009

In a simple Flex (SWF) application, all of the necessary components and classes are defined in a single Flex project. In the enterprise, however, you may want to refactor some of the components and classes into a separate library so that these common components and classes can be reused across multiple Flex applications (or project teams). The most common way to do this is to create a separate Flex project that will be used to create *.SWC file. Each Flex application will then be configured to link to this SWC. A SWC file is basically an archive of external components and classes, similar to a *.jar file in Java land.

There are various reasons that an enterprise might choose to decouple the common components and classes and put them in a separate, reusable SWC file:

  • * Reuse across Flex projects
  • * Reuse across Enterprise project teams
  • * Reuse across Enterprise applications
  • * Influence/enforce/decouple enterprise look-and-feel
  • * Improve application performance
    • – Startup time
    • – file size
    • – network bandwidth usage

Once the SWC file is created, you must decide how your SWF code will link to the necessary classes residing in the SWC. At a high level, Flex provides two linking options: Static linking and Dynamic linking.

STATIC LINKING (“Merged Into Code”):
When you use static linking, the compiler includes all referenced classes and their dependencies in the application SWF file. The end result is a larger SWF file. Obviously, a larger SWF file takes longer to download from the server. On the other hand, since all of the necessary code is contained in the SWF, it will load and run quickly. Keep in mind that the browser can cache the SWF file. So, if a given user will be accessing the same SWF file multiple times, the initially increased download time might be a reasonable trade-off for faster startup times.

DYNAMIC LINKING (“External” (or Runtime Shared Library “RSL”)):
When you use dynamic linking, the refactored components and classes are not included in (they are not compiled into) the application SWF file. Instead, the SWC file remains separate from the SWF. The result is a smaller SWF file size for the main application. The downside is that the SWC must be loaded at run time. In addition, the application loads the entire library (as opposed to static linking that can limit the linking to only the items that the SWF actually uses). This can result in slower startup times and greater memory usage.

Once again, however, client-side caching can play a role. The external SWC file can be cached and reused by multiple SWF applications. Each individual SWF will be smaller due to the exclusion of the common components and classes. If the enterprise has multiple SWF applications that will use the same SWC file, the cumulative size of the downloads might be lessened by using dynamic linking.

The enterprise will need to consider the tradeoffs of each option with respect to its situation and goals, in order to determine the best course of action. Components that will be reused across the enterprise will likely result in the creation of enterprise guidance and best practices. Components and classes whose reuse is limited to smaller divisions may need the flexibility to make the decision that is best for their particular sitation.

Using Flex to integrate with existing web sites

Thursday, April 2nd, 2009

In a couple of my previous posts, I discussed the integration of a Flex application into an existing web site. One post (link to post) discussed dynamically controlling the HTML real estate used by an embedded Flex application. The other post (link to post) gave a (hopefully) simplified view of code snippets that can be used to communicate between Flex and JavaScript under various scenarios. These were low-level, “how-to” posts. In this post, I’d like to explore some of the ways that this type of integration might benefit the enterprise.

In this particular situation, I was representing a company that had a new product/service offering. This offering is something that many existing E-Commerce web sites would like to add to their existing web site. Conceptually, this is a pretty common situation. However, integration is often more difficult to implement than it is to conceive.

That was not the case in this situation. Implementing this business offering by embedding a Flex application into an existing web site was embarrassingly easy. The integration instructions given to the E-Commerce site’s developers consisted of about 30 lines of text. This text consisted of the HTML Object/Embed tags and the JavaScript functions that the E-Commerce site’s developers needed to copy and paste into their web page. Beyond copying and pasting this text, all the E-Commerce site’s developers needed to do was to modify the JavaScript return values with the values from their web page.

They did not have to change any code on their server. They did not have to change the flow of their web pages. The Flex application that we provided them handled the external-domain server communication. We did not have to work-out the details of how the customer’s servers would access our servers and our services. We did not have to match technologies or protocols. The E-Commerce web site’s developers did not have to modify their server code to know, understand, and call our services.

This integration did not take months or years. This integration took something on the order of minutes or hours. I suppose you could say it took days, if you include time to arrange phone calls between the developers, etc.

Think about that. A new business offering was implemented in a matter of days.

Obviously, the company (or enterprise project team) providing the services, will have to build the backend for the services. But, they would have to do this anyway. The huge payoff is at integration time. And, if these services are used by many “clients” (either by selling the same offering over and over to many customers … or, within an enterprise, by allowing many project teams and existing applications to leverage your services), the cost-benefit analysis becomes compelling. Moreover, the more you can shrink the integration time, the easier it becomes to close a deal. In corporations, various levels of the hierarchy often have different levels of budgetary decision-making power. The lower the integration cost, the fewer levels of approval you will need to close a deal.

Admittedly, this was a specific type of business offering. It clearly does not replace all other forms of integration. As with any architectural tool (or software design pattern), you still must choose the best solution for a given challenge. There are many places where SOA, RESTful Web Services, XML, etc. will be the better solution. But, when this type of solution fits, it can really payoff!

Dynamically modifying the HTML space allocated to a Flex Application

Saturday, March 28th, 2009

If you need to integrate a Flex application into an existing web page, you will probably want control over the amount of space that the Flex application uses on the web page. If the Flex application size never changes, you can simply set the height and width of the Flex application in the HTML code (in the Object and Embed tags). However, if the Flex application size is dynamic based upon user interaction, you will may want the HTML space allocated to the Flex application to change as the Flex application size changes. The purpose of this post is to show how this can be done.

The following Flex application has an “Add Fields” button. If you click that button, two things will happen. First, the “Add Fields” button will be removed. Second, a TextArea and another button (“Remove Fields”) will be added. This behavior will cause the height of the Flex application to grow. The Flex application will make a JavaScript call to the containing page to dynamically change the space allocated to the Flex application.

Similarly, if the “Remove Fields” button is clicked the height of the Flex application will shrink. So, again, the Flex application will make a JavaScript call to the containing page to dynamically change the space allocated to the Flex application.

In order to accomplish this, we first need to insert our Flex application into the containing HTML page:

<OBJECT classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
	codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab
#version=6,0,40,0"
	WIDTH="1" HEIGHT="1" id="mySwf" scrolling="no">
	<PARAM NAME=movie VALUE="FlexibleGorilla.swf">
	<PARAM NAME=quality VALUE=high>
	<EMBED src="FlexibleGorilla.swf"
		quality=high
		scrolling="no"
		WIDTH="1"
		HEIGHT="1"
		NAME="mySwf" ALIGN="" TYPE="application/x-shockwave-flash"
		PLUGINSPAGE="http://www.macromedia.com/go/getflashplayer">
	</EMBED>
</OBJECT>

Next, we will add the following JavaScript function to the containing HTML page:

function updateSwfSize(myHeight, myWidth) {
	var flexibleGorillaSwf = document.getElementById("mySwf");
	flexibleGorillaSwf.height = myHeight;
	flexibleGorillaSwf.width = myWidth;
}

Then, in the Flex application, we will call this JavaScript function everytime the Flex application size changes. Here is the Flex code used in the example application:

<?xml version="1.0" encoding="utf-8"?>
<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" width="100%" height="100%"
							creationComplete="create()">

	<mx:Script>
		<![CDATA[

			private function create():void {
				updateSwfSize();
			}

			private function addFields():void {
				this.addButton.visible = false;
				this.addButton.includeInLayout = false;

				this.myTextArea.visible = true;
				this.myTextArea.includeInLayout = true;
				this.removeButton.visible = true;
				this.removeButton.includeInLayout = true;

				updateSwfSize();
			}

			private function removeFields():void {
				this.addButton.visible = true;
				this.addButton.includeInLayout = true;

				this.myTextArea.visible = false;
				this.myTextArea.includeInLayout = false;
				this.removeButton.visible = false;
				this.removeButton.includeInLayout = false;

				updateSwfSize();
			}

			private function updateSwfSize():void {
				this.validateNow();

				var newHeight:Number = this.myVBox.height;
				var newWidth:String = "100%";

				if (ExternalInterface.available) {
					ExternalInterface.call("updateSwfSize",
								newHeight,
								newWidth);
				}
			}

		]]>
	</mx:Script>

	<mx:VBox id="myVBox" horizontalAlign="center" width="100%">
		<mx:Label text="Dynamic Sizing Example" />
		<mx:Button id="addButton" label="Add Fields" click="addFields()" />

		<mx:TextArea id="myTextArea" text="FlexibleGorilla.com"
					width="90%" height="100"
					visible="false" includeInLayout="false" />
		<mx:Button id="removeButton" label="Remove Fields"
					click="removeFields()"
					visible="false" includeInLayout="false" />
	</mx:VBox>

</mx:VBox>

Flex JavaScript Communication

Thursday, March 26th, 2009

I was recently developing a Flex application that needed to be integrated into an existing e-Commerce site. As part of the integration, I needed to communicate information between the Flex application and the containing HTML / JavaScript page. I don’t believe I’ve ever seen a web site that put together all of the various scenarios that I wanted in one place. So, I put together an application that contains small examples of each scenario that I was interested in. I thought it might be helpful to post these simple examples for others.

Presenting Summary-Detail Content

Monday, November 3rd, 2008

I was recently working on a task with Jon Rose (Jon’s Blog). We basically needed to implement the typical summary-detail functionality.

At a high level, we needed to show a DataGrid containing a list of items, along with some summary information about each item. The user would then select the item that they wanted to work with. At that point, we would remove the summary list and display the details of the item.

Removing the summary list allowed us to save screen real estate by removing now-irrelevant information (the user no longer needed to see the items that they did not select). However, this also meant that we were no longer displaying the summary information about the item that the user did select.

Although the summary information is typically present in the detail section, it is usually preferred that it also be presented as a header or title above the details. We could have created a Label to display this header/summary information. However, we already had a DataGrid row that displayed exactly what we needed. Furthermore, at this point, the user is already accustomed to seeing the summary data in this format. We wanted to keep the flow from summary-view to detail-view as obvious as possible.

What we really wanted was to keep the summary DataGrid, but shrink it to only show a single row. That single row should only show the item that the user had selected. We tried setting the row count to 1 and scrolling to put the selected item in view. But, that led to dealing with a scrollbar and some other annoying issues.

What we decided to do, instead, turned out to be much more simple (and, in hindsight, seemingly obvious!). Instead of trying scroll a DataGrid to the proper item, we created a filter to eliminate everything except the selected item. At that point, the DataGrid would only contain one item (the selected item). Thus, we could set the DataGrid’s row count to 1, and not have any of the other issues (scrollbars, etc.). Here is an example:

This behavior allowed us to keep the selected item’s summary information available in the form that the user was used to. It avoided the creation/maintenance of another way of displaying the summary information. It also allowed us to reclaim screen real estate. And, it was simple.

The remainder of this page discusses the code behind the example. I have omitted things like widths and resizing effects in an effort to simplify the conversation. First, we create your basic DataGrid:

<mx:DataGrid id="stockDG" dataProvider="{this.stocks}" itemClick="selectStock(event)">
	<mx:columns>
		<mx:DataGridColumn headerText="Company Name" dataField="companyName" />
		<mx:DataGridColumn headerText="Symbol" dataField="symbol" />
		<mx:DataGridColumn headerText="Exchange" dataField="exchange" />
		<mx:DataGridColumn headerText="Industry" dataField="industry" />
	</mx:columns>
</mx:DataGrid>

In addition, we will create a “details” section that will initially be invisible:

<mx:VBox id="viewDetailVbox" visible="false" includeInLayout="false">
	<mx:HBox width="100%" height="100%" backgroundColor="#F2F1F1">
		<mx:Label text="Company" />
		<mx:TextInput id="companyDetail" />
		<mx:Label text="Symbol" />
		<mx:TextInput id="symbolDetail" />
	</mx:HBox>
	<!-- ... (continue adding details fields) -->
</mx:VBox>

We will also create some buttons to allow the user to either update the data with any changes they made in the details section … or to cancel any changes they may have made.

<mx:HBox id="buttonsBox" visible="false" includeInLayout="false">
	<mx:Button label="Update" click="updateSelectedStock(event)"/>
	<mx:Button label="Cancel" click="closeSelectedStock(event)"/>
</mx:HBox>

When an item in the DataGrid is clicked, the selectStock(event) function will be called. Here is that code:

private function selectStock(event:ListEvent):void {
	this.selectedStock = Stock(stockDG.selectedItem);
	stockDG.selectedItem = null;

	filterArrayCollectionToSelectedItemOnly();
	collapseDataGridToOneRow();
	displayDetailsOfSelection();
}

And, here are the functions that are called by the selectStock(event) function:

private function filterArrayCollectionToSelectedItemOnly():void {
	//assign the filter function to use
	this.stocks.filterFunction = filterStocksToSelectedItemOnly;

	//run the filter
	this.stocks.refresh();
}

private function filterStocksToSelectedItemOnly(item:Object):Boolean {
	var thisIsTheSelectedItem:Boolean = false;
	if(item == this.selectedStock) {
		thisIsTheSelectedItem = true;
	}
	return thisIsTheSelectedItem;
}

private function collapseDataGridToOneRow():void {
	stockDG.rowCount = 1;
}

private function displayDetailsOfSelection():void {
	this.companyDetail.text = this.selectedStock.companyName;
	this.symbolDetail.text = this.selectedStock.symbol;
	//... (continue setting remaining values)

	showDetailsAndButtons();
}

If the user wishes to return to the summary list (by clicking either the Update or Cancel button), we will reset the DataGrid to contain all of the items by removing the fiter, calling refresh() on the collection being used by the dataProvider, and setting the rowCount to the number of items in the list. In addition, we will remove the details section and the buttons from display.

private function closeSelectedStock(event:Event):void {
	this.selectedStock = null;
	this.stocks.filterFunction = null;
	this.stocks.refresh();
	stockDG.rowCount = this.stocks.length;

	hideDetailsAndButtons();
}

Finally, here are the two functions that hide and display the details section and the buttons:

private function showDetailsAndButtons():void {
	viewDetailVbox.visible = true;
	viewDetailVbox.includeInLayout = true;
	this.buttonsBox.visible = true;
	this.buttonsBox.includeInLayout = true;
}

private function hideDetailsAndButtons():void {
	viewDetailVbox.visible = false;
	viewDetailVbox.includeInLayout = false;
	this.buttonsBox.visible = false;
	this.buttonsBox.includeInLayout = false;
}