The Amazon Web Services Developer Connection recently published an article I wrote for them called, “Hosting Flex Applications and PHP Services with the Zend Framework in Amazon EC2″. Naturally, I’m the last person to find out about these things, so you may already know about this. The purpose of the article is to assist RIA Flex and Zend PHP developers in getting their apps up and running in Amazon’s Elastic Compute Cloud rather than via the typical paradigm of hosting on a physical server or cluster of servers.

Ironically, I found out it was published already from a mass email that showed up in my inbox from Amazon Web Services. The purpose of this massive email blast was to announce the 3rd annual  AWS Start-up Challenge, but I scrolled down and found a promotional piece for my article under “Developer Resources”. It seems that publishers are just unaware of the fact that authors like to know when their material has been published, regardless of what the publishing medium is.

Anyway, this article took me weeks in research, and only six hours to write once I finally had it all figured out. I went through at least one hundred and fifty different ways of setting up and configuring an Amazon EC2 cluster to run a Flex application that communicated with PHP services created with the Zend framework on the server side. This is worth keeping in mind when reading the article. My objective when I wrote the article was to find the simplest method of setup and configuration, then base my tutorial on that, which I did. It is worth noting when reading the article though, that it describes only one step-by-step way of getting things up and running, but its not the only way. At the same time, I butchered my setup and configuration many times while in pursuit of the easiest possible way to run a Flex app on EC2.

With that in mind, if you haven’t worked much with AWS and the Elastic Compute Cloud yet, I strongly recommend following the tutorial in the exact step-by-step order that is provided until you become more familiar with it.

The most important thing I would like to point out is that this is my fourth article for AWS, and the more I’ve gotten to know the Amazon “Infrastucture as a Service” and how it all ties together, the more I see an incredible opportunity for businesses of all sizes to significantly reduce their IT costs.  As businesses begin realizing this, more and more developers that know AWS will be needed, so if I may be so bold as to provide some advice if you are a developer that is fairly new to Amazon Web Services, its this:

Learn AWS, and learn it yesterday.

This article serves as a great starting point for developers of any type, and I’m not just saying that because I wrote it. Seriously,  I’ve saved you an insane amount of time by figuring out the best way to setup EC2, and then described my findings in a step-by-step tutorial here so you can get up and running in minutes, not hours, so its definitely worth a look. Your clients will undoubtedly appreciate you for the money they end up saving on hosting costs thanks to you. Click the image below to be taken straight to the article on the AWS web site.

Cheers!

Click to view the new article on hosting Flex and Zend apps in the Amazon Cloud

Possibly Related Posts:

• FlashCamp is coming to Phoenix Dec. 4th – Early Bird Registration
• Flex 4 Features for Creating Software as a Service now on IBM developerWorks
• Discover the Power of Flex and CSS – on IBM developerWorks
• “Flex 4 in Action” (Early Access Edition) Now Available!
• Adobe Flash Builder 4: Data-centric Features for PHP (PHPBuilder.com)

The Flex documentation on the UIComponent life cycle is rather difficult to understand, and so I came up with what I felt was an easier and more logical way of describing the process. I felt this might be useful for those who are interested in creating custom visual components in Flex that extend the UIComponent class. Creating custom components without having a solid understanding of the functionality that is abstracted within the Flex framework in regard to how it lays out UIComponent objects will likely result in design decisions that are inconsistent with the Flex Framework, which could potentially lead to a frustraing and seemingly uphill battle between the developer and the framework.

The following flow diagram represents the process that is abstracted within the Flex framework when the addChild() command is made to create and make a visual component visible on the stage, or when the properties of the component and/or it’s parent change (like a new data update for example):

Life Cycle of a Flex UIComponent

Note that if that is a little hard to read, you can click on it and it will brink up a pdf version. This is identical to what is said in the Flex documentation, it is just a lot easier to understand for those of us who appreciate visual representations of processes that are comprised of many steps. It is just easier to follow.

You will notice toward the bottom the diamond shape, which represents a decision that has to be made. The thing to understand here, is that additional components may be going through this same process simultaneously, thus affecting the layout properties of each other. An example might be the resizing of the parent window. The invalidation methods in essence, act as a sort of “queue” so to speak, so the actual stage ends up redrawing just once even though a number of things may have changed. The point at which the UIComponent makes the decision on whether or not to re-render is sort of like it is checking itself to make sure that it is ready before becoming visible. If a number of visual properties have been set on it or something else changed again that forced the invalidation methods to be called again on the components, it re-runs the commitProperties(), measure(), layoutChrome(), and updateDisplayList() methods again, and will continue to do so until it knows that it is now ready to be seen, at which point it’s visible property is set to true.

The speed at which this all happens and the overall architectural decisions with regard to how the stage is drawn in a Flex app and the way the visual elements are laid out, is truly quite impressive, and worth studying in further detail if you are interested in learning more about the design patterns used in the Flex framework to make it work the way it does. Although Flex does have its flaws, this is an example of how the framework abstracts a lot of functionality quite elegantly for the developer.

Possibly Related Posts:

• Flash Camp Phoenix a Huge Success
• Building Custom Components with Flex 4
• Understanding the Flex 4 Spark Component Architecture and how to Build Custom Components with the Flex 4 SDK
• Peter deHaan on using Spark controls in Flex Gumbo
• Understanding Flex Communication Protocols

I came across this article on O’Reilly’s InsideRIA site by Moxie Zheng and was surprised to find some similarities between the architecture the author describes and the architecture that I am seeking to create. The good stuff begins under the subtitle about halfway down, labeled “The Architecture”, where Moxie Zheng discusses his use of an Event Bus the same way as I have implemented it into my own architecture.

One thing I wanted to point out, and my reason for mentioning it here, is that below that he describes what he refers to as “The Widget Programming Model”, something I have not come across before. When it comes to enterprise Flex apps, we’re usually dealing with multiple user levels. In other words, the interface must look different based on the conditions under which the user is accessing the application. These conditions are often set by an external database server that handles user management, in which user types and their respective permissions may be set in a specific table. Then each user is assigned a user type, or in some cases, multiple user types. Therefore, the client side AIR or Flex application must construct itself “on the fly” so to speak, based on the group of configuration settings that it is handed from the server side. I like this widget-based programming model because it takes custom component development to an even more loosely coupled level, making it virtually impossible for the developer to creat interdependencies within an application due to the nature under which that particular widget must be programmed. It’s loose-coupling at it’s finest.

These “widgets” are compiled as separate swf “mini-applications” if you will, encapsulating and isolating code that handles a specific way of viewing data on the server. As I wrap my brain around the possibilities with this design pattern, I can’t help but think that for applications that are powered by specialized services, a “widget registry” could in fact be formed on the network (talking about AIR applications only now). Therefore, if a user was installing the application based on a certain set of credentials, a call to the network registry would return a set of “widgets” that should be installed along with the main application, thus defining how that particular user views the application interface. This concept could easily apply to the branding of an application based on the web site it was downloaded from, as a simple example.

Possibly Related Posts:

• Second Generation Micro-architectures, Part 1: The Swiz Framework
• Open source clientside RIA frameworks for SaaS
• Using the Zend Framework to take some wind out of AIR
• Traditional Project Management vs. Agile Development with Software as a Service projects
• Data-centric Adobe Flash Builder development with the Zend Framework

This posting is in response to the comment left HERE, which I felt necessitated its own separate post and discussion. Before I start, I must first at least suggest that some research be conducted on Cairngorm, PureMVC, and Fireclay and allow yourself to draw your own conclusions with regard to how they fit into the bigger picture of your enterprise Flex or AIR project.

The first question that Jeff asks in his comment is if I can post a screenshot of a Flex directory structure of an enterprise application. My first thought was that I would make Jeff’s head spin if I did that due to the fact that every enterprise application I’ve worked on has had its own unique set of requirements, and differentiating the parts that could be considered as “standards-based” from those parts that were specific to the application (like a package titled “http” for RESTful services, for example) would not be of any assistance and would leave Jeff (and many others) right back where he started.

So instead, I drafted a diagram (figure 1) that so far seems like it could potentially be the bigger, better, faster, stronger framework for enterprise Flex development. Note that in order to address Jeff’s specific request, I made the diagram to be a sort of hybrid between a directory structure and a design pattern. This is the 50,000-foot view of the new architectural framework that I’m working on. Each rectangle represents a package or directory. Additionally, each layer is in fact it’s own library, with the exception of the Application Layer, which serves as the gateway to the application, and thus it is constructed as a standard Flex project and holds the primary MXML application file.

New Enterprise Flex Application Architecture

Notice that the different layers are completely unaware of each other. In fact, it is impossible, because if you attempt to add one of the libraries as a reference in the properties of another library, Flex Builder should throw a bunch of random “unknown errors” at you. This is because you have a cyclical redundancy in the build of the Application layer project (note that I am also addressing one of Jeff’s other points, which was to elaborate on the concept of separation of layers in the form of libraries).

In the diagram above, the application layer (which is the ONLY layer created as a Flex or AIR project, not a library project) holds references to the Business Layer, the Component Layer, and the Behavior Layer, which are all libraries and compile as separate swcs. During development however, I suggest you do not add the swcs to the libs folder of the Application Layer project, but rather add them as project references. Then, each time you build, you will notice that Flex Builder automatically recompiles each swc and adds them to the libs folder of your Application Layer project, as long as you have specified the libs folder in the “libraries” panel of the project properties. If you don’t do it this way, you will likely end up with “stale data”, meaning you’ve got an old swc from a previous build of one of your libraries, but the code in that library has been changed.

I must mention that the diagram above is merely a prototype, and has unfortunately not yet been put into practice. Therefore, I am open to feedback on it because, having been dissapointed in the past by Cairngorm and PureMVC, this is what I will be using for my next 2 enterprise level Flex development projects. At the same time however, this is only my first draft. The reason I drafted a diagram of a structure that has not yet been used in a real environment is for the simple fact that I would be doing Jeff – and everyone else that reads this – a disservice by showing you a diagram that is based on a past enterprise level project. This is because with each project, there were architectural decisions made that led to problems later. This is pretty typical when a new language is brought into the enterprise development space, and is to be expected.

The bottom line is that Flex and AIR are still very immature, and those of us who are using these technologies for enterprise development are still learning from our mistakes. Ultimately, we do our best and implement the design patterns we know, often from J2EE patterns since it bares the strongest resemblance to the Flex architecture. However, Flex (and AIR, and AS3 too for that matter) are unique in that they are event-driven. Therefore, a somewhat unique approach must still be taken to an enterprise Flex application that cater to it’s differences. This is why Cairngorm has a breaking point. Once an application becomes massive in size, a Cairngorm-based app turns into spaghetti-code and it becomes nearly impossible to track down events, event handlers, request-response handlers, etc.

Some Important Points

There are a few things I should point out about this initial draft shown above. First, it may not be immediately apparent, but it is in fact based on the MVC (model-view-controller) design pattern. The reason it is hard to tell at first glance is because we’ve got quite a few additional micro-patterns in here. For example, the “event bus” is based on the publish-subscribe design pattern, and I attribute Shashank Tiwari and his work on Fireclay for this idea. Shashank is developing Fireclay as an alternative to Cairngorm and PureMVC for many reasons, some of which I previously stated in regard to Cairngorm. The difference however, is that in the “bindingDictionaries” package – which is probably the most important to make note of in the application layer – is where the mapping of events to their respective handlers occur. This partially breaks away from how the publish-subscribe pattern is being used in Fireclay.

The relational size of the Business Layer/library in the diagram does not do justice for how large the business library will likely get in an enterprise Flex application. There is a lot of abstractions that must be made here and a significant amount of internal processing within this library. One of these abstractions I should point out is that the “model” package would contain a package within it called “vo” or “valueObjects”, which would basically hold references to all of our data as it is captured from the server.

Ultimately, there is a lot going on here and again, this is an over-simplified, high-level overview that encompasses my initial ideas for the architectural design pattern that I am working on developing right now. The important thing about it is that it resolves the many problems that I have seen come up in enterprise Flex development, whether it was a custom architecture being used or Cairngorm, or PureMVC, the problems that arise are consistent.  That is not to say however, that this is an end-all, be-all solution by any means….in fact, it is still just a baby.  However, I will soon find out where the weak points are as I continue to draw out additional diagrams to accompany this first iteration in my efforts of constructing a solid and robust architectural “best practices” standard for Flex enterprise development…well, at least for my own projects:)

Overall, I think the community is in great need of something that supercedes what is currently out there considering Flex and AIR are being used on such a grand scale all of a sudden for enterprise RIA development. I’m not sure if this is the start of something that will fulfill this need for the community, but at the very least it will give me what I need to make my future enterprise Flex projects successful.

There is one last point that Jeff makes in his comment, as follows:

“I’m struggling with the separation/inclusion architecture of these apps because most of them will have interdependencies – security, model, commands, etc.”

The answer here is to simply remove these interdependencies.  If this seems like a ridiculous and nearly impossible solution, then I might suggest that this project will be a nightmare for you until you decide on an architectural solution for this project and just accept the fact that you are going to have to hack away at the code in order to remove the interdependencies. In some cases however, interdependencies are ok. The simple rule with the solution that I have diagrammed above is that if the class doesn’t fit into any one of the 3 libraries, then it belongs in the Application Layer.

I hope this helps.

Possibly Related Posts:

• Second Generation Micro-architectures, Part 1: The Swiz Framework
• Using the Zend Framework to take some wind out of AIR
• Thinking Outside the IDE: Ideas for Flex Architects
• Micro-architectures for Flex Enterprise Development
• Understanding Flex Communication Protocols

Recently I was charged with the responsibility of creating a very complex visual interface in Flex that looks more like something you’d expect to see built with Flash because of the animation and 3D effects. Flex was clearly the better choice for developing this piece of the application, but I learned a number of things regarding the limitations of Item Renderers, particularly those having to do with the Flex TileList component.

The Requirement
The primarily component needed to display a tiled list of objects that represented a group of media objects. Each item renderer in the TileList had to have 3 images, each representing a different piece of media, and when the user hovered over one of the items, a parallel effect that combined one Zoom effect, 3 Move effects, and 2 Rotate effects. The top image ultimately needed to zoom in and have a DropShadow filter applied to it to give it a 3D-like effect, and the middle and bottom images needed to fan out to the left and right using the combined rotate and move effects on each one.

Getting the Data
Getting the data in the first place was a task in and of itself. My first several iterations of the code involved a lot of looping through the massive collection of media “packages” that is returned from the server, in order to get the sets of preview images from each media package object that i needed for the item renderers. I eventually came to realize that I could cut the amount of code I was using for this thing into a fraction by simply using the standard , with the data provider set to this massive collection of objects being sent from the server. This, however, required a complex and well-planned item renderer component written in ActionScript. The item renderer component extended the Flex TileListItemRenderer class and implemented the IListItemRenderer and IDropInListItemRenderer interfaces.

In this solution, each Item Renderer automatically receives one of the media package objects from the large collection that is sent from the server. This functionality is already built into the ListBase, so all I needed to do was find the array of images that from the object, then loop through the array and determine the “role” that each image should play in the item renderer (eg. top image, middle image, or bottom image) and discard anything else that I didnt need.

The Major Problem
The big problem I ran into, was the fact that the complicated effects that i built for the mouse over and mouse out required the item renderer display object to overlap the surrounding display objects in the tilelist. This, unfortunately, was completely impossible, and after studying all of the classes that TileList is extended from and how the TileList component automatically lays out the objects within the list, I found that it was impossible to prevent clipping of the images from occurring when the effects were generated.

The Quick-and-Dirty Solution
Due to time constraints, I needed a solution that i could implement quickly, and as long as it looked pretty, we were ok. In other words, an elegant hybrid component was simply not an option. I should also note that other possible solutions, like using a repeater with a Grid container, were not options either for reasons that are beyond the scope of this article/blog.

I created an mxml component based on the Canvas container that took 3 images as properties, dropped shadow filters on the images and included 2 parallel effects for the over and the out events. When the mouse over (or mouse out) occurs on an item renderer, this additional component that holds the effects is added to the stage with this.parentApplication.addChild(_effectContainer). So essentially, a new iteration of the item renderer that fired the event is being created as an overlay and the effect can then play and is free to run over any display objects in its way, since it is ultimately automatically added to the stage with an index that is higher than all other display objects on the stage.

In order to get this right however, the positioning of this canvas has to be pristine. In other words, when the new child (the effect container) with the duplicated images is added to the stage, the x,y coordinates of the initial state of the image stack (which is with only the top image displayed, assuming the other two images are of the same size and have the same x,y values) must be EXACTLY the same as the x,y position of the item renderer that generated the new instance of the display object responsible for displaying the effects. This ultimately makes it look as if the animation is playing on the actual item renderer, when in fact the item renderer is merely still lying directly beneath it’s double.

To be honest, the final product is pretty bad-ass and gives a flash-like quality to a data-driven Flex UI component. However, this is not the most elegant solution, as the ideal thing would be to create a hybrid TileList-like component that includes DYNAMIC layout constraints on each item renderer. Therefore, the component would automatically recognize that a display object inside of one of the item renderers was pushing on the boundaries of the container that was allocated to it and resize itself automatically until the animation stopped by placing calling super.invalidateProperties or super.updateDisplayList on the UIComponent class on each ENTER_FRAME event until the internal display objects of the item renderers stopped pushing on the layout bounds. There is a little caveat to this however, and that is – resizing the layout constraints of the item renderer must NOT change the layout of the component as you would expect. In other words, we could suspect that implementing such functionality into a hybrid TileList component would by default push the other item renderers around to compensate for the renderer that was resized. This assumes however, that we do NOT want the item renderer to overlap the surrounding renderers, which in the case of this requirement, is untrue. When the user rolls off the item renderer’s effect double, the rollover animation should basically play in reverse and then simply remove itself from the parent’s display list. Thus, the original layout of the TileList is never changed by the effects rendering.

My feeling is that we will build such a component eventually, probably for a future version of this application, but we’ve got a deadline to meet right now, and sometimes making the right business decision means quick and dirty is the answer.

As much as I’d love to actually show the code for this view state that I have described here, I must respect certain nondisclosure and intellectual property rights and restrictions considering the nature of the application we are building. However, I will provide a generalized code example of a specific element described in this article if there is something in particular that you would like to understand in greater detail by actually seeing it. I am very quick to respond to comments, so feel free to ask if there is anything in particular you would like to see.

Possibly Related Posts:

• Flash Camp Phoenix a Huge Success
• Building Custom Components with Flex 4
• Understanding the Flex 4 Spark Component Architecture and how to Build Custom Components with the Flex 4 SDK
• Peter deHaan on using Spark controls in Flex Gumbo
• Understanding Flex Communication Protocols

One of my biggest issues with the Flex Viewstack element is the lack of built-in transitions to choose from. So in this demonstration, I will show you how to create your own. We will first create a reusable animation factory class that we can call from anywhere in our application. Then, I will demonstrate how we can put the animation factory to work by creating a slide transition for a viewstack component. Note that Flex has a built in Slide object, and if you don’t mind mixing up your ActionScript behaviors with your MXML display, then that is also a viable option worth looking into for accomplishing the same end result. Just like anything you’ll find on this site though, we want to build abstraction and reusability into our code.

Step 1: Create the Animation Factory

Our first step is to create the animation factory class. We can instantiate this object from anywhere in an application and call the animateTo method, passing it the x, y position that we want it to end at, and the duration in milliseconds that we want the animation to last.

ObjectSlider.as

package {

   import flash.display.DisplayObject;
   import flash.events.Event;
   import flash.events.TimerEvent;
   import flash.utils.Timer;
   import flash.utils.getTimer;

   /**
    * @author Dan Orlando
    */
   public class ObjectSlider
   {
        // The object being animated
	private var _target:DisplayObject;
	 // Each time an animation starts we record its start time
	private var _startTime:Number;
	 // The duration of the animation in milliseconds
	private var _duration:Number;
	 // Record the target's start position
	private var _startX:Number;
	private var _startY:Number;
	 //  Record the difference between the starting and ending positions
	private var _deltaX:Number;
	private var _deltaY:Number;

	public function ObjectSlider() { }

   // Starts an animation that moves the target object from its current
   // position to the specified new position over a specified period of time.
	public function animateTo(target:DisplayObject, toX:Number,
           toY:Number, duration:Number):void {
	   //store where the target was when the animation started
	   _target = target;
	   _startX = _target.x;
	   _startY = _target.y;
	   // calculate difference between target's start position
           // and final destination
	   _deltaX = toX - _target.x;
	   _deltaY = toY - _target.y;
	   _startTime = getTimer();
	   //store how long the animation should take
	   this._duration = duration;
	   //update target's position each time a screen update occurs
	   _target.addEventListener(Event.ENTER_FRAME, enterFrameHandler);
	}

   // Updates the target's position on each ENTER_FRAME event
	private function enterFrameHandler(event:Event):void {
	   var elapsed:Number = getTimer()- _startTime;
	   var percentDone:Number = elapsed/_duration;
	   if (percentDone < 1) {
	      updatePosition(percentDone);
	   }
	   else {
	      updatePosition(1);
	      _target.removeEventListener(Event.ENTER_FRAME, enterFrameHandler);
	   }
	}

   // Sets the position of the target object
	private function updatePosition(percentDone:Number):void {
	   _target.x = _startX + (_deltaX * percentDone);
	   _target.y = _startY + (_deltaY * percentDone);
	}

   }
}

Step 2: Create the MXML component
For our MXML display component, we will create a simple canvas that initializes a “helper” class that contains all of the behavior and functionality for the component in ActionScript. Note that when we instantiate the helper class, we pass it the current instance of our canvas component as a display object argument using the this keyword. We also place two left and right arrow buttons here, which we will use to move the viewstack back and forward by changing the selectedIndex value of the ViewStack when one of the buttons is clicked.

CustomCanvas.mxml

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml" width="750" height="550"
   creationComplete="init()">
   <mx:Script>
      <![CDATA[
      import com.danorlando.util.ViewStackHelper;

      private var _helper:ViewStackHelper;

      private function init():void {
         _helper = new ViewStackHelper(this);
      }
      ]]>
   </mx:Script>

// place additional mxml components that should not be part
// of the viewstack here, like buttons, labels, etc...
   <mx:HBox x="693" y="56" horizontalGap="5">
      <mx:Button x="64" y="13" id="backBtn" styleName="iconButtonBack"
         width="16" height="16"/>
      <mx:Button x="85" y="13" id="forwardBtn" styleName="iconButtonForward"
         width="16" height="16"/>
   </mx:HBox>
</mx:Canvas>

ViewStackHelper.as

package com.danorlando.util
{
   import com.danorlando.display.components.CustomCanvas;
   import com.danorlando.effects.animation.ObjectSlider;
   import flash.display.DisplayObject;
   import flash.events.MouseEvent;
   import mx.containers.ViewStack;

   public class ViewStackHelper
   {
      private var _parent:CustomCanvas;
      private var _viewStack:ViewStack;
      private var _currentIndex:Number;
      private var _slider:ObjectSlider = new ObjectSlider();

      public function ViewStackHelper(canvas:Canvas) {
            _parent = object;
            addListeners();
            createChildren();
      }

   // add event listeners to the forward and back buttons
      public function addListeners():void {
       _parent.backBtn.addEventListener(MouseEvent.CLICK, viewStackBack);
       _parent.forwardBtn.addEventListener(MouseEvent.CLICK, viewStackForward);
      }

   // create and add the viewstack and it's children
      public function createChildren():void {
         _viewStack = new ViewStack();
         _parent.addChild(_viewStack);
         _viewStack.selectedIndex = 0;
         _viewStack.x = 39;
         _viewStack.y = 72;
         _viewStack.width = 675;
         _viewStack.height = 402;
         var vsChild1:Canvas = new Canvas();
         _viewStack.addChild(vsChild1);
      // add other components and params to the 1st index/child here
         var vsChild2:Canvas = new Canvas();
         _viewStack.addChild(vsChild2);
      // add additional components and params to the 2nd index/child here
         var vsChild3:Canvas = new Canvas();
         _viewStack.addChild(vsChild3);
      // add additional components and params to the 3rd index/child here
      // get the first child that is about to be displayed in the viewstack
         var curChild:DisplayObject = _viewStack.getChildAt(_currentIndex);
      // set the x-position of the child to the x-pos of the viewstack + 600
         curChild.x = _viewStack.x + 600;
      // now slide the child into view
         _slider.animateTo(curChild, _viewStack.x-40, 0, 500);
      }

   // event handler for the back button in the parent container
      private function  viewStackBack(event:Event):void {
         if(_currentIndex > 0) {
            _currentIndex = _currentIndex - 1;
            var newChild:DisplayObject = _viewStack.getChildAt(_currentIndex);
         // set the x-position of the new child 600 pixels to the right
            newChild.x = _viewStack.x + 600;
         // use the animateTo method of our animation factory to slide the new
         // child into position
            _slider.animateTo(newChild, _viewStack.x-40, 0, 500);
         // set the new index
            _viewStack.selectedIndex = _currentIndex;
         // set the forward button to visible if it is hidden
            if (!_parent.forwardBtn.visible) {
               _parent.forwardBtn.visible = true
            }
         // if the _currentIndex property is 0, then hide the back button
            if (_currentIndex == 0) {
                _parent.backBtn.visible = false;
            }
         }
      }

   // event handler for the forward button
      private function viewStackForward(event:Event):void {
         // get the highest index value of the viewstack
         var lastIdx:Number = _viewStack.numChildren-1;
         if(_currentIndex < lastIdx) {
            _currentIndex = _currentIndex + 1;
            var newChild:DisplayObject = _viewStack.getChildAt(_currentIndex);
          // place the incoming child 600px to the left
            newChild.x = _viewStack.x - 600;
          // slide the new child into position using our animation factory
            _slider.animateTo(newFaq, _viewStack.x-40, 0, 500);
          // set the new index of the viewstack
            _viewStack.selectedIndex = _currentIndex;
          // make the back button visible if it is hidden
            if(!_parent.backBtn.visible) {
               _parent.backBtn.visible = true }
          // hide the forward button if we are at the last index
            if (_currentIndex == lastIdx) {
               _parent.forwardBtn.visible = false;
            }
         }
      }

   }
}

Ok, so we’ve got a few things going on here in the helper class. The first thing we do is set the Canvas object that was passed in the constructor to our local (i.e. private) canvas property which is of type CustomCanvas. We then add the event listeners to the forward and back buttons of the parent container – which is the Canvas object that was passed in the constructor – with the addListeners method. We then instantiate the ViewStack and add its children with the createChildren method. You will see the use of our animation factory with the call to _slider.animateTo. Notice that we are initially setting the position of the child off to the left or the right, depending on which button was clicked, then we slide the child into place. Lastly, in order to ensure that we never get a runtime error because the forward button was clicked when we were already viewing the last child, or the back button was clicked when we were already on the first child, we simply set the visible property to false for the respective button based on said conditions.

Possibly Related Posts:

• Flash Camp Phoenix a Huge Success
• Building Custom Components with Flex 4
• Understanding the Flex 4 Spark Component Architecture and how to Build Custom Components with the Flex 4 SDK
• Designing (RED)Wire, Part 3: Advanced Styling Methods for Enhanced User Experience with Adobe Flex and AIR
• Designing (RED)Wire, Part 2: Taking the User Experience from Concept to Production with Flex and CSS

I spent a large portion of this week learning a new technology based on a collaboration between Adobe and Zend Technologies for data communications and an unified workflow for PHP RIA developers. My assignment was to write up an article/tutorial on implementing the new technology into Flex/AIR applications. Since it is a new technology that has yet to be released to the public, the setup and configuration process was naturally a bit daunting. After I got it up and running though, I was pretty impressed with what this new technology offers. The article is set to be published initially at OnLamp.com immediately following the public announcement and release of this new technology. I will provide more details and additional information on getting up and running with this new technology here, but for now, mum’s the word.  :-)

Possibly Related Posts:

• Flash Camp Phoenix a Huge Success
• Best Drunk on Software Episode Ever
• Enterprise Flex and the Swiz Framework Architecture, Part 3: Using Autowire and Mediate
• “Flex 4 in Action” (Early Access Edition) Now Available!
• Designing (RED)Wire, Part 3: Advanced Styling Methods for Enhanced User Experience with Adobe Flex and AIR

For larger applications that have an ordered process by which objects are instantiated, you are sometimes required to position your objects on the stage using only Actionscript, at a certain time. For example, let’s say your business logic needs to gather all of its data and run through a series of tasks before the user interface can be displayed. It then must dispatch a custom event to notify the display layer that it is ready. However, you do not want display objects that are defined in your mxml to be instantiated prematurely, resulting in the infamous flex 1009 error, “Cannot access a property or method of a null object reference”. In this case, our best bet is to instantiate these objects through actionscript when the “ok, im ready now!” event is dispatched from our controller class. Let’s take a look at an example:

First, we’d want to add a listener on our controller for the “I’m Ready!” event, which we will call MODEL_INITIALIZED, like so:

private var _uiCtrl:UIController;

private function init():void {
     _uiCtrl = new UIController();
     _uiCtrl.addEventListener(ControllerEvent.MODEL_INITIALIZED, createDisplayObjects);
}

Here we assume that our UIController class has an event in it of type ControllerEvent, and dispatches the ControllerEvent.MODEL_INITIALIZED when it has completed all of its background work and is ready for the user interface to be displayed.

Our createDisplayObjects handler function would then look something like the following:

private function createDisplayObjects(event:ControllerEvent):void {
     createControlBar();
     createCanvas();
     createGrid();
}

Here we are simply calling a series of methods to create our display objects. The function takes event:ControllerEvent as an argument. If this is not included, we will get a runtime error that says “Expecting 0 arguments, received 1″.

Here is an example of what our display object instantiation methods would then look like:

private function createControlBar():void {
     var bar:CustomApplicationControlBar = new CustomApplicationControlBar();
     addChild(bar);
     bar.dock = true;
     bar.uiController = this._uiCtrl;
}

private function createCanvas():void {
     var canvas:Canvas = new Canvas()
     addChild(canvas);
     canvas.percentWidth = 100;
     canvas.percentHeight = 100;
     canvas.x = 10;
     canvas.y = 10;
}

private function createGrid():void {
     var grid:CustomDataGrid = new CustomDataGrid();
     canvas.addChild(grid);
     grid.x = 0;
     grid.y = 0;
     grid.width = 500;
     grid.height = 500;
     grid.dataProvider = _uiCtrl.gridData;
}

I should first point out that the example above is meant to provide a “real-world” example of what this might look like, so allow me to explain what is going on here. In the first method, createControlBar, we are instantiating a custom component that extends the Flex ApplicationControlBar component. The ApplicationControlBar component has a property called “dock”, which docks it to the top of the stage in such a way that it is always on top, and the stage’s 0,0 point is now directly under the ApplicationControlBar so no display object will ever get covered up by the control bar. Our CustomApplicationControlBar component has a property of “uiController”, which is the current instance of the UIController class. This gives our component access to the data model within the application.

The createCanvas method is pretty straight-forward and probably requires no explanation. The createGrid method however, has a few things going on. In this example, the CustomDataGrid component extends DataGrid. We are then adding this component to the canvas that we created above it. Lastly, we set the dataProvider property to an ArrayCollection, which was part of the data model that was created when the UIController was instantiated. Since we can access our entire data model through our UIController class, we can directly bind the dataProvider of our CustomDataGrid to any of the collections within our model.

Possibly Related Posts:

• Flash Camp Phoenix a Huge Success
• Building Custom Components with Flex 4
• Understanding the Flex 4 Spark Component Architecture and how to Build Custom Components with the Flex 4 SDK
• Peter deHaan on using Spark controls in Flex Gumbo
• Understanding Flex Communication Protocols

With all of the books that I’ve read on Flex and Actionscript 3.0 development, I find it interesting that none of them go into detail about the organizational structure of an enterprise level RIA application built with Flex. Perhaps Flex is still too immature and has not really evolved enough yet to write on such topics. Nonetheless, that is exactly what we are going to discuss in this article. More specifically, we will go into detail on how one might want to structure an RIA application that he or she expects to grow very large in size. In other words, we will pay particular attention to designing an application foundation that is scalable in nature.

In order to cultivate a development environment that caters to ultimate scalability, we must start by separating our code into clearly defined layers. By layering our code, we are able to entertain a high level of abstraction in the logic. Most RIA applications are split into 3 initial layers by nature: the server side logic and database, the client side logic (and database also if we’re working with an AIR app that uses a client-side DB as well), and the medium that is used for client-server communication. Here are two examples that come straight from the two big projects I am currently part of:

Project 1
Client-side: AIR desktop app & SQLlite
Server-side: Java/Jboss with MySql Enterprise
Client-server communication: Custom Java REST service and JVM (Java Messaging Service)

Project 2
Client-side: Flex application (runs through web browser)
Server-side: PHP (custom built PHP framework) & MySql
Client-server communication: AMFPHP/Remote Object, Flash Media Server

As you can see, this kind of layering is inherent to any RIA application by nature, but our focus is splitting the client-side logic further into an additional set of layers. It is important to note that this is generally what you want to be considering before starting any development work on the project. Of course, that’s easier said than done, which is why a large number of applications in any language are overhauled once or even twice a year because there just wasn’t enough scalability built into the previous version. Nonetheless, using this article as a resource when you first begin the design of a what could become a fairly large application will definitely put you a step ahead. The same also applies to smaller applications that require a lot of custom functionality (i.e. using the built-in flex components are not really an option).

Layer 1: The Business Layer

The business layer is the core of the client side application and is completely encapsulated in such a way that nothing is ever brough up to the user interface level. In other words, it is completely hidden and works entirely behind the scenes. It’s job is to feverishly work to make sure that the user interface always has the data that it needs, when it needs it. The business layer should include: the data model, a set of value object classes, an event model, its own internal services layer for communication with the client side database (if applicable) and the server, and a primary controller class for the user interface to hook into. We make this layer its own flex library project because it has no dependency on display whatsoever.

Layer 2: Custom Component and Behavior Layer

This is the “middleman” of our user interface, and is often composed of classes built with the factory design pattern. Its job is to listen for events fired from the business layer and instantiate it’s built-in event handlers, which may be to display a popup component, change the application state, or shout out commands to particular components like “do this animation!”, or “move to here and show this data!”…you get the idea. Things you might see in the component and behavior are: custom actionscript components, use of the drawing api, programmatic animation and movement, programmatic skinning, and factory classes that ultimately control all of the behavior of the display components. We create a separate Flex library project for this layer as it is not directly part of the display. Note that we can even place some of our mxml components in this layer and still keep it as a separate library because we can just call those components from the display layer if we wanted to. Whether or not you do this however, largely depends on the size of the application. Otherwise, I suggest keeping all of the mxml in the display layer.

Layer 3: The Display Layer

This is what we can refer to as “the UI layer”, in that it defines our user interface. This is typically where you will find most, if not all of the mxml files. This is our Flex or Air application project, and it includes the business layer and component/behavior layer libraries by referencing them accordingly (see below, under “Setting it Up”). Very little actionscript should be needed in these mxml files, as they are like “dummy” files that simply define the layouts of the different states of our application. They are more like “wireframes” than anything, as our actual design should be defined either in CSS stylesheets or on layer 2 for programmatic skins. My suggestion is also to do some research on the flex component plugins for Illustrator, Flash, Photoshop, and Fireworks if you haven’t already. Using these nifty little tools that Adobe created for us, we can let the design application compile a single swf for us after you’re done creating your skin, with all of the images inside of that single swf file, then import it into Flex Builder by going to File->import->skin artwork and selecting the skins you want to import. This will save you a considerable amount of time, and allows you to take the abstraction of your application one step further by separating the design from the layout on the display layer.

Setting it Up

When you setup the layer 1 and 2 projects, when you go to File – new flex project, make sure that “flex library project” is selected in the configuration window that pops up. When you setup the Display Layer project (I would suggest choosing a different name than “Display Layer” by the way, but that’s up to you), make sure that Flex Application is selected. Then go to the project properties for the Display Layer project in flex builder, click “Flex Library Build Path”, select the Library Path tab, and click “Add Project” (as opposed to add swc) and add the layer one and two libraries that way. I suggest adding swc’s or adding a swc folder (which you then place your swc libraries into, usually called “lib”) only for components or libraries that are complete in their entirety and you will not be making changes to. The “Crypto” or “Corelib” swc libraries offered by adobe for data serialization and data encryption are examples of when you would add a swc or swc library folder (and place your swcs inside of it, which is the best way to go). That is not to say that you can’t use the swc’s for your libraries, as whenever the swc is recompiled, it will automatically be updated in the main application project, but Flex still has some bugs with regard to this functionality, so my recommendation would be to steer clear of it for now unless the library does not need to be modified.

Final Thoughts

It is worth noting that this structural pattern caters very nicely to multiple-developer environments, and each layer could even be split further into additional libraries, where each developer has their own library project, and because so little development is really happening on the display layer (it should only account for maybe 5 to 10% of the application at most), developers rarely run into each other because they are mostly working on their own library project. Each developer can additionally test their code by running the main application mxml file in the Display Layer application locally, which has all of the libraries referenced. Source control is obviously critical for this to work though.

Hopefully this article sparked some new ideas, and feel free to leave a comment describing how you might alter this structure with your own ideas and design patterns.

Happy Flexing!

Possibly Related Posts:

• Second Generation Micro-architectures, Part 1: The Swiz Framework
• Flash Camp Phoenix a Huge Success
• Using the Zend Framework to take some wind out of AIR
• Building Custom Components with Flex 4
• Understanding the Flex 4 Spark Component Architecture and how to Build Custom Components with the Flex 4 SDK

I had an interesting conversation this morning with a colleague, who is also a Flex/Actionscript developer, about how we end up using very little MXML when building enterprise level RIA applications. That’s not to say that we don’t leverage the classes that are encapsulated inside of the flex framework, but there is no question that 90% of our code is written in Actionscript. The other 10% are simple MXML files that have no purpose other than to instantiate our Actionscript components on the stage. I think as the Flex developer grows, evolution has it that he or she would move toward the use of Actionscript more than MXML.

A comment I made during this converstaion was that Flex/MXML was great for building little RIA “widgets” that use the built in flex components, which can all be skinned to your heart’s desire. However, it is definitely not well-suited for enterprise level RIA applications because there is too much flexibility (pardon the pun), where we often see programmers literally taking a framework (flex) and language (actionscript 3) that essentially forces you into some form of an object-oriented design, then flipping it on its back to where we see these mxml files that are reminiscent of procedural programming, complete with plenty of inline Actionscript and random switches from mxml to straight Actionscript and back again. This tends to be mostly due to a lack of knowledge on using events and multiple design patterns in a larger application, which takes a while to pick up.

Don’t get me wrong, Flex Builder is definitely the tool of choice for coding RIA applications, but I think the general rule of thumb is that any application that is more than just a “widget”, is going to end up about 80% – 90% Actionscript files and 10% – 20% MXML files. That’s a good way to tell right off the bat if an application is using abstraction and encapsulation of the client-side business logic and behavior versus strictly display. I’ll get more into layering applications in a later blog. For now, here are a few books worth taking a look at if you’re a flex developer on a journey toward learning how to build large-scale RIA apps. All books I recommend are from my personal collection, and I never recommend a book that I haven’t read in its entirety. In other words, I’m not trying to make some cash off an Amazon affiliate program here.

There aren’t too many out there yet on more advanced subjects in Actionscript 3.0, but these 3 will surely help you take it to the next level. Note that the first one I am listing, I attribute some of my most valuable learning to this book and I strongly recommend it to any Actionscript developer aspiring to be an expert at their trade:

AdvancED Flex Application Development; Building Rich Media X
Authors: R Blank, Hasan Otuome, Omar Gonzalez, Chris Charlton
Publisher: Friends of ED
Amazon Link

Actionscript 3.0 Design Patterns
Authors: William Sanders, Chandima Cumaranatunge
Publisher: O’Reilly Media
Amazon Link

Object-Oriented ActionScript 3.0
Authors: Peter Elst, Sas Jacobs, Todd Yard
Publisher: Friends of ED
Amazon Link

Possibly Related Posts:

• Flash Camp Phoenix a Huge Success
• Best Drunk on Software Episode Ever
• Enterprise Flex and the Swiz Framework Architecture, Part 3: Using Autowire and Mediate
• “Flex 4 in Action” (Early Access Edition) Now Available!
• Designing (RED)Wire, Part 3: Advanced Styling Methods for Enhanced User Experience with Adobe Flex and AIR