StateMachines : Implementation of WF in AS3

I have now successfully ported a minimal subset of the Windows Workflow Foundation to AS3. Initially I have created Sequential and StateMachine Workflows with just a set of non-nestable Activities.

Next point of focus is on implementing a set of sample applications which will illustrate the power of having an event-driven application based on StateMachines as well as a number of Applications illustrating how easy keeping a complex set of activities in strictly sequence using the SequentialWorkflow.

Another important aspect right now is to get the WorkflowRuntime just right as it right now pretty much only works as a Workflow factory.

State Machines : The C in PureMVC

I have some difficulty figurering out how to combine the notion of a statemachine workflow with the PureMVC notion of commands as the primary work-units. Using states seems to defy the need for commands and if not in direct conflict only because one could imagine using the statechange events to trigger commands. However, the ladder seems to create additional complexity in return of no other benefit than being able to use a statemachine workflow as the primary driver in a strict PureMVC system without removing logic from the commands.

Cliff Hall started a working group with this focus, but it appears that they too have had some difficulty cornering the right way to combine this.

Check it out...
http://forums.puremvc.org/index.php?board=25.0

State Machines : Windows Workflow Foundation

Windows Workflow Foundation has buildin support for building state-machine workflows to be used from any dotNet based host.

I will explore this in the upcoming weeks in relation to my effort to contribute to the further development of State Machine support in the PureMVC framework.

Check it out...
http://msdn.microsoft.com/en-us/netframework/aa663328.aspx

State Machines : Basic Thoughts

There is one important decision to make when creating a new workflow. Will the workflow be a sequential workflow, or a state machine workflow? Windows Workflow provides these two types out of the box. To answer the question, we have to decide whois in control.

A sequential workflow is a predictable workflow. The execution path might branch, or loop, or wait for an outside event to occur, but in the end, the sequential workflow will use the activities, conditions, and rules we've provided to march inevitably forward. The workflow is in control of the process.

A state-machine workflow is an event driven workflow. That is, the state machine workflow relies on external events to drive the workflow to completion. We define the legal states of the workflow, and the legal transitions between those states. The workflow is always in one of the states, and has to wait for an event to arrive before transitioning to a new state. Generally, the important decisions happen outside of the workflow. The state machine defines a structure to follow, but control belongs to the outside world.

We use a sequential workflow when we can encode most of the decision-making inside the workflow itself. We use a state machine workflow when the decision-making happens outside the workflow.

State Machines : A Powerfull Programming Tool

State machines have always fascinated me. There is a clockwork precision to their inner workings that appeals to me on an aesthetic level. They are also an invaluable programming tool. In building libraries and applications, I have returned to them again and again.

A state machine is a model of how something behaves in response to events. It models behavior by making its responses appropriate to the state that it is currently in. How a state machine responds to an event is called a transition. A transition describes what happens when a state machine receives an event based on its current state. Usually, but not always, the way a state machine responds to an event is to take some sort of action and change its state. A state machine will sometimes test a condition to make sure it is true before performing a transition. This is called a guard.

* A state machine is a model of behavior composed of states, events, guards, actions, and transitions.
* A state is a unique condition in which a state machine can exist during its lifetime.
* An event is something that happens to a state machine.
* A transition describes how a state machine behaves in response to an event based on its current state.
* A guard is a condition that must be true before a state machine will perform a transition.
* An action is what a state machine performs during a transition.

This description of state machines introduces several abstract concepts quickly, and is not meant to be formal or complete. It is just a starting point. I will explore what state machines are in a series of posts.

Next post will be about the implementation of State Machines in Adobe Flex with a running code example.

HCI : Morphable Interfaces introduces new challenges

Lately I have been working on a number of applications where the requirements to the UI has been quite extensive. The paradigm of UI in RIA's are now getting more and more well-understood among the GFX departments, XD departments, IA departments, etc. and this has triggered something resembling a revolution in advanced UI's.
Among one of the new paradigms is the morphable interface where no elements are static in their representation, but on the contrary have many different and often incoherent states.
I have chosen the wording "morphable interface" as all elements now have many representations all depending on the overall state of the application combined with the fact that movement now has taken a new position as it now is used to communicate the change of state: hence the Adobe coined slogan, "movement matters".

Having many different incoherent application-states with an equivalent set of elements combined with an effect being played while transitioning between two states defines a morphable interface.