Gugga Flash Framework

GuggaFF is now on ActionScript 3.0

2007-09-20T06:06:00.000-07:00

We this new feature we would like to announce our long anticipated plans for moving the Gugga Flash framework to ActionScript 3.0 have become a reality and we can share its first alfa release. This turned out to be a very complicated task since the whole concept of making interactive sites and applications with Flash is changing completely with the release of Flex 2 and Flash CS3. That’s why we decided to identify the unique features that we believe will continue to exist and will contribute most to the whole development process, and port them first.

The primary features which we decided to include in this first ActionScript 3.0 release of the framework is the Tasks Engine. Along with it are included some other aspects which support its functionality such as Collections, Logging and variety of utilities.

Tasks engine is very powerful and in the same time its abstract enough. It can be combined with different concepts already included in Flex and Flash CS3. One can imagine tools combining XML defined animations from Flash CS3 and effects from Flex wrapped and included in a GuggaFF task sequence or sequences wrapped and used as effect in Flex.
There are still no implemented wrappers for doing so but they are possible to implement and will probably be included in some of the next releases.

Our major goal is to provide a full featured framework which will complement the Adobe’s suite of tools for creating interactive sites and applications. The scope and concepts of the framework will change over time as the basis of the tools we currently have has changed so much but we promise that all that we learn will be shared, with more examples and refined best practices.

You can download the new alfa release from here:
Alfa Version 2.0 alfa

Building multimarket applications with Gugga Flash Framework.

2007-06-26T04:46:00.000-07:00

Creating applications with dynamic structure.

With this new article we would like to offer you a flexible solution for creating a Multimarket-Multilanguage Flash Applications using GuggaFF. We will see how such RIAs can achieve a highly flexible and extensible structure accommodating future changes and updates. Based on our own experience, those kind of applications are usually requested to serve specific business reasons providing customized information to many markets in different languages. Let summarize the requirements for our application

provide customized information and functionality to more then one market in more then one language

allow for transparent update of information without the need to recompile the application

ability to quickly release or disable whole sections of the application during its lifespan

build and release new markets and languages without jeopardizing the existing functionality and without rewriting the application

allow for creating Accessible versions of the applications reusing the existing content

allow for transparent introduction of a content management system to support the application

Sounds familiar ….?
Ok let’s look at the two important aspects of our application that make it so unique as a requirement.

Market
A very common scenario is that different markets involve different structure of the application at the same time there is usually a significant overlap and single section is found among more than one market. Hence, market determines a set of sections with specific structure.
Please, remember that Gugga Flash Framework introduces Sections and SectionsControllers as the building blocks of an application.
Take a look at them, if they are new to you!

Language
Language is usually a function of the content displayed in the site. We will assume that all the content in our application will be external to it and will either be held in static XML files or in a Data Base.

Our goal is to create a single application which supports variable sections structure, in order to represent different markets. We strive to reach the lowest development cost in the long term and preserve high quality on a large scale.

The main architectural problems our solution is faced with are:

How to define flexible application structure, which also allows transparent creation of new markets?

How to implement an application which supports variable section structures?

How to define flexible application structure, which also allows transparent creation of new markets

Our best approach in defining the sections structure is to use xml format. It is hierarchical and matches the composite structure of the sections. Its declarative style allows even non-developer to create and control it. More importantly, the xml format brings formal sense to the key abstraction of an application structure. It also ensures that the application is completely abstracted of its current structure. For convenience proposes we will call that xml file structure.xml

Let’s start with declaring the main building block of our application - the section within the structure.xml. We will create a

node which will basically need:

id – identifier of the section. It will be used in the section paths used by GuggaFF navigation mechanism
Please, remember that every section within the composite is identified by a dot-notated section path. NavigationCommands are used to navigate section paths.

type – on_stage, lazy_attach or lazy_load depending on that if the section is on the application stage or in the application library or in external swf file. GuggaFF supports all types of sections by registerChildSection, registerLazyAttachSection and registerLazyLoadSection methods of the SectionsController class. The on_stage type of section is not the best approach if we want a flexible solution but in some very special cases (ex. when we want to abstract a block of sections which always go together) we can use it. This kind of sections are opening faster, because they are loaded and initialized in advance.

instance – For on_stage type of sections.

symbol_identifier – For lazy_attach type of sections.

swf_path – For lazy_load type of sections.

Here is a sample node of a generic section declaration:

<section id="Home" symbol_identifier="HomeSection" type="lazy_attach">
<section id=”SubSection” … </section>
</section>
If we could point any drawbacks of this solution, it is that we should have separate structures even for identical markets. But this is a cheap price to be paid!

How to implement an application which supports variable section structures

In GuggaFF every SectionsController registers its child sections. Given that, we need SectionsControllers which accept structure data(coming from structure.xml) which they will use to register their child sections. We will subclass SectionsController and this will bring a new quality to the composite entity – the ability to be created dynamically.

Here is some pseudo code to illustrate the idea.

Interface extension for composite nodes:

interface sections.IBaseSection extends ISection 

{
   public function setStructureData(aData : SectionStructureData) : Void;
}

Subclass of SectionsController to carry out the structure data and register child sections:

class configuration.SectionStructureData 

{
   public var ID : String;
   public var Type : String;

   public var SymbolIdentifier : String;
   public var Swf : String;

   public var Instance : String;
   public var Subsections : Array;

   public var SectionPath : String;
}

Subclass of SectionsController to carry out the structure data and register child sections:

class sections.BaseSectionsController extends SectionsController implements IBaseSection 

{
   public function setStructureData(aData : SectionStructureData) : Void 
   {

      mStructureData = aData;
      
      var subsectionsStructureData : Array = aData.Subsections;

      for (var i : Number = 0; i < subsectionsStructureData.length; i++)
      {

         var data : SectionStructureData = 
            SectionStructureData(subsectionsStructureData[i]);

         
         if(data.Type != "on_stage")
         {
            mSectionLoadersCount++;
            var sectionLoader : ISectionLoader = 
               createSectionLoader(data, "sectionLoader_"  + data.ID + "_" + mSectionLoadersCount);

               
            registerLazySection(sectionLoader, data.ID, true);
         }
         else

         {
            var section : Object = registerChildSection(data.Instance, data.ID);

            IBaseSection(section).setStructureData(data);
         }
         
         mSubsectionsStructureData.add(data.ID, data);
      }
   }

   private function onLazyTargetSectionUIInitialized(ev) : Void 
   {
      var section : IBaseSection = IBaseSection(ev.section);

      var data : SectionStructureData = SectionStructureData(
         mSubsectionsStructureData[mTargetSectionID]);

      section.setStructureData(data);
   }
}

To use the structre functionality of the BaseSectionsController from classes which derives from SectionsController (ex. ApplicationController), we can use the Bridge pattern.

These pseudo-implementations create the foundation of our solution for applications with dynamic structure. Every section which derives from IBaseSection or BaseSectionsController will be of a full value for the application with dynamic structure.

In next postings we will explain additional aspects of the multimarket applications like, strategies for implementing sections and components, skinning and creating accessible version of a flash site build using GuggaFF.

The new Minor(major) release of Gugga Flash Framework

2007-05-14T00:44:00.000-07:00

The new release of the GuggaFF is introducing a number of changes and improvements. The majority are focused on performance increase and improved application model.

The most significant change in is the Application Architecture. Now the ApplicationController class is a kind of Front Controller for the application. It controls all the transitions in the application and is responsible for the navigation state. Transition starts and interruptions are handled by the ApplicationController so the lower level SectionControllers are no more responsible for this. Their job is to provide the openSection() method and return the transition between the sections they are responsible for. The openSection() method of the ApplicationController should not be called separately. The navigateTo() should be called instead.

In addition to the ApplicationController changes the navigation’s state can be set by specifying the section path which is currently available. This synchronization is made by the gugga.application.NavigationManager which is commanded by the ApplicationController. Every navigation instance which is registered in the NavigationManager will follow the changes in the application’s section path automatically.

Having the ApplicationController as a Front Controller gives a much better level of control and synchronization, so now we have much better transitions interruptions. To support all the cases of fast transition changes the navigateTo() method can refuse to open a certain navigation path. In this case it returns false and the corresponding command is not included in the CommandHistory.

The other major change in this release is that GuggaFF has become almost completely separated from the Macromedia MX framework. We have our own implementation of EventDispatcher with the gugga.events.EventDispatcher class. It uses AsBroadcaster and provides significant increase in performance. In addition, the gugga.common.UIComponentEx is not inheriting mx.core.UIObject. This makes the framework more performing and decreases the time needed to initialize an application. The only link between GuggaFF and MX remains the mx.utils.Delegate class.

Another big step in increasing the performance is the new gugga.tween package. It provides a lightweight but powerful tween engine. It supports both tweens with frames duration and tweens with time duration. This helps to tune the speed and smoothness of the animations even better.

For a complete list of changes please see the change log.

Anatomy of a Button in GuggaFF

2006-11-17T00:48:00.000-08:00

The gugga.components.Button class in GuggaFF is designed to provide functionality for managing the visual states of a button and to inform for mouse events over it.

Mouse events which the Button dispatches are “click”, “press”, “rollOver”, “rollOut”. On all of them it can change its appearance. In addition the button can be in one of its selection states which also determines certain visualization.

Selection states:

off – button is not selected

on – button is selected

offDisable – button is disabled and is not selected

onDisable – button is disabled and selected

Mouse states:

Roll – mouse is rolled over the button

Down – button is pressed

Normal – none of the above is happening

In each moment of its life a button is in one of its selection states and one of the mouse states. Selection and mouse states are combined together to represent the unified button state. Here is the table of all possible states:

Let's take a closer look at some of the button states:

offRoll is when button is not selected but is rolled

onDisableRoll is when button is selected, disabled and rolled

offDisableDown, onDisableDown – the only two combinations which are impossible because when button is disabled it can’t be pressed

Now if we want to transit from one state to another we can create transition. Its name is generated with this pattern: oldState_newState, for example - off_offRoll.

Each button is a MovieClip with linked gugga.components.Button class to it. Button states and transitions are placed on the button’s timeline. They are marked with frame labels named as the state or transition’s name. On the end of each of these timeline segments, where the certain animation is finished, the stopPlaying() function should be called. If we want two, three or more states to be identical, we don’t need to create portions of the timeline for each of them. Despite this we could simply put several labels on the frame where the desired state or transition animation starts.

There are 10 button states and because it is possible to go from each state to all others, we have 9*10=90 transitions. Do we have to create all of them?
Of course not.

The main idea in the implementation of GuggaFF Button is that we should create only those states and transitions which we need. When the button goes to another state, it first tries to play transition with name made by the pattern oldState_newState. If there is such a transition the button plays it and when it is finished the button tries to play the newState.
If this transition does not exist then newState is played directly.
If we have neighter transition, nor state – nothing happens.

Basics of Tasks and Sequences in GuggaFF

2006-10-20T05:07:00.001-07:00

Overview

With this new article we would like to introduce you to one of the most important aspects of the GuggaFF, the concept of tasks and sequences and their applications. We will start with one example and how it is usually handled in Flash.

Let’s examine an abstract GUI application with dynamic content implemented in Flash. One of our first tasks will be to extract the application data from our data source. It doesn't matter what of kind of data source you are using - http service, web service or simple xml file it will take a while to load and process the data. Fortunately data loading in the Flash runs in background thread, so we can implement a loading animation which will capture the user attention during these tasks. After the data is loaded we'll want to populate the controls responsible for its presentation. This example may scale to a situation where depending on the size of the data the process may need to be distributed on more than one frame to achieve the desired performance.

In more complex sites we will need to implement the ability to have more then one view (also known as sections in GuggaFF) or different states of the view. Depending on user interactions we will need to switch the current section or to change its internal state. Often this operations are composition of loading and transition animations, preloading of external assets etc.

Common problems

During the implementation of a site in Flash we will need to handle a lot of asynchronous operations. The base approach is to register an event handler for the completion of the operation and use it to continue our work after the asynchronous task is finished. If you are using the event delegation mechanism of mx framework it would be something like this:

private var mImageLoader : ImageLoader;

private function loadContent(aImageUrl : String) : Void
{
mImageLoader.addEventListener("completed", Delegate.create(this, onImageLoaderCompleted));
mImageLoader.load(aImageUrl);
}

private function onImageLoaderCompleted() : Void
{
//do something (ex. hide loading animation or start another loader)
}

Now imagine that we want to implement a functionality which is a sequence of asynchronous operations. If we scale this approach the resulting code will be:

private var mAnimation1 : IAnimation;
private var mAnimation2 : IAnimation;
private var mAnimation3 : IAnimation;

private function initUI() : Void
{
mAnimation1.addEventListener("completed", Delegate.create(this, onAnimation1Completed));
mAnimation2.addEventListener("completed", Delegate.create(this, onAnimation2Completed));
mAnimation3.addEventListener("completed", Delegate.create(this, onAnimation3Completed));
}

private function startAnimationsSequence() : Void
{
mAnimation1.start();
}

private function onAnimation1Completed() : Void
{
mAnimation2.start();
}

private function onAnimation2Completed() : Void
{
mAnimation3.start();
}

private function onAnimation3Completed() : Void
{
//do something (ex. notify for the completion of the sequence)
}

Also if we need to wait for more than one event before we can execute some function one of the possible solutions is:

private var mImageLoader1 : ImageLoader;
private var mImageLoader2 : ImageLoader;

private var mIsImageLoader1Completed : Boolean;
private var mIsImageLoader2Completed : Boolean;

private function initUI() : Void
{
mImageLoader1.addEventListener("completed", Delegate.create(this, onImageLoader1Completed));
mImageLoader2.addEventListener("completed", Delegate.create(this, onImageLoader2Completed));
}

private function loadConent(aUrl1 : String, aUrl2 : String) : Void
{
mIsImageLoader1Completed = false;
mIsImageLoader2Completed = false;

mImageLoader1.load(aUrl1);
mImageLoader2.load(aUrl2);
}

private function onImageLoadersCompleted() : Void
{
//do something (ex. start reveal animation)
}

private function onImageLoader1Completed() : Void
{
mIsImageLoader1Completed = true;
if(mIsImageLoader2Completed)
{
onImageLoadersCompleted();
}
}

private function onImageLoader2Completed() : Void
{
mIsImageLoader2Completed = true;
if(mIsImageLoader1Completed)
{
onImageLoadersCompleted();
}
}

If we combine this examples and try to scale them the result will be a big amount of spread and tangled code. So we need to find a way to generalize the management of computations which are combination of asynchronous operations.

Tasks in GuggaFF

The base unit for solving these kind of problems in GuggaFF is the task. The task is abstraction of operation which has determined begin and end. It is represented by the interface gugga.common.ITask.

In GuggaFF we have a lot of implementations of this interface – ImageLoder, XMLLoader, TimelineAnimation, PropertiesTweenAnimation. Also we provide some helper tasks which simplify and reduce the resulting code in this approach – ExecuteMethodTask, ExecuteAsynchMethodTask, SingleExecutionTask.

So once we have tasks we need a way for combining them. The basic composition of tasks is the linear sequence:

This composition can be implemented with the gugga.sequence.TaskSequence class. It uses an single-linked list for managing the task execution. As we have in the Composite design pattern TaskSequence is also task. When we start the sequence, the head of the list is stated too. Every task in the list waits for the end of his predecessor and then it is started. This iteration continues until the last task in the sequence has been completed, then the whole sequence completes.

If we rewrite the previously mentioned example of sequence of animations with the TaskSequence class it will look like:

private var mAnimation1 : IAnimation;
private var mAnimation2 : IAnimation;
private var mAnimation3 : IAnimation;

private function startAnimationsSequence() : Void
{
var animationSequence : TaskSequence = new TaskSequence();
animationSequence.addTask(mAnimation1);
animationSequence.addTask(mAnimation2);
animationSequence.addTask(mAnimation3);

Listener.createSingleTimeListener(
new EventDescriptor(animationSequence, "completed"), Delegate.create(this, onAnimationSequenceCompleted));

animationSequence.start();
}

private function onAnimationSequenceCompleted() : Void
{
//do something (ex. notify for the completion of the sequence)
}

Before describing the other composite task in GuggaFF – gugga.sequence.TaskManager we will need to introduce the abstraction for precondition.

In GuggaFF it is abstracted by the gugga.common.EventDescriptor class. This class is a pair of event name and an object which raises this event. So the EventDescriptor class exactly describes a moment in the lifetime of concrete object.

GuggaFF provides a mechanism for composing preconditions with the gugga.sequence.PreconditionsManager class. This manager observes a collection of preconditions and raises an event when all of them are met.

If we use PreconditionsManger in the example of waiting for completion of two loaders it will be something like:

private var mImageLoader1 : ImageLoader;
private var mImageLoader2 : ImageLoader;

private function setConent(aUrl1 : String, aUrl2 : String) : Void
{
var preconditionManager : PreconditionsManager = new PreconditionsManager();
preconditionManager.add(new EventDescriptor(mImageLoader1, "completed"));
preconditionManager.add(new EventDescriptor(mImageLoader2, "completed"));

Listener.createSingleTimeListener(
new EventDescriptor(preconditionManager, "preconditionsMet"), Delegate.create(this, onImageLoadersCompleted));

mImageLoader1.load(aUrl1);
mImageLoader2.load(aUrl2);
}

private function onImageLoadersCompleted() : Void
{
//do something (ex. start reveal animation)
}

When we have the idea for precondition, we can easily describe the TaskManager class as a composite task which manages the execution of its children by preconditions. We can think that the TaskManager is a web of tasks connected by preconditions.

According to Composite Pattern, the TaskManager is task itself. When the manager is started, all of its starting tasks are started too. When all the preconditions for certain task in the web are met and all of his predecessors are completed then the task is started. The manager is completed when all final tasks are completed and all final precondition are met.

As you see TaskManager lets you to solve complex situations which are combination of all previously mentioned common problems. A simple example of his usage can be illustrated by extending the example for usage of PreconditionManager by adding an animation which should be started after completion of the loaders. So the resulting code will be:

private var mImageLoader1 : ImageLoader;
private var mImageLoader2 : ImageLoader;
private var mAnimation : IAnimation;

private function setContent(aUrl1 : String, aUrl2 : String) : Void
{
var taskManager : TaskManager = new TaskManager();
taskManager.addStartingTasks([mImageLoader1, mImageLoader2]);
taskManager.addTaskWithPredecessors(mAnimation, [mImageLoader1, mImageLoader2]);
taskManager.setFinalTask(mAnimation);

Listener.createSingleTimeListener(
new EventDescriptor(taskManager, "completed"), Delegate.create(this, onTaskManagerCompleted));

taskManager.start();
}

private function onTaskManagerCompleted() : Void
{
//do something (ex. notify for the completion)
}

Stay tuned for more articles related to interruption of tasks, deeper look into web of tasks (TaskManager) and more advanced techniques related to their usage.

Application Building Blocks part 2 - Commands

2006-09-27T06:30:00.000-07:00

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?

2006-09-20T08:08:00.000-07:00

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

2006-09-18T03:45:00.000-07:00

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?

2006-09-18T01:52:00.000-07:00

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

Gugga Flash Framework first release

2006-08-31T02:46:00.000-07:00

Nine months later and hopefully alot wiser the first official release of the framework is here. The reason for the delay is obvious, we wanted to share what we think is best at this point of time. Is it complete? Far from it. But is it good enough to be released in the public domain, you can count on that.
Every significant project we have build is based on that framework and we have not made a step back of the principles we said we will defend.
Ok, no more of as one friend nicely put it, programmer bravado.

You can download the framework from here:
Gugga Flash Framework 0.9
You can review the documentation for the framework here:
Gugga Flash Framework Documentation in HTML format

The package contains not just the framework but also the unit testing framework for it and some sample applications to get you started.
The unit testing framework is for those of you who would decide to extend it and want to make sure your code does not brake anything.
We are working on releasing a wiki that will feature some articles about how to use the framework and we will be happy to hear from you.
We do hope you will find interesting and engaging in what we do and for everyone interested to contribute to do so. Because after all this is the idea to grow from where we are now and to create something that everyone involved in developing rich interactive web sites using Flash technologies and OOP.

Some of the more significant web sites that have been build based on the framework:
Bombay Sapphire
Dewars World of Whiskey
Bar TV

Acknowledgements To Everyone's Code And Concepts We Based Our Framework On.
Macromedia
Thank You First and foremost for creating Flash :)

We are using some concepts,classes and implementations of their UI component Framework, Web Service Connector, Delegate Utils.
AS2LIB
Thank you for the Unit testing capabilities, reflection and Hash Map collection
as2logger
Thank you for the logging capabilities
Robert Penner
Thank you for your easing animations
Colin Moock
Thank you for your application template idea and first steps in applying design patterns in Flash
Darron Schall
Thank you for your Date Format Class
Mika Palmu
Thank you for the Crypthology capabilities
Ladislav Zigo
Thank you for the Tweening Classes
Alessandro Crugnola
Thank you for your XML2Object

Purpose and Scope of this blog

2005-11-14T07:20:00.000-08:00

With this initial posting we would like to announce to the ever growing Flash development community our ongoing efforts to create and maintain an extensible Macromedia Flash based framework for developing highly engaging and interactive web sites using sound Object Oriented methodology and approach.

We believe ...
That the development of any interactive content should not be made at the expense of good software design. We are committed to allow the design community to continuosly express their creative efforts in the best possible way and at the same time to enable the developers to create a well designed, performant, executable, tested and maintainable software. We would also like to chalenge you and see what your thinking in this direction is.

Based on our experience ...
We believe we can share our success and failure and introduce a different and hopefully successful approach how to develop interactive content using Macromedia Flash.

This framework is based on 2 years of our collective effort and over a 100 projects and in its latest incarnation will attempt to introduce what we believe is a sound and extensible way of approaching development of Flash modules.

Why share?
Well, a lot of what we do and the reason for some of our success is because the flash community has always been open to sharing. You will witness that we reference and use a lot of open code and we base some of our solutions on it.
We strongly believe there is a point when one has to share his work and expose it to the thoughts and candor of the flash community and the people engaged in the flash development.
We would like to pick your brains and we are confident that we will spawn your interest once you take the time to see what we have done.
There is always room to improve and to build upon the efforts of the creative minded open and willing to experiment community.

The first version ...
Of this framework will feature entirely OO AS 2.0 code compatible with Flash player version 7. Soon after we intend to release an amended version that will be fully compatible with the recently released Flash player 8 and will take advantage of some of its new features.

Sincerely Gugga Team