The Specific Requirements

BombaySapphire.com - that’s a typical example. The requirements for the application loading can be summarized in the following diagram, where the gray bars depict the life-span of the different visual phases of the Bombay application, and the red ones are showing the time needed for loading the various parts and data, comprising the application. In case you wonder the LDA abbreviation stands for Legal Drinking Age validator.

Instead of having all the gray bars be part of a monolithic whole, the guys from Adobe had provided us with the 2-frame Flex application model, where the first frame of the application is solely devoted on the preloader, while the second is available for the actual application.

In the rest of the article I’m going to describe how to setup not just a skinned preloader, but a totally custom preloader. For those interested in just skinning the default Flex preloader - mx.preloaders.DownloadProgressBar - you should continue with Jesse Warden’s great article on the topic. But before proceeding with the implementation of the IPreloaderDisplay interface, we need to take a look at the Flex SystemManager and its responsibilities and also to get familiar with some events that the Preloader dispatches.

The Flex SystemManager

1. The SystemManager is the first display class created within a Flex application.
2. It is responsible for creating the Preloader and handling its events.
3. The SystemManager is also responsible for advancing the Flex application to the second frame once the application SWF is fully downloaded.

Besides these responsibilities directly related to the Preloader, the SystemManager is also responsible for:
4. Managing an application window and sending events if the size of the window changes.
5. Maintain tooltips, cursors and popup windows.
6. Expressly trapping the keyboard and mouse activity.
7. Some other stuff, I hadn’t time to read about.

Preloader’s most important events

1. ProgressEvent.PROGRESS
This is a typical progress event - it indicates what part of the application is loaded.
2. FlexEvent.INIT_PROGRESS
This event is dispatched when the Flex application completes an initialization phase - once the application SWF is fully loaded, the SystemManager advances the playhead to the next frame. Usually you’ll need to control the specific moment when the application advances to the second frame in the 2-frame model. In the samples below I’ll show one ways to achieve this - basically you need to capture the event, store it as pending and suspend the succeeding dispatches of these type of events - later you should re-dispatch the stored pending event.
3. FlexEvent.INIT_COMPLETE
This is the last event the Preloader dispatches. Next the Preloader should dispatch Event.COMPLETE indicating that the SystemManager is ready to remove the Preloader and to add the application to the display list.

Implementing the IPreloaderDisplay interface

I think this is the right place in the article to show you a sample implementation of the IPreloaderDisplay interface. Let’s start with the trivial part of the interface - some background and stage related properties. In the IPreloaderDisplay these are defined as get and set functions, which allows me to implement them by just declaring the corresponding public variables.

public var backgroundAlpha : Number;
public var backgroundColor : uint;
public var backgroundImage : Object;
public var backgroundSize : String;
public var stageHeight : Number;
public var stageWidth : Number;

The most convenient place for adding listeners for the events dispatched by the Preloader-component is in the set preloader() method of the interface.

private var _preloader : Sprite;
public function set preloader(value : Sprite) : void
{
    _preloader = value;

    _preloader.addEventListener(ProgressEvent.PROGRESS, onPreloaderProgress);
    _preloader.addEventListener(FlexEvent.INIT_PROGRESS, onPreloaderInitProgress,
        false, int.MAX_VALUE);
    _preloader.addEventListener(FlexEvent.INIT_COMPLETE, onPreloaderComplete);
}

The last method we must implement is the initialize() method. This method is called right after the Preloader is added as a child. This is the entry point where you can configure your preloader. For example I use this method to draw the background, filling it with a custom pattern or just adding visual components as children to this totally custom preloader.

public function initialize() : void
{
    // e.g. draw a background
    ...
    // or add visual children to the totally custom preloader
    ...
}

Let’s take a look how I handle the above mentioned event FlexEvent.INIT_PROGRESS:

private var readyToAdvanceToSecondFrame : Boolean = false;
private var pendingInitProgressEvent : FlexEvent;
public function onPreloaderInitProgress(e : FlexEvent) : void
{
    if (readyToAdvanceToSecondFrame)
    {
        pendingInitProgressEvent = e.clone();
        e.stopImmediatePropagation();
    }
}

It worths taking note on the way I’m subscribing to FlexEvent.INIT_PROGRESS:

_preloader.addEventListener(FlexEvent.INIT_PROGRESS, onPreloaderInitProgress,
    false, int.MAX_VALUE);

I’m setting the priority of the specified handler to the maximum possible value, making this handler the first one to execute when the event is dispatched.

Duplicating Binary Class Definitions

This probably needs a separate post, but I’ll share it here anyway. It is very possible that you’ll end up using a Flash component as your Preloader. The reasons for such a solution are clear. If your Preloader does a lot of stuff before your main application is even loaded, this better be a separate component. If you choose to put it in the application it will first increase the size of it, and second you’ll need to wait loading the whole application before using it. But making it separate imposes the question whether to use Flash or Flex when implementing it. Making this component a separate Flex application means you’ll have a preloader for the actual preloader, which is acceptable if you find a way how to load and use one Flex application inside of another Flex application. If you’ve done this, please share it with us and write a comment about it. Another thing we can’t rely on is whether the Flex framework is loaded - the size of the framework can be much bigger than the size of the Preloader you want to use.

Well, let’s assume we end up using a Preloader component written in Flash. When I did this I ran into a very subtle problem - duplicating binary class definitions. The picture below illustrates the problem:

The Bombay Application Domain is the domain with the code of the main application. If this code holds a reference to the concrete type of the Flash-component, represented here by the LDA Application Domain we’ll run into trouble if the above application domain contains definitions of same classes - in this example the problematic duplication is the Tweener class. Such a duplication makes the application behave strange and unpredictable.

One way to avoid ugly situations like these is to use the exclude command before compiling the Preloader Flash component. The Flash 8 IDE provided this feature, but unfortunately it was removed from the new Flash IDE that has no such exclude definitions command.

Another way to avoid duplication is to avoid the above application domain to reference the concrete type of the Flash component. All you need to do is to encapsulate the preloader component under an interface Facade, thus the Flash component will conform with the Facade interface and the above application domain will not need to know the concrete type of the Flash component.

A Skeleton Implementation

I want to finish with a skeleton implementation, so you can base your code on it.

IPreloaderContentFacade.as:

package preloader
{
import flash.events.IEventDispatcher;

public interface IPreloaderContentFacade extends IEventDispatcher
{
    function setApplicationProgress(bytesLoaded : Number, bytesTotal : Number) : void;
}
}

TotallyCustomPreloader.as:

package preloader
{
import flash.display.Loader;
import flash.display.MovieClip;
import flash.events.Event;
import flash.events.ProgressEvent;
import flash.net.URLRequest;
import flash.system.ApplicationDomain;
import flash.system.LoaderContext;

import mx.events.FlexEvent;
import mx.preloaders.IPreloaderDisplay;

public class TotallyCustomPreloader extends MovieClip implements IPreloaderDisplay
{
    public static const PRELOADER_CONTENT_URL : String = "preloader_content.swf";

    public var backgroundAlpha : Number;
    public var backgroundColor : uint;
    public var backgroundImage : Object;
    public var backgroundSize : String;
    public var stageHeight : Number;
    public var stageWidth : Number;

    private var _preloader : Sprite;
    public function set preloader(value : Sprite) : void
    {
        _preloader = value;

        _preloader.addEventListener(ProgressEvent.PROGRESS, onPreloaderProgress);
        _preloader.addEventListener(FlexEvent.INIT_PROGRESS, onPreloaderInitProgress,
            false, int.MAX_VALUE);
        _preloader.addEventListener(FlexEvent.INIT_COMPLETE, onPreloaderComplete);
    }

    private var preloaderContentFacade : IPreloaderContentFacade;

    public function TotallyCustomPreloader()
    {
        super();
        loadPreloaderContent();
    }

    public function initialize() : void
    {
    }

    private var loader : Loader;
    private function loadPreloaderContent() : void
    {
        loader = new Loader();
	loader.contentLoaderInfo.addEventListener(Event.COMPLETE, onLoaderComplete);

	var loaderContext : LoaderContext = new LoaderContext(false, new ApplicationDomain());
	var request : URLRequest = new URLRequest(PRELOADER_CONTENT_URL);
	loader.load(request, loaderContext);
    }

    private function onLoaderComplete(e : Event) : void
    {
        preloaderContentFacade = IPreloaderContentFacade(loader.content);
        addChild(MovieClip(preloaderContentFacade));
    }

    private function onPreloaderProgress(e : ProgressEvent) : void
    {
        if (preloaderContentFacade != null)
        {
            preloaderContentFacade.setApplicationProgress(e.bytesLoaded, e.bytesTotal);
        }
    }

    private var readyToAdvanceToSecondFrame : Boolean = false;
    private var pendingInitProgressEvent : FlexEvent;
    private function onPreloaderInitProgress(e : FlexEvent) : void
    {
        if (readyToAdvanceToSecondFrame)
        {
            pendingInitProgressEvent = e.clone();
            e.stopImmediatePropagation();
        }
    }

    private function onPreloaderComplete(e : FlexEvent) : void
    {
        readyToAdvanceToSecondFrame = true;
        if (pendingInitProgressEvent != null)
        {
            dispatchEvent(pendingInitProgressEvent);
        }
        dispatchEvent(new Event(Event.COMPLETE));
    }
}
}

This skeleton implementation is omitting a lot of things a real implementation can have - all depends on the specific requirements of the application you develop. But I think the code above is general enough to serve as a guideline for a concrete implementation.

The Publish/Subscribe Pattern

One of the first things a programmer should acquire about object oriented programming is the attitude not to care. Not to care about the internal workings of an object implementation, not to care about the unrelated details, relationships, component dependencies and underlying technology. Not carrying is not just about avoiding brain stress or being cool, but to put additional effort to achieve exactly 3 things:
1. Encapsulation or please, hide this dirty underwear.
2. Strong cohesion for doing one thing, but doing it right.
3. Loose coupling for being independent and not to need more to get more.

The goal of encapsulation is to expose only enough of a system to allow others to make use of it. We need to hide things in order to allow others not to care about them.

Cohesion refers to the degree in which elements within a system form a single, unified concept, with no excess elements. Cohesion affects the ease with which we can comprehend a system, and also unit test it, thus turning it into more reliable code.

Loose coupling refers to the degree in which a system relies on the knowledge about other components details. Depending on less, means carrying about less.

The Publish/Subscribe pattern is an established approach of reducing coupling in cases where a publisher-component needs to collaborate with other subscriber-components in a way, where this publisher needs not even know about the subscribers existence and the communication between them should remain ignorant of the system topology - the architectural layout between these components.

ActionScript 3 or I should say the Flash (not Flex) Framework provides an implementation of the Publish/Subscribe pattern through the EventDispatcher class. Event dispatchers provide an interface for subscribers to establish and discontinue interest in particular events through the public methods addEventListener and removeEventListener. I won’t go into further detail, because most probably by now you’ve done lots of event handling in Flex and also used Publish/Subscribe on variety of languages and frameworks. Just want you to be aware that this pattern is not just useful technique for programming UI, but a fundamental meaning for reducing coupling.

After you get acquainted with the PureMVC framework’s ActionsScript implementation you’ll notice that PureMVC does not rely on the Flash Framework and instead of using the Publish/Subscribe pattern in the form of dispatching Flash Events they use custom implementation of the Observer pattern (a.k.a. Publish/Subscribe). Well, no matter which implementation is in use PureMVC is a nice sample of how to achieve loose coupling through Publish/Subscribe.

The PureMVC Micro-Architecture

On almost every Flex event organized by the Bulgarian Flex User-group there are guys asking about how to use Cairngorm or PureMVC. As I said before it’s perfectly normal for a beginner to seek for an architecture with which he can approach every new application in relatively uniform way. That’s why I’m writing about Cairngorm and PureMVC - both are pretty general approaches and the focus of this second part is the PureMVC micro-architecture.

As the name says this is an MVC micro-architecture. It’s comprised from Model, View and Controller - all these three are hidden under a Façade - a singleton delegating corresponding responsibilities to the Model, View and Controller singletons. These are the core actors.

The Model caches named references to Proxies, which expose an API for manipulating the data model (including data retrieved from remote services).

The View primarily caches named references to Mediators, which adapt and steward the UI components that make up the user interface.

The Controller maintains named mappings to Command classes, which are stateless, and only created when needed.

The Façade initializes and caches the core actors (Model, View and Controller), and provides a single place to access all of their public methods.

If you pay attention you’ll see 3 new concepts in the above description - Mediators, Proxies and Commands - well, almost new, because these are very similar respectively to the ViewHelpers, BusinessDelegates and Commands from Cairngorm, but they’re definitely not the same and the differences between them are worth noting.

Mediators help us to create or reuse existing user interface components without the need to imbue them with knowledge about the PureMVC application they communicate with. The benefit of using Mediators is they can be positioned closer to the view compared to the Cairngorm ViewHelpers. Being closer Mediators can handle immediately user interaction events that are not significant for the whole application, but just for the sake of the UI components comprising the corresponding view. Just like ViewHelpers, Mediators can be retrieved from the View and used within Commands or other Mediators. To register or retrieve a Mediator, you should use the Façade. Another advantage is the ability to use immediately Proxies without the need to trigger execution of Commands - this is not the way Cairngorm works - BusinessDelegates are invoked only from within Commands.

Proxies help us to expose data structures and entity classes (and the domain logic and services that support them) to our application in such a way that they may be easily reused elsewhere, or refactored with a minimum amount of impact to the rest of the application. Major thing to note is that we can use Proxies to simply manage a reference to a data object, and interact with this data object synchronously through the getData() and setData() methods. This seems to me messier than the approach used in Cairngorm. While in PureMVC you can use the Proxies for both synchronous and asynchronous interactions with data, Cairngorm makes clear separation between these two types of interaction - you can only interact synchronously with the data stored in the ModelLocator and every time you need to store or retrieve data from the back end, which is asynchronous operation you should use BusinessDelegates. Another point to ponder is that Cairngorm also advocates clear separation of services from the BusinessDelegates with the use of the ServiceLocator - a centralized storage for all the services the application consumes. PureMVC provides no such separation, but you can always try to organize your Proxies in a layered fashion where synchronous and asynchronous interactions are on different layers.

I won’t say much about the Commands, because you’ll find them pretty analogous to the Cairngorm commands.

Conclusion

In conclusion I should say that you really need to read the documentation for the framework you’re planning to use, especially if you’re a beginner or have not enough experience to accept or reject such a reasonably looking micro-architectures like PureMVC and Cairngorm. Take PureMVC for example - if you read carefully the documentation you won’t omit the Goals&Benefits section, which clearly states the following under Goals:

This simply means that the PureMVC is avoiding the use of Flex, and it’s originally designed not to use Flex. So, where is PureMVC applicable? I should say, it’s applicable to the design and development of big Flash applications, but in cases of big Flash applications it’s always good to take some time to consider doing it with Flex.

Reference

PureMVC.org - the official site of the PureMVC framework

I usually prefer to use very short slides with just enough information on them, but I’m aware that this kind of slides are only effective during the presentation and completely useless after that. Publishing them is not enough, because they are very short and not very informative. So, I write this post in order to be used as notes accompanying the presentation.

Before rushing into the popular Flex application architectural frameworks we need to answer one question.

Why architecture is important?

Alan Kay gave a nice sample on importance of architecture in his OOPSLA’97 keynote and I will use it here too. We can build a decent dog house from almost anything - you just need a hammer, nails and some randomly picked wooden boards. Having a plan is not necessary, but even if we need one it is going to be very simple.

Now, let’s expand this thing about the factor of a 100, thus we can get something with the size of a cathedral. Every engineer should know that scaling this thing 100 times, will actually increase its mass 1,000,000 times and its strength only by the factor of a 10,000, which actually means that the new construction is going to be 100 times weaker than the original dog house. Most probably it’s going to collapse under its own weight.

Well, if you want to stick with small creations and simple structures you don’t need an architecture. But if you want to deal with complex and big structures, then you should start getting interested in architecture - literary the designing and building of successful arches. But to build something expanded by the factor of a 100 we need a new concept - a non-obvious, non-linear interaction between simple materials that would give you a non-obvious synergies and a vast multiplication of materials. As complexity starts becoming more and more important architectures are always going to dominate material, which in the context of this topic simply means that architecture is always going to dominate the technology of our interest. That’s why architecture is important!

A word on architectural frameworks

A framework is defined as a set of cooperating classes that make up a reusable design for a specific type of software, but what’s an architectural framework? We can define an architectural framework as a set of cooperating design patterns that make up a reusable micro-architecture for a specific type of applications. Now as you know what an architectural framework is I can start making an overview of the popular Flex architectural frameworks.

Cairngorm

This is the most popular architectural framework for Flex. It is so popular that developers are starting to overexploit it, as it is some kind of a panacea for the design and development of RIAs. Well, if you have no experience at all, most probably you’ll start with Cairngorm, because of its straight forward usage and the fake sense of confidence it gives to beginners.

Generally speaking Cairngorm is an MVC micro-architecture composed from a FrontController which maps application specific events to commands, a ViewLocator which is a dictionary for ViewHelper classes, a ModelLocator which is the main abstract representation of the application state and data, and a ServiceLocator that stores the variety of services an application consumes. Most of the application logic goes in the Commands implementations. The easiest way to define a command is as the actions and logic that should be performed in response to the meaningful user gestures. By meaningful I refer not just to all user gestures, but only these that trigger the execution of the business logic behind the application.

It’s relatively easy to incorporate Front to Back Development when using the Cairngorm micro-architecture. Basically, you start with some View, define all user gestures and corresponding Events and Commands for that View. Because of the rich component set provided with the Flex framework developing a prototype that broadcasts the defined Events is a piece of cake. The next step is to implement the corresponding Commands. Usually the commands are just updating locally the state of the application stored in the ModelLocator or before updating the model the data is processed remotely from a back end service. To implement such commands that require remote processing the Cairngorm team proposes the use of BusinessDelegates which encapsulate the whole request-result logic. You only need to configure the needed BusinessDelegate by providing it with result and fault handlers. Usually these handlers are functions within the Command that uses this BusinessDelegate. By the time you build the prototype, most probably you won’t have an available back end application. If that’s the case, you can use mockup BusinessDelegates, which process the data locally and return fake results. As soon as the back end is ready you can easily switch to remote processing and real data, but instead of waiting for this task to be accomplished you’ll have already evaluated the prototype with the customers and the precious feedback is going to be available much sooner, thus boosting requirements elicitation, customer communication and satisfaction, and drastically improve the overall user experience.

Another way to approach Flex application development is Feature Driven Development. First, you need to build the overall application model. Second or in parallel, you need to compile a list of required features. It is useful to map features to user gestures, which in the context of Cairngorm can be mapped to Commands. With Cairngorm it’s easy to streamline the development of Commands - you can easily define concrete steps for implementing every feature - something like, define and dispatch Event from View, create entries in the ModelLocator, implement the needed BusinessDelegate, implement the Command that updates the model and finally define a mapping in the FrontController between the Event and the Command. This type of streamlining can be useful within big projects with 10,000 features and a staff of 100 not very experienced developers. You start dividing this huge list of features into sets, that can be developed and deployed within short iterations - usually 2 weeks. Well, that’s a Feature Driven Development!

Don’t get me wrong Front to Back development and Feature Driven Development are not orthogonal approaches. Combining them is an intelligent decision, but this is a matter of a different discussion.

Some words of warning

By the time, you get to this paragraph, you should have some really nice impressions on Cairngorm. It looks like you can handle almost everything with this so influential framework, but you should be aware of the huge disadvantages, which you’re about to uncover in the middle of the development of your next big Rich Internet Application.

First, the number of Commands can easily grow from 10 to 1,000. By the time you hit the count of 100 you’ll realize that most of the Commands are very similar, just differing in the type of data they process. This huge number of Commands means huge number of classes, which leads to a huge size of the application, not to mention the annoying compilation time. You should start thinking about generalization and new ways to reuse this repetitive logic.

Second, as the project grows in complexity it’s model or application state stored in the ModelLocator are going to get very complicated. It’s kind of difficult to decompose this model into something smaller, more granular and not that monolithic.

Third, in cases of complicated user interaction the logic for that interaction appears too far from the View. Commands that need to manage and use the Views are utilizing the ViewHelper classes. While this sounds reasonable in the context of this architecture, I see no point in getting through the whole Cairngorm cycle of processing of events to execute some logic that should be rather positioned near the View. Well, it’s just the way how Cairngorm tries to uniformly treat every user gesture.

What’s next?

Part 2 of this topic is going to be about the PureMVC architectural framework. In Part 3 I plan to show you a very different approach - an approach more natural to Flex. You don’t need more to get more! So, stay tuned!

Reference

Introduction to Flex Application’s Architecture - the slides of the talk I gave at the Sofia University
Alan Key: The Computer Revolution hasn’t happened yet OOPSLA 97
CairngormDocs.org - a community driven site, devoted on systematizing the documentation and learning resources for the Cairngorm micro-architecture for Adobe Flex.

Well, I find this feature very useful - the size of the ScrollThumb is giving the user a hint about the amount of content that needs scrolling. But vanity has almost never been in favor of usability, so I’ll have to share with you how to accomplish this further amputation of the scrollbar features.

To make a fixed size ScrollThumb you need to do roughly two things:
1. To extend the ScrollThumb class by overriding the setActualSize() method.
2. To replace the ScrollThumb on the existing ScrollBar instance.

I’m providing a sample application with a View Source option, so you can check how I’ve implemented the FixedSizeScrollThumb and how the scrollbar is skinned:

I prefer to specify the size of the FixedSizeScrollThumb with styles. In case of a very tiny thumb it’s useful to make the hitArea of the thumb a bit larger. I use styles again to specify this additional padding for the hitArea.

Now, we’re ready to replace the traditional ScrollThumb with the new FixedSizeScrollThumb, and this is the most tricky and controversial part of the task. I use a simple utility class ScrollBarUtil, which provides the static replaceScrollThumb method:

public static function replaceScrollThumb(scrollBar:ScrollBar):void
{
    if (scrollBar != null && !(scrollBar.scrollThumb is FixedSizeScrollThumb))
    {
	scrollBar.removeChild(scrollBar.scrollThumb);

	var fixedSizeScrollThumb:FixedSizeScrollThumb = new FixedSizeScrollThumb();
	fixedSizeScrollThumb.x = scrollBar.scrollThumb.x;
	fixedSizeScrollThumb.y = scrollBar.scrollThumb.y;

	fixedSizeScrollThumb.styleName = new StyleProxy(scrollBar, null);
        fixedSizeScrollThumb.upSkinName = "thumbUpSkin";
	fixedSizeScrollThumb.overSkinName = "thumbOverSkin";
        fixedSizeScrollThumb.downSkinName = "thumbDownSkin";
	fixedSizeScrollThumb.iconName = "thumbIcon";
	fixedSizeScrollThumb.skinName = "thumbSkin";

	scrollBar.scrollThumb = fixedSizeScrollThumb;
	scrollBar.addChildAt(fixedSizeScrollThumb, scrollBar.getChildIndex(scrollBar.downArrow));
    }
}

This method needs an initialized ScrollBar instance, which you can get usually like this:

ScrollBarUtil.replaceScrollThumb(
    ScrollBar(someFlexContainer.rawChildren.getChildByName("verticalScrollBar")));

By now, we know how to replace the ScrollThumb, but still we don’t know when to do it. Which is the moment when the container’s scrollbar is available and needs to change its thumb? In the sample above I’m using the updateComplete event handler of the Flex Container.

I know this ScrollBar looks more like a VSlider or HSlider, and maybe you will try using a skinned slider instead of a scrollbar, but you should be aware that this approach will need custom code to detect whether the content needs scrolling, which is already implemented in the Container class from the Flex Framework.

But you should be aware that Adobe Flex effects are designed to be used with UIComponent components, so replacing with Sprite and Bitmap will cause problems, which beside the obvious run-time errors, can be really difficult to debug and correct.

Let’s observe a typical issue with Flex CompositeEffect effects, such as Parallel and Sequence effects. I want to animate simultaneously some sprites - the sprites should move horizontally and fade slightly. But as you’ll see in the sample application, only the bottom sprite is animated, the rest two are just jumping to their end positions:

This is completely unexpected behavior and you will get no run-time error whatsoever. We should dig deep to see what’s going on?

Well, at least we see what’s happening. Only the bottom sprite is animated, so it looks like the Parallel is not getting its children effects targets correctly. Let’s see the CompositeEffect.getChildrenTargets() method. The following excerpts are getting my attention:

var resultsArray:Array = [];
var results:Object = {};
//…
results[childTargets[j].toString()] = childTargets[j];
//…
for (var p:String in results)
{
    resultsArray.push(results[p]);
}
return resultsArray;

The results object is an Object instead of a Dictionary, therefore only String can be used to index the child effect targets. But the sprite.toString() method will return always the same string [objects Sprite], and the results object will index only one of the sprites and eventually the resultsArray will end up containing only the last sprite.

To avoid that and to index all sprites with different strings, we can use FlexSprite instead of a simple Sprite. Actually the FlexSprite adds only a unique name to the Sprite and also overrides the toString() method with the use of the NameUtil:

override public function toString():String
{
    return NameUtil.displayObjectToString(this);
}

This implementation will return the string indicating the location of this object within the hierarchy of DisplayObjects in the Application.

This is the same sample application, but Sprite is now replaced with FlexSprite:

Now it functions as intended!
FlexBitmap overrides Bitmap in exactly the same way, and you should always use FlexBitmap instead of Bitmap in such situations.

To do that open the Terminal application, and start typing the change directory command, which is cd followed by the new location. When you type the location you can start with / - the root directory, type few symbols, then hit Tab and the command shell will try to auto complete the rest of the directory name, thus assuring you that what you type is correct.

You should be aware of that the command shell is case sensitive, so if the auto completion doesn’t work, probably you’ve started typing with the incorrect case. When you’ve done typing the file location, instead of executing the cd command, you can select and copy that location.

If there are any spaces in the file location, the command shell will escape them prefixing every space with the \ escaping symbol.

The moral of the story is that designers work rather with great variety of assumptions than with fixed requirements about how the creation is going to be used. In this particular case the Windows designers have predicted correctly that copying the file name might be in handy, in opposite to the Apple designers which have easily overlooked this mini feature.

To be honest I haven’t done any thorough research on how to accomplish copying the file name to the clipboard on Mac OS X and I’ve approached the problem as I would approach it in Windows. But it turns out that there is even easier way to copy the file name. You need to open the Finder application, navigate to the file location, select the file, then chose from the main menu Finder>Services>TextEdit>New Window Containing Selection. The TextEdit application will open a window that contains the file name encoded in URL encoding.

But now it’s time to explain shortly what this blog is going to be about.

As the title says it’s going to be about personal computing. It’s going to be a huge criticism on the current state of personal computing and it will reveal to you a very intimate and controversial journey towards an improved personal computing. I’m planing to publish not only technical stuff that you can use in your daily job, but also philosophical disputes about programming, software engineering, design in general and simply how to use computers to make our lives better.

Feеl free to suggest me topics to write about!

My first major post will be about how do I imagine a more sophisticated and yet simplified personal computing. This post should serve as a long-term goal and as an abstract roadmap of my journey towards a better personal computing.

In the mean time I’ll write about some Adobe Flex issues me and my colleagues in Gugga have discovered during our latest project.

So stay tuned!