Application Building Blocks part 2 - Commands

Leveraging the browser back and forward functionality in Flash using Commands and the Gugga Flash Framework

With this new posting we would like to introduce one more of the key aspects used in the Gugga Flash Framework, the Commands, along with a real world example how to apply them. As a wide aspect framework GUGGAFF takes advantage of this well known concept in software development to introduce some key features. Commands' sole purpose is to abstract requests and encapsulate their logic. They decouple the caller from the callee, allowing undoable actions and preprocessing.
We will show you how you can apply that to manage the browser history functionality in a Flash application, or in more familiar terms the browser back and forward buttons. Although there are already examples of such implementations most of what we seen is for applications build using frame based approach. But what happens when you do not have frames and you want to build a flash application using OO methodology? The need to persist application state, ability to buffer what the user does with your application and restore that state.

Command Pattern
We are not going to lay out in detail what the command pattern is all about but for the sake of context and explanations how we applied it in GuggaFF here is a brief layout:
„Sometimes it's necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request....
The Command pattern lets objects make requests of unspecified application objects by turning the request itself into an object. This object can be stored and passed around like other objects. The key to this pattern is an abstract Command class, which declares an interface for executing operations. In the simplest form this interface includes an abstract Execute operation. Concrete Command subclasses specify a receiver-action pair by storing the receiver as an instance variable and by implementing Execute to invoke the request. The receiver has the knowledge required to carry out the request...“



GuggaFF and Commands

In GUGGAFF the Commands primary usage is to abstract navigational requests. A navigation request might imply a various expected results: opening or closing a secton, a popup, following a deep link or cross section navigation, position a component in a state.
When you build an application with GUGGAFF, you can base the navigation architecture of your application on commands for navigating through the Sections or inside components.

The Benefits

Using commands allows us to abstract the invoker of a navigation requests from the receiver.

We are also able to maintain a command history buffer , which helps us to support browser history events such as back and forward.

Key Players and their responsibilities

There are several key players in the framework that cooperate using commands.

MenuItemsController, responsible for execution of NavigationCommands in response to user activities with your application's navigation menu. It is the invoker from the diagram above.

NavigationCommand, a specific command implementation possesing enough information to navigate through the application.

OpenPopupCommand, another implementation of command used for opening popup within your application

CommandManager , a singleton responsible for executing commands without being aware of their specific implementations since they expose the command interface. It also acts as a history buffer, but we will get to that later.

Application, a command receiver for NavigationCommands, available through the IApplicationCommandReceiver interface.

How does it all work?

We have already made a brief lay out of the command pattern and also identified the key players participating. Here is a more detailed explanation about the players in the GuggaFF and how they cooperate.

The Application class was identified as the command receiver for navigation requests, and it should provide the IApplicationCommandReceiver interface to the commands. The interface defines methods for:

1. Navigating inside the application using a given Section Path (a dot notation of sections or components hierarchy describing it uniquely)
We would expect the commands in our history buffer to be able to reverse the application state. Considering that the application also exposes the following methods :

2.Creating navigation state (Memento Desing pattern) preserving the current navigation Path.

3.Setting navigation state to a previously preserved one

A MenuItemsController in our application acts as an invoker for commands. To ensure the invokation, we equipe the controller with commands for the items it aggregates. It is usually done durring the initialization of the controller.

To maintain a history buffer, the MenuItemsController delegates the command execution to the CommandManager singletone. Once the execution is delegated to him, the command is stored in the buffer and processed.
The CommandManager also needs to be able to reverse the application state. Reversing of the application state is available calling the manager, to navigate to a particular command in its buffer. To identify the command in the buffer we use a command index. A command index should be remembered whenever we want to be able to reverse to a state.

This ability to reverse state forces the commands to create and store a navigation state memento right before their execution.

The next aspect is how the command pattern implemented within the framework gives us the ability to manage the browser history back and forward.

Real world example of managing browser history back and forward

Solution architecture

The first issue we face when building a solution to manage browser back and forward buttons is the fact that the browser history buffer is not affected when the flash application is navigated. A way to solve this problem, is to issue parallel requests to the browser, every time the application is navigated, and it is also an important point that these requests should not cause reload of the flash movie. To do that, we choose to update the hash of the browser address bar.

Once we are able to use the browser buttons, we would expect them to reverse the application to a previous navigational state. In order to do that, our application is forced to maintain its own history buffer for navigational states.
It should meet the following requirements

1.Navigational requests should be abstracted so the history buffer can work with them
2.The history buffer should be able to reverse the application state using the stored requests

To meet the requirements we abstract navigational requests into commands and store them into the history buffer. The commands also might be undone or re-executed later to reverse the application state.

Once we have the commands we should put them together with the items in the browser history, which we do by passing a command identifier to the address bar hash. Given that we are able to reverse the application navigational state when the browser history is navigated.

In addition to the previously mentioned key players we also:

1.Need a class abstracting the communication with the address bar. This is the AddressBar.
2.And a class maintaining the communication between the AddressBar and the CommandManager. This is the AddressBarManager.


The following sequence diagram illustrates the interactions between the participants in our solution.




[DOWNLOAD]

You can test the application here:
History Management Sample App

You can download the sample application from here:

HistoryManagement.zip

Why a new Flash Framework?

Flash as a technology besides its obvious benefits and capabilities posses greater then other technologies challenges related to work flow , separation of code and design , development environment, process, maintenance, extensibility and reusability of concepts and code.
Most of the developers working with flash and creating web sites do not use OO programming and design patterns.90% of them are single developers not teams and they consider this an overhead. The methodology and approach used in other technologies are not applied in Flash only in Flex and other frameworks that are build around creating applications not web sites in Flash.
Let's look at the available options for building OO, extensible , maintainable flash based web sites. There are a number of frameworks most of which focus on applications(Flex, Cairngorn, ARP). At the same time most of the web sites build using Flash are multi page web sites. Someone can argue that application frameworks can be used to build sites but in fact the requirements are so different that this is yet to be proved that is has an economic value to it.
Let's add to this mixture one more critical element, the creative one.Each web site strived to be very unique in terms of look, feel and interactions.

So a flash developer/team is under gun to create a unique look and feel, very highly interactive, performing, web site under tight deadline. Add to that you want to be able to reuse your code, concepts, architecture. Implement the site in a way that a year from now you can still read and extend your code and the requirements just hit the sealing. If this is not enough, you as a developer do not have the proper development environment, debugging and testing tools and frameworks.Or is it so ...Off course we will not address all these issues in one article but we will start taking care of those one by one.

We are not going to list all problems related to developing web sites with Flash but to quote Jesse Warden from one of his posts there are 4 key problem with Flash Development:
# Deadline - all projects are under tight dealdline which imposes requirements for how quickly can you pull a project
# Creative - you cannot pose any creative restrictions upfront to the designers and IA
# Bandwidth - you must employee as little as possible resources
# Maintainability - you have to be able to extend every web site you have ever build no matter how much time it went by and make it quick

Let's add to that list a bit more spice and what we want to be able to do with Flash from a Software Development Perspective:
# write in OO manner in Flash
# use Design Patterns in Flash
# create maintainable, extensible data aware multi tier web sites in Flash

I believe we owe you one more definition and an explanation, why do we think we have a framework and the best explanation we found is in one of the famous Design Paterns Books:
"A framework is a set of cooperating classes that make up a reusable design for a specific class of software... You customize a framework to a particular application by creating application-specific subclasses of abstract classes from the framework.

The framework dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibilities thereof, how the classes and objects collaborate, and the thread of control. A framework predefines these design parameters so that you, the application designer/implementer, can concentrate on the specifics of your application. The framework captures the design decisions that are common to its application domain. Frameworks thus emphasize design reuse over code reuse, though a framework will usually include concrete subclasses you can put to work immediately...

Not only can you build applications faster as a result, but the applications have similar structures. They are easier to maintain, and they seem more consistent to their users. On the other hand, you lose some creative freedom, since many design decisions have been made for you...

Frameworks are becoming increasingly common and important. They are the way that object-oriented systems achieve the most reuse. Larger object-oriented applications will end up consisting of layers of frameworks that cooperate with each other. Most of the design and code in the application will come from or be influenced by the frameworks it uses."

We could not put it better not only in terms of what we are expecting of a framework but what we actually are offering and we can only encourage you to explore Gugga Flash Framework. I'm sure it has room to be extended and improved but we believe there is a very good foundation proved to work in a large number of real work projects.

Application Building Blocks part 1 - Sections

The Sections are the base logical and application building blocks in an application based on the GUGGAFF. Sections implementation follows the Page Controller design pattern. Each section is responsible for displaying and controlling one logical part of the application. The scope and content of this part can be defined depending of the needs in every single application. Each section should follow the rule for logical encapsulation, and should have a consistent lifecycle.

Sections Lifecycle
The lifecycle of a Section is comprised of five sequences – Initialization, Activation, Opening, Closing and Destroying. They are actually referenced as Tasks but thanks to the Composite pattern used, we can have complex sequences at this places. Each of those Sequences will be executed when that cycle step is due.

Initialization
Section initialization sequence is triggered when the section is instantiated and should initialize itself to become fit for work. This can include components creation, essential data loading and other tasks that ensure the workability of the section.

Activation
Activation sequence is triggered in the very first moments when the section is about to be opened. The opening of a section is triggered only when the closing sequence of the previous section is complete. This way the Activation sequence starts with the previous section’s Closing sequence. During the Activation sequence the section can prepare itself for the upcoming Opening sequence. It can for example perform lazy loading by loading its data here but not in the initialization sequence.
In a common scenario the Initialization and Activation sequences are time consuming tasks. They must also complete prior to the Opening of the section and we have to entertain the end user during that time period. That’s why each section provides its controller a way to monitor the progress of the tasks which precede the Opening. These tasks are not coupled with the initialization and activation sequence sequences. They can contain subparts of them, but its programmer’s choice what to put in the pre open progress monitor.

Opening and Closing
One of the key aspects that is used in every web site is the ability of the sections to open and close. Those sequences common use is to play animations. Closing tasks can also be used for freeing some temporary allocated resources.

Destroying
The destroying sequence of the lifecycle is not as common scenario. Its usage appears when dealing with sections that feature large amounts of content in them which should be destroyed to free the flash player resources.
The common functionality for controlling the section’s lifecycle is implemented in the gugga.application.Section class. All the sections in a GUGGAFF application should extend this class.

Nesting Sections
Sections can be nested. They follow the Composite design pattern to implement this functionality. A group of nested sections is controlled by a Sections Controller (gugga.application.SectionsController), which is a Section it self. In addition the Sections controller is responsible for switching between its child sections which must be registered with him.

There are three types of sections that can be registered with a Sections Controller. Sections that are already instantiated on the scene and you can reference their instance names.

Lazy attach sections which exist in the library, but are still not instantiated.

Sections that will be loaded as external Swf files.

Navigating between Sections
When a command is issued to navigate from one Section to another, the Section Controller instantiates a Sections Transition (gugga.application.SectionTransition) object which handles the transition. This object does all the work to ensure the correct lifecycle of the sections involved in the transition.

Key Concepts in Gugga Flash Framework?

This is the first of a series of articles that will introduce the key concepts in the Gugga Flash Framework. The idea behind those articles is trivial to easy the process of Introducing developers to the framework. Before we dive in the key concepts we owe you a little more insite and something as a definition of what the framework is.
The Gugga Flash Framework is a library of application building blocks designed to assist developers with common development challenges.

Application blocks are set of classes that can be asociated to movie clips and used "as is", extended, or modified by developers to use in Rich Internet Applications (RIA) projects. They are designed to encapsulate the best practices for Flash and enterprice applications, help address the common problems that developers face from one project to the next, and also addresses scenarios not directly supported by the underlying class libraries supplied by Macromedia.

The GuggaFF focus in Rich Internet Applications determine that main concepts in the framework are those of the Section, Application and Task and Sequence. To create an application using the GuggaFF you mush have at least :

Section

The Section is the main application building block. If nothing else a single section will exist and this will be the Application. The name Section was chosen because the abstraction Section is a common knowledge for everyone who was ever involved in creating a web site. The Section abstraction also implies:

* one can navigate from and to a Section
* that it is a container assuming responsibility for a certain level of encapsulated functionality or information.

From a development perspective, in GuggaFF, the Section is a class. This class or its successor must be assigned to a Movie clip in a FLA file to allow its participation in an Application.

From a Designer perspective the Contents of the movie clip associated with the Section class can be edited using Macromedia Flash editor to add graphic symbols or other components.

This architectural approach follows our firm belief that we have to allow for separation of design from development work.

Section Controller

Besides Section we have one more very important player and this is the SectionController. SectionController is a kind of Section that contains other sections. If a Section must contain other Sections then it have to become a SectionController?. It acts like an Application for its own contained sections. Actualy the Application it self is an extension of a SectionController. This approach allows for unlimited level of nesting of sections without sacrifising flexibibility and ease of use.

Application

In GuggaFF the Application follows the MVC pattern, and acts as a “controller” that assumes responsibility to respond to navigation events, register and manage its contained sections. The Application responsibilities are not limited to control the Sections but are extended to :

* configure the entire application,
* preload globally used resources
* prepare data connectors
* other system wide tasks.

The Application is also associated with a Movie Clip

Task

Task represents small piece of work that has to be executed, or a function to be performed in order to constitute a complete unit of action. Tasks can be linked together in order to achieve desired result.

Code execution in Flash is always synchronous. All code that belongs to a frame must be executed before player moves to another frame. At the same time, many critical aspects in application development have an asynchronous nature. This includes but is not limited to:

* loading of external resources
* access to data and it’s processing
* waiting for user interaction
* initialization of components
* and so on.

Some of these actions cannot not even start before the playhead has moved to the next /sometimes virtual/ frame. This is real reason behind introducing the concept of the Task, to handle such situations.

Task are building blocks that can be either used alone or included into the Sequences. They :

* defines its own start and completion
* can either have synchronous or asynchronous nature
* can be externally manageable - their start can be invoked by someone when certain conditions are met.

Sequence

Sequences are used to organize task execution and synchronization. They are a representation of a workflow that must be executed in order to complete a complex process. Sequences can be linear or graph.

Linear sequences are intended to be sequential and to start next task, only when the previous one have completed. They are very easy to construct and can handle a web of situations.

In more complex situations a graph like Sequence /represented by class TaskManager? / can be used. In such cases the task execution time can depend on the completion of more than one Predecessor Task, or even External Preconditions. Task completion itself can trigger execution of more than one task. Multiple starting tasks and complex “complete” status determination are also possible to implement.

Sequences are also considered Tasks. You can include one sequence into another just like adding any other atomic task. Armed with that flexibility there are no restrictions to what you can acheive.

Sections and Application use sequences to perform their duties. For example a Section is intended to have 4 different sequences

* Initialization – executed only once and it prepares a section for work
* Activation – executed every time a section is nominated to be opened . This sequence is executed concurrently with the Closing Sequence of the Section being closed. It starts its execution when the Closing Sequence of the previously opened Section is started. This Sequence is intended to load external resources or reorganize the Section content
* Open - Opening Sequence is intended to reveal the currently selected Section. It starts its execution when Closing Sequence of previous section is completed.
* Close – executed when section is closed

The next set of articles will dive into greater detail as to how those key aspects interact or work