The Animated Tile List attempts to fill the Visual Component gap left by Adobe in their current TileListRenderer structure. While not as sophisticated (it doesn’t support drag & drop, mouse commands, or data change transitions for instance), it nevertheless provides an invalidating, caching tile list with smooth selection transitions.

Notable differences: The AnimatedTileList does not poll its children for desired row height or widths, but calculates those directly off of the numRows and numColumns properties, setting them explicitly.

The topics will be as follows:

• October 5th- Flex and Subversion
• October 12th- MVC Frameworks and Cairngorm
• October 19th- Unit Testing with FlexUnit
• October 26th- Automating Application Compilation and Deployment with Ant

Each of these sessions will be hosted via Adobe Acrobat Connect, and will begin at 8PM EST. Given the complex nature of some of these topics, there will be no end time set. Furthermore, these sessions will also be recorded, so if you can’t make it you’ll be able to review them whenever you feel like, and I will post links here when they are complete.

Links, preparatory sample code and prerequisites will be provided via the meeting room itself. The presentation platform will be Windows XP and Eclipse, with many apologies to my fellow Mac users. The reason is that certain shortcut methods I would use on OSX are simply not available on Windows without some serious wrangling, so I will prepare my system for that environment and make sure to go over the OSX commands while I’m there.

If you’re interested in attending, contact me directly and I’d be happy to send you a link.

State of the Union

Flash content at this point can only interface with several select screen readers, and only on Windows (EDITED: see comments). This is because the Flash player uses Microsoft Active Accessibility, which is, of course, only supported in and via Microsoft technologies. As a result, Accessibility is one of those “Holy Grail” problems you run into over and over again, and everyone slaps a big price on because nobody really knows anything about it.

Solution Overview

Now for the solution. If you really think about the problem, making the flash player accessible is completely redundant. Compiled .swf’s are embedded into the DOM of a web page which, assuming the browser is reasonably up-to-date, already accommodates a broad selection of screen readers. What is really missing is a way for the Flash piece to use the browser as a bridge communicate with them.

Some interesting developments have actually occurred in this arena recently. The first is the release of a “headless” flash player by Adobe which Google and Yahoo now use for SEO purposes, yet could very easily be licensed for other purposes. The second is open-sourcing the .swf file format spec, which could allows someone to write their own ‘accessible’ flash player. Yet both of these solutions are very resource intensive, and take control away from the developer of the application in question.

Enter WAI-ARIA: This is a W3C standard for Accessible Rich Internet Applications (ARIA) that was designed specifically with Ajax-based RIA’s in mind. To give you a quick overview, ARIA outlines a series of attributes by which an XHTML tag (such as div, body, or table) can notify a screen reader of its semantic role, as well as any changes that may occur to/within it. Thus a div tag or unordered list can be given the role of ‘menu’ and an aggressive ‘politeness’ level so that any time the menu changes, the screen reader is notified.

At this point our proposed solution should be pretty clear: Rather than relying on the flash player to connect and manage the relationship with a screen reader, we instead piggyback on the browser’s capability and let it handle our communication for us. This can be easily accomplished via the ExternalInterface class, which not only allows us to interface with the javascript engine, but also allows us to write that same javascript to the DOM from flash so our Accessibility solution becomes completely internalized.

Fig 1: A flash RIA overlaying a DOM abstraction.

Implementation

To fully understand the implementation of this concept, it’s important to realize that the flash portion of our application completely loses its purpose as a visual display platform, and is relegated to the role of Model and Controller, with the HTML DOM acting as the View. In essence the .swf becomes a Meta application whose job it is to accurately project its current DisplayList hierarchy into the HTML, while accepting commands from that same environment.

This requires a one-to-one mapping between DisplayObjects and HTML elements, which thankfully is fairly easy. To illustrate, take a look at the following two simple code examples. The first is an HTML representation of the DOM rendered by a browser, while the second is an MXML representation of DisplayObjects rendered by the Flash AVM.

Fig 2: XHTML and MXML representations of a similar page interface.

Look similar, right? Even though they’re both abstractions, you can get a good sense of similar object hierarchy and inheritance, and building an bridging framework becomes a question of determination rather than digging into the depths of the Flash Player. The tools are there, the solution is there, all we need to do is build it.

Fig 3: User Interaction flow for different use cases.

This post originally written for Resource Interactive’s Technology Blog.

One of the holy grails of the "Build Once, Deploy Anywhere" promise of the Adobe AIR isn’t simply that your application will cross all major operating systems, but also that the same codebase can be deployed via the web as an RIA. Admittedly, there remain some differences in functionality; For instance, a desktop application has to worry about windows or contextual menus. Another challenge altogether is transferring data between a desktop and a web application, which can be a daunting task if you’re trying to share multiple files, yet is perhaps not as difficult as you might think.

AIR, via the ByteAray and FileStream classes, allows us to take an arbitrary data object and serialize it to our own custom file type. Since the ByteArray class is available within the standard Flex environment as well, the only trick remaining is to make this file accessible to an application deployed via the web. When running in the browser, Flash’s security sandbox prevents us from directly accessing it on the desktop (At least until the release of Flash Player 10, which relaxes that restriction), however we can still send a file to the server and then open it from there. In short, files generated from AIR can be easily deserialized and used within the Flash Player runtime.

Potential uses for this are many. Consider, for instance, that your application has a fairly complex customized display object that draws its information from a value object. This value object contains strings, arrays, and perhaps even an image. By serializing this information into a file, a user can easily share all this information without the need for a data transfer process that has to support multiple file objects. Simply write your file from binary and send it.

Step 1: Create your Value Object

The first step is of course to create your Value Object. The below code should be no surprise to anyone – the only difference is  the [RemoteClass] metadata tag. This tag is a catchall identifier used by Actionscript to map class-to-binary identification, and is used anywhere  serialization occurs: The AMF protocol, SharedObject, ByteArray Serialization, etc.

package com.resource.vo
{
	/**
	 * A simple data Value Object to show that it is possible
	 * to deserialize a binary object created in AIR within the
	 * Flex environment.
	 */
	[RemoteClass(alias="com.resource.vo.SimpleDataVO")] 
	public class SimpleDataVO
	{
		[Bindable]
		public var firstName : String = "";
		[Bindable]
		public var lastName : String = "";
		[Bindable]
		public var email : String = "";
	}
}

Step 2: Save your Value Object to a File

The code shown in the next two steps is almost exactly the same, except that the button handlers are a little different. As you will note, this is an AIR application in which we create a simple form that writes a constructed data object to a specified location on the file system when the Save button is clicked.

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
	<mx:Script>
		<![CDATA[
			import com.resource.vo.SimpleDataVO;
			import flash.filesystem.*;

			[Bindable]
			private var dataObject : SimpleDataVO;
			
			override protected function initializationComplete():void
			{
				super.initializationComplete();
				
				dataObject = new SimpleDataVO();
			}
			
			private function saveFileButtonHandler ( event : MouseEvent ) : void
			{
				// First, generate your ByteArray from the VO.
				var byteArray : ByteArray = new ByteArray();


				byteArray.writeObject( dataObject );
				
				// Resolve your file location.
				var file : File = File.applicationStorageDirectory.resolvePath( "testFile.ri" );
				var fileStream:FileStream = new FileStream();
				
				// Save the file to the given location.
				fileStream.open(file, FileMode.WRITE);
				fileStream.writeBytes( byteArray );
				fileStream.close();
			}
			
		]]>
	</mx:Script>
	<mx:Form x="10" y="10" width="363" height="196">
		<mx:FormItem label="First Name">
			<mx:TextInput id="firstNameInput" text="{dataObject.firstName}" change="dataObject.firstName = firstNameInput.text"/>
		</mx:FormItem>
		<mx:FormItem label="Last Name">
			<mx:TextInput id="lastNameInput" text="{dataObject.lastName}" change="dataObject.lastName = lastNameInput.text"/>
		</mx:FormItem>
		<mx:FormItem label="Email">
			<mx:TextInput id="emailInput" text="{dataObject.email}" change="dataObject.email = emailInput.text"/>
		</mx:FormItem>
		<mx:FormItem>
			<mx:Button label="Save" click="saveFileButtonHandler(event)" />
		</mx:FormItem>
	</mx:Form>
</mx:WindowedApplication>

Step 3: Read your Value Object

This next application written for web deployment, and matches the above in all but the button handler. Here we use the URLLoader and URLRequest classes to retrieve our file from an upload directory. Once it’s been received we access the returned data and let the ByteArray class reconstruct our logical object.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
	<mx:Script>
		<![CDATA[
			import com.resource.vo.SimpleDataVO;
			
			[Bindable]
			private var dataObject : SimpleDataVO;
			
			private function loadFileButtonHandler ( event : MouseEvent ) : void
			{
				// Execute the file load.
				var request : URLRequest = new URLRequest ( "upload/testFile.ri" );
				var receptor : URLLoader = new URLLoader( request );
				
				// Make sure our content is interpreted as a ByteArray.
				receptor.dataFormat = URLLoaderDataFormat.BINARY;
				receptor.addEventListener( Event.COMPLETE, fileLoadedHandler );
			}
			
			private function fileLoadedHandler ( event : Event ) : void
			{
				// Retrieve the event target, cast as the URLLoader we just created
				var loader : URLLoader = event.target as URLLoader;
				
				// Retrieve the loaded data. We know it's a ByteArray, so let's cast it as well.
				var data : ByteArray = loader.data as ByteArray;
				
				// Use the ByteArray.readObject method to reconstruct the object.
				var obj : Object = data.readObject();
				
				// Cast the object and assign it to our data container.
				dataObject = obj as SimpleDataVO;
			}
		]]>
	</mx:Script>
	<mx:Form x="10" y="10" width="363" height="196">
		<mx:FormItem label="First Name">
			<mx:TextInput id="firstNameInput" text="{dataObject.firstName}" change="dataObject.firstName = firstNameInput.text"/>
		</mx:FormItem>
		<mx:FormItem label="Last Name">
			<mx:TextInput id="lastNameInput" text="{dataObject.lastName}" change="dataObject.lastName = lastNameInput.text"/>
		</mx:FormItem>
		<mx:FormItem label="Email">
			<mx:TextInput id="emailInput" text="{dataObject.email}" change="dataObject.email = emailInput.text"/>
		</mx:FormItem>
		<mx:FormItem>
			<mx:Button label="Load" click="loadFileButtonHandler(event)" />
		</mx:FormItem>
	</mx:Form>
</mx:Application>

A few caveats

For ByteArray to properly serialize and deserialize your object, two things must be the case. First, you must use the [RemoteClass(alias='')] metadata tag. Secondly, you have to make sure your value object is compiled into your application. This can be done either implicitly (via the type declaration I used above), or explicitly by adding your class to the mxmlc compiler arguments.

Additionally, there are a few things  I explicitly omit in this tutorial. Foremost of these is the send/receive architecture that would ensure the proper distribution of a file created from AIR. This will vary by implementation, so I’m not going to tell you how this should or should not be done. The other is that I don’t discuss the creation of ByteArrays within Flex and returning them to AIR. Since the Flash Player doesn’t yet allow you to save to the desktop without bouncing through a server, the implementation of Save-From-Flash can be complex and involved, and will have to wait for a future article.

The similarities, though, end there. Implementation varies, technology varies, scope and location and functionality varies, and all in all it ends up being a pretty difficult convoluted mess to describe. At best you can group them via complexity, and after a brief exercise of that nature we realized that a new breed of networked application was emerging. Well, alright, perhaps not emerging, but instead gaining momentum and acceptance in the mainstream. Here’s the scale, see if you agree with our reasoning.

Level 1: The Widget

At this level of RIA you are attempting to display information in context of a particular page, however you don’t care about anything but the most basic user interaction. These could be things like drop-down menus, product detail pop ups, rotation views, buttons that reveal and/or expand text content (like reviews) and so forth. They are almost always implemented in JavaScript, because to use Flash or another plug in technology would be quite a bit of overkill.

Level 2: The Functional/Interactive Widget

This level of RIA’s describes widgets that allow a user to complete a particular functional task. No longer content with simply displaying information, we’ve now added functionality or a experience that responds to user input. This could be as simple as a DHTML login form or as complex as a Flash-based page takeover, but it necessarily remains restricted to a specific, easily definable task. "Log In", "Rate This Product", "Check Convention Schedule" and so forth are good examples, as they add a richer experience that remains in context with the page itself.

Level 3: The Rich Internet Application (RIA)

The next level of complexity takes the task mentioned above and strings them together into a flow, or objective, thus defining an actual application. While previously you would have perhaps a few simple form fields to fill out, an actual RIA causes the context of the page to change dramatically via user input. User interaction is no longer restricted to a single action, but instead is intended to enable an activity, such as "Tracking your time", "Editing a Photo", or "Managing a Color Palette". This is where the bread and butter of RIA’s exist, as well as the holy grail of Web 2.0: A fully interactive and functional application contained entirely within one browser page.

Level 4: The Rich Networked Application (RNA)

The Rich Networked Application (RNA, I’m trying to coin a term here, help me out) ceases to be bound by the browser, and instead has become an experience that bridges and is uniform across all digital touch points. The service is available not only from a browser, but may also be accessed from a desktop, a mobile device, a vehicle dashboard, a kiosk, a gaming console, or any other networked or partially networked device you can imagine. The RNA reaches out to many delivery channels, and while it may provide a different experience for each it nevertheless remains connected in context across them all. Excellent examples of this are Twitter (and all its clients), Google Maps (available on Mobile, Internet, etc), Kuler (Integrated to the desktop and the entire Adobe Suite), as well as upcoming games like Spore (Share creatures across platforms). Implementation… well, lets be honest, it’s a nightmare if you go into it unarmed. You have to support many different platforms, frameworks, systems and limitations, yet even so we’re starting to see toolsets emerge that address them all (Most notably Adobe’s Flex & AIR, Microsoft’s DLR via WMF & Silverlight, and Javascript libraries like SproutCore, MooTools and Prototype).

Did that make sense to you? It does to me, and I’m really excited to see how what we have today is going to start bridging the Device Divide.

Step 1: Download and Install Cruise Control

You can download Cruise Control from Sourceforge. For the purpose of this demo I’ve used the binary distribution, though you can compile your own. Once you’ve downloaded your distribution, unzip it into a convenient directory. I’ve used the base applications directory: /Applications/CruiseControl.

Step 2: Create a User

It’s best practice to not run cruise as root, so open up your user accounts and create a new user called Cruise Control.

Step 3: Create a folder in the StartupItems directory.

$ sudo mkdir /Libraries/StartupItems/CruiseControl

Step 4: Create the Parameters File

Create a file called /Libraries/StartupItems/CruiseControl/StartupParameters.plist. This file will contain your startup launch configuration information- in other words it’s a file describing your startup task.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Description</key>
	<string>Cruise Control</string>
	<key>OrderPreference</key>
	<string>None</string>
	<key>Provides</key>
	<array>
		<string>CruiseControl</string>
	</array>
	<key>Uses</key>
	<array>
		<string>Network</string>
	</array>
	</dict>
</plist>

Step 5: Create/Configure the launch script

The launch script needs to be command line executable with the following three options: start, stop, reset. I’ve included my sample here, but I recommend you adjust it to match your own configuration and user name.

#!/bin/sh
#
# Error out when no parameter given
if [ -z $1 ] ; then
	echo "Usage: $0 [start|stop|restart] "
	exit 1
fi

# Source the common setup functions for startup scripts
test -r /etc/rc.common || exit 1
. /etc/rc.common

###################################################################################################
# USER CONFIGURATION

# The user under which CruiseControl should run.
CC_USER=cruisecontrol

# Cruise Install Directory
CC_INSTALL_DIR=/Applications/CruiseControl

# Directory for the config.xml file.
CC_WORK_DIR=$CC_INSTALL_DIR

# Logfile Directory
CC_LOGFILE_DIR=$CC_INSTALL_DIR

# Port under which Cruise should run
CC_WEBPORT=8080

# JMX Port. It's suggested you don't change this unless the port is already in use.
CC_JMXPORT=8082

# Port for the RMI gateway, leave blank to disable.
CC_RMIPORT=

###################################################################################################
# DO NOT MODIFY ENTRIES BELOW THIS LINE

NAME=cruisecontrol
DESC="CruiseControl - continuous integration build loop"

PATH=/sbin:/usr/sbin:/usr/bin:/bin
export PATH

CC_DAEMON=$CC_INSTALL_DIR/cruisecontrol.sh
CC_CONFIG_FILE=$CC_WORK_DIR/config.xml
CC_LOG_FILE=$CC_LOGFILE_DIR/cruisecontrol.log
CC_COMMAND="$CC_DAEMON -configfile $CC_CONFIG_FILE -webport $CC_WEBPORT -jmxport $CC_JMXPORT -rmiport $CC_RMIPORT -user youruser -password supersecret"

# overwrite settings from default file
if [ -f /etc/default/cruisecontrol ]; then
  . /etc/default/cruisecontrol
fi

# does the executable exist?
test -f $CC_DAEMON || (echo "The executable $CC_DAEMON does not exist!" && exit 0)

if [ `id -u` -ne 0 ]; then
        echo "Not starting/stopping $DESC, you are not root."
        exit 4
fi

# Get the PID output from the startup script
if [ -f $CC_INSTALL_DIR/cc.pid ]; then
	CC_PID=`cat $CC_INSTALL_DIR/cc.pid`
else
	echo "No cc.pid file found.  CC process may not be controllable from this script!"
fi

StartService ()
{
	cd $CC_INSTALL_DIR
	su $CC_USER -c "/bin/sh -c "$CC_COMMAND >> $CC_LOG_FILE 2>&1"" & RETVAL=$?
	echo "$NAME started with jmx on port ${CC_JMXPORT}"
}

StopService ()
{
	if [ -n "$CC_PID" ] && ps -p ${CC_PID} > /dev/null ; then
		kill -9 ${CC_PID}
		RETVAL=$?
	else
		echo "$NAME is not running"
		RETVAL=1
	fi
}

RestartService ()
{
	RunService "stop"
	RunService "start"
}

RunService "$1"

Step 6: Set permissions

Given that the startup script will ignore anything that isn’t owned by root, and right now cruise still doesn’t have write access to the cruise install dir, we have to make a few adjustments to our file structure to make this work.

$ sudo chown -R cruisecontrol /Applications/CruiseControl
$ sudo chown -R root /Libraries/StartupItems/CruiseControl
$ sudo chmod 755 /Libraries/StartupItems/CruiseControl/CruiseControl

That’s it. I hope this was helpful

• The internet ecosystem: Ruby, Rails, AIR, Flex, and where do they all fit
• Cost: What is it going to take?
• Installing and using RubyAMF
• Overview of MXML, Actionscript, Eclipse and the SDK
• Consuming data services with Flex & Air
• Building a simple call/response architecture

The presentation was on Monday, June 16th. The files are below:

I’ve always been bothered by that question, because not only do I have a strong background in the Fine Arts, but I have 8 years of solid experience as a developer. The reason I don’t like it is that those of us who operate on the web apply both our creative and logical skills on a daily basis, and in many cases it is our creative streaks that make us so good at what we do. Problem solving skills and creative expression are absolutely inseparable: We learned this from Einstein, and Galileo, and Leonardo Da Vinci, and Thales, and Newton, and a host of other individuals who nowadays would be called the greatest minds of their time.

And yet, every single time we present ourselves professionally, we are categorized into either a logical or creative bucket: Designer or Developer. Admittedly, there are advantages to this, since one can easily quantify compensation, career advancement and project resources based on defined tracks. Furthermore, most (if not all) web production processes work on the basis of phase signoff to protect both the client and the agent, and design necessarily comes before development. Rigid classification of skill and expertise is a boon to management and customer expectations, though it is a poor representation of reality.

Truly great projects involve all hands from kickoff, and while production can perhaps not truly begin until the ideation and proposal comps have been signed it is only by the virtue of continuous collaborative progress that the possibilities begin to flourish and grow. In this kind of an environment, the terms “Designer” and “Developer” cease to have any meaning; Contribution becomes equal in value and blended along the lines of common expertise.

An example: My colleague Jeff Breckenridge (Who’s a fantastic but under-appreciated designer *hack*cough*shameless plug*) has a remarkable understanding of graphic composition, but that does not mean he doesn’t understand the opportunities of object-oriented design. I myself know how important his expertise is, and with my background in production graphics can bring my own skills to the table and meet him on mutual common ground. The end result is well composed, well designed, and is functionally robust.

Skills: Jeff Breckenridge & Michael Krotscheck

The work we did on Practical Desktop was great not because he was the “Designer” and I was the “Developer”, but because we both mingled our skills across our particular domains of expertise. In some cases, I relied on his understanding of functional implementation, while in return he provided me with comps I could easily derive interface states from. We both brought our skills to the table, and in the middle they blended to produce something great.

I have stated before, and will state again, that true genius occurs at intersections of knowledge domains. The only thing we are lacking is a way to describe our skills in a way that accurately describes these domains, and is useful in managing projects, resources and employees to achieve the greatest level of creative impact for each implementation. The following flash piece approaches a method by which the skills may be described, and even assists in managing skills for a particular project, however it may not yet be refined enough to properly define career progression and compensation.

In the end, the point I’m really trying to make is this: The terms “Designer” and “Developer” have no meaning anymore. What matters from this point forward is the blending of skills, and we need a new way of describing these skills so they may be properly blended. What remains is the management of individuals categorized in this way. How exactly does one form a team of professionals when a particular set of skills is needed? And how in the world do you compensate them?

Practical Desktop

Practical Desktop appears to be a simple timekeeping application, though in reality it’s an open source widget framework that allows pretty much anyone to build a deployable block of functionality that can start interacting with other widgets. The wrapper’s there for you, go nuts. The source is here

From a personal perspective, I use it as a beta and explorative sandbox, because there are a lot of interesting things coming out in the near future that I’d like to offer some guidance on development best practice, and to do so I will have to figure it out myself first. Rest assured that the widgets I build will be functionally complete, though perhaps limited in feature support.

Pandora

The Pandora Desktop application is really just a customized webkit browser that’s hardwired to the Pandora mini player. I’ve fixed the application so minimization works in Windows, and expanded it to include the player’s html wrapper as well. The reason I did this is because Pandora’s a free service, and I’d like to make sure that I’m not ripping them off by stripping out the ads. Optimally I’d like to help them convert their existing player to AIR, but until I have free time (or they pay me ) that won’t happen.

• Ant
  Ant macros, includes and libs
• Libraries
  The new home of the practicalflash libraries, refactored to match the Flex 3 project layout
• PandoraDesktop
  The Pandora Desktop application
• PracticalDesktop
  The Practical Desktop utility widget framework application and timekeeper
• Tools
  Miscellaneous non-actionscript tools and utilities
• build.xml
  The unified build script