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