This is a set of posts documenting my experiences with utilising functionality within the Flex SDK that provides the automatic mapping of custom ActionScript classes to element definitions within an XML Schema (XSD).

1.  Part 1 – Introduction and background
2.  Part 2 – Overview of Flex’s XML Schema classes (inc example code)

Part 2 – Overview of Flex’s XML Schema classes (including example code)

This post covers how to take advantage of these classes (including example code) – as at the time of writing there doesn’t seem to be any discussion of these features by Adobe or the community at large. I’ll also list a few caveats we have come across in using these classes.

Read the rest of this entry »

This is a set of posts documenting my experiences with utilising functionality within the Flex SDK that provides the automatic mapping of custom ActionScript classes to element definitions within an XML Schema (XSD).

1.  Part 1 – Introduction and background
2.  Part 2 – Overview of Flex’s XML Schema classes (inc example code)

Part 1 – Introduction and background

This post explains some reasons on why the automated mapping of ActionScript classes to XML Schema definitions can be a better alternative to other data integration options available to Flex (in certain circumstances).

Read the rest of this entry »

One of the key benefits of using Flex for the end user is a consistent experience when interacting with on screen elements. While the look/skin can vary greatly, the underlying behaviours remain consistent, making the site or application more usable. While Flex provides a default implementation to each step in an interaction, it generally allows customization of the visual state through the various events associated with each component type. Hence we have custom animations and transitions between states to implement the most appropriate behaviour in an individual project.

A good example of this is Flex’s inbuilt Drag and Drop. Generally on the web, drag and drop functionality varies greatly from implementation to implementation. Many cases don’t provide enough visual feedback to the user to fully utilise the benefits of a drag and drop system – easy, direct manipulation of information on screen.

Drag and Drop functionality within Flex is pretty solid. It works out of the box with inbuilt components, and adding it to custom components is relatively straight forward (once you understand the order of all the events in a drag-drop interaction by reading this PDF- http://blogs.adobe.com/flexdoc/pdf/dragdrop.pdf). It also allows for a reasonable amount of customization to the visual states during a drag-drop process, with the exception below.

Flex provides two possible behaviours when an object is dropped:

1. The drop is rejected and the dragged item animates back to it’s original position
2. The drop is accepted and the dragged item animates into the new position.

These behaviours are correct, however there is no means to override the actual animations that occur as a result of these behaviours, so we are stuck with the following “zoom to mouse position” transition when a drop is accepted (from mx.managers.dragClasses.DragProxy) :

// Zoom into mouse location to show drag was accepted.
var e:Zoom = new Zoom(this);
e.zoomWidthFrom = e.zoomHeightFrom = 1.0;
e.zoomWidthTo = e.zoomHeightTo = 0;
e.duration = 200;
e.play();

var m:Move = new Move(this);
m.addEventListener(EffectEvent.EFFECT_END, effectEndHandler);
m.xFrom = x;
m.yFrom = this.y;
m.xTo = parent.mouseX;
m.yTo = parent.mouseY;
m.duration = 200;
m.play();

This transition may work well when dragging data from one list to another (which is the most common use case when using the inbuilt components), but can look a bit much when dragging a large container around the screen.

You drag an object from one area of the screen to another, and when you release the mouse it scales down into obscurity before appearing in its new position. There should be a means to override this default effect.

In this example try dropping the item in the bottom right corner of one of the (white) drop areas. This transition looks wrong as the mouse coordinates are not always the intended final destination of the dropped object.

Basically there should be some way to define or override the animation that occurs on a successful drop event. It seems surprising that this animation is hardcoded within the framework, while every other visual state during the drag/drop operation is customisable.

I know it is hardly a show stopper, but I’ve submitted an enhancement request to the Flex Bug and Issue Management System (https://bugs.adobe.com/jira/browse/SDK-13472) as it is an UI issue that has already arisen in one of our commercial projects.

– D

Click on the image for the full sized version.

And if you don’t believe me – here’s the evidence: http://coldfusion.sys-con.com/read/450703.htm

The International War Crimes tribunal is probably not the right place to report atrocities such as this, but I’m sure it breaks some part of the Geneva Convention.

And why do so many people blame Flash when they see a page like this? Flash is just the tool, not the actual tool who thought it was a good idea to combine a floating ad, an expanding ad, two video ads, and three banner ads on the top of a single page (and there is more if you scroll down).

There are so many guilty parties involved – including the webmaster, the online advertisers, and especially the person who invented the eyeblaster.

Rant over and out,

Dom

The FDT plugin for Eclipse is a great piece of software (way way better than other flash plugins for Eclipse such as ASDT and FlexBuilder). I use it for all my AS2 flash development. However it has always had some issues with the location of the intrinsic core ActionScript classes in Flash 8 because they reside in a FP7 or FP8 directory (see forum post here and solution here).

While this solution solves the problem of FDT not recognising intrinsic classes such as Object and String, It doesn’t resolve a very nasty potential bug.

DON’T rename a project if you have selected “Refactoring” – “Flash Explorer File Operations” in the FDT preferences.

What happens is it refactors all the intrinsic classes in the core library and renames all the classes in the FP7 and FP8 folders as if the folders were package names. E.g. Object becomes FP8.Object, String becomes FP8.String.

This causes FDT all kinds of problems, and Eclipse hangs while trying to refresh the workspace (while consuming 100% CPU).

This has happened to me on several occasions and it took me hours to work out the issue – i tried cleaning out all the cache and project metadata from eclipse, I tried reinstalling the FDT plugin, all with no success. I eventually set up a new workspace and imported a single project and eventually discovered what had happened.

The only solution is to copy over the core classes (C:\Program Files\Macromedia\Flash 8\en\First Run\Classes) with a fresh copy, or go through and re-edit each intrinsic class.

I’ve posted the bug here.

I was looking for an simpler way of setting default values for function parameters in ActionScript2. The way I usually do this is something along the lines of:

function set value(s:String):Void
{
if(s == undefined) _value = s;
else _value = "default";
}

One option is using a logical OR operator to set default values. For example:

function set value(s:String):Void
{
_value = s || "default";
}

According to the flash LiveDocs a non-Boolean logical OR operation first converts the first operand (i.e. the expression on the left of the ||) to Boolean and if true returns the resolved value of the first operand. Otherwise it will return the resolved value of the second operand (expression on the right of the ||)

In the use case above it works fine, but after exploring the non-boolean implementation of the OR operator we found the following behaviour. In both the string literal (“hey”) and the string variable (s), the Boolean value equals true, but when placed in a logical OR operation they return different results. See below:

var s:String;
s = "hey";
trace(Boolean(s));//true
trace(Boolean("hey") //true
trace("hey" || "dude");//"dude"
trace(s || "dude");//"hey"

Can anyone explain why the String literal is treated differently than a variable containing a String literal?

Oh and word up to Ian on this one for his input :)

[UPDATE] I know I could have gone with “toBoolean() || !toBoolean()” for the title but I think that is taking it a little too far.

[UPDATE 2] The only gotcha with this approach is with numbers as a value of zero converts to false.

I attended WEBDU the other week and had some thoughts after listening to one of the sessions – Geoff Bowers’ “taming the code”.

Amazingly over half the people in the audience weren’t using any form of version control. While we’ve been using version control for a few years now on our flash projects, It made me think about the development methodologies and processes that we have developed in the flash team at Massive over the last few years, specifically in relation to maintaining a common centralised code base.

The way i see it, there are two types of common code libraries – constant and evolving.

Constant code base
This comprises of functionality that rarely changes. Good examples of this are utility classes (e.g. trimming white space on a String or a generic XML parser). These classes are added to over time (in the case of utility classes as new conversions/formats are required), but the usage of existing methods remains the same across all projects – the returned format of a NumberUtil.toDollarsAndCents() method is always going to need to return a string with 2 decimal places.

Evolving code base
This is the common code base that evolves over time. At massive this is primarily the frameworks we use for our applications. While there is little change individually from project to project, over time our processes evolve and all the subtle improvements add up to a distinctly different framework. A project that is only 6-12 months old looks and behaves quite differently to a project started today.

Despite this, it is still necessary to version control the code base for our frameworks – because the alternative is to copy and paste core classes by hand every time we start a new project – yuck! At the same time we don’t want to have to maintain backwards compatibility in our common code base just in order to be able to recompile old projects.

Solution

Our solution to this problem has been to not version control the actual classes for our frameworks, but instead version control scripts that can automatically generate them. This way each project has its own version of the core classes that are fixed within that project, and every new project contains the most recent set of classes and structure.

There are heaps of benefits to this approach – not only do we not have to worry about breaking old projects – but we gain an extra level of standardisation across our projects no matter who initially creates them. Setting up a new project by hand can take hours and is often the most tedious part of the process. Automating this process saves time and heaps of monkey work.

Because we primarily use Eclipse for our actionscript development, we’ve been using Ant for all our build scripts (Eclipse has inbuilt support for it). Initially our scripts were responsible for creating a few folders, and some stub core classes. Over time we have extended this further to auto-generate project specific build scripts for both compiling a project and also creating specific class types on demand.