Fast forward to 2007. I happen to have multiple computers at home, so I’ve been using Google Docs to store some of my critical information so that I don’t have to worry about which computer I’m using. And.. guess what? Google Docs is completely hosed right now (at least for me).

It’s a weird feeling to not be able to access my own data until someone else fixes their problem. Maybe I should have thought about that before putting my data in the cloud…

That having been said, I have a number of concerns. Maybe concerns is too strong. Let’s put it this way. I have some hopes about how Adobe goes about this.

I hope they find a way to make Buzzword available freely to everyone instead of just trying to sell to corporations. There was a bank robber by the name of Willie Sutton, who when asked why he robbed banks, replied: “That’s where the money is.” In a sense, this is why companies try to sell software to large corporations.

The most likely scenario that I can imagine is that they try to put Buzzword together with Acrobat and their newly announced Share product into a sort of office suite that they sell at relatively low cost (~5k?) to corporations. Why do I worry about this?

1. Online applications are a potentially disruptive technology, but only when combined with easy availability. Look at the inroads that Google docs has already made. That application looks like a toy compared with Buzzword (no offense to Sam and Steve and the rest of the Google docs gang). But if Buzzword becomes a behind-the-firewall application that only large enterprises purchase, it won’t get the momentum it needs to move forward.
2. In the enterprise, a better product is not necessarily the most important thing, and Adobe is not yet a company that has a proven track record of selling to enterprises. That’s not to say that Adobe couldn’t get there someday, but it’s hard.
3. I’m just speculating about pricing, but a mid-priced (5k?) product is a very difficult product to sell. It’s not expensive enough to warrant a salesforce, but it’s too expensive for people to try out and adopt virally.

In general, I am usually skeptical of freemium models, but in this case, I think it’s the right one. (free product + premium offerings + expensive software sales for enterprises).

I hope Adobe doesn’t stretch itself too thin by trying to do too many things. Let’s count the fundamental shifts that Adobe is trying to undergo, all at the same time:

1. Become a platform company.
2. Become a technology provider to the mobile industry.
3. Become an enterprise software company.
4. Become a company that delivers software as a service.

Any one of these is potentially transformative, and very difficult to achieve. Trying to do it all is very scary. Maybe Adobe will pull it off, but I would feel more comfortable if the company was trying to do fewer things.

I hope Adobe finds a way for the Virtual Ubiquity guys to continue working as if they were at a startup. Even when everyone is doing everything right, organizational dynamics tend to change when a smaller company is absorbed inside of a larger one. And this space right now is going to get so competitive that I would rather bet on a small startup than a large company. Or better yet, I hope they can harness the power of both.

~

So those are my hopes. Overall, I am very bullish. Buzzword is an amazing piece of software, and the Virtual Ubiquity team is outstanding. Adobe leadership is smart and determined. The space is undeniably exciting. I am 100% sure that in 10 years, the way that people use productivity software will have completely changed. So Adobe is getting into a very exciting game with a great product. There is a lot of competition out there, and Adobe has a number of challenges ahead. I hope they come out on top.

As it turns out, I have decided to leave Adobe.

The reasons are complicated, but my decision was somewhat sudden and unexpected, so I am not quite sure what I’ll be doing next. If you have any ideas for me, let me know! For the time being, I won’t be posting much until I figure out what I’ll be doing.

Thanks to all the great people I met along the way. It has been tremendous fun. I will be rooting for Flex from the sidelines.

After step 2, there was very little refactoring to do. I removed the DragTile class once and for all, and I added styles back in. The way that the Flex styling mechanism works, you can implement styles for non UIComponents, and that’s what I did. Each Layout object can have its own styles.

I created another concrete layout called CircleLayout to make sure that the layout was actually assignable at runtime. This exposed a few bugs, which I fixed. I factored out the common code between TileLayout and CircleLayout into a common concrete superclass, called Layout. In the end, the inheritance hierarchy for the layout managers looks like this:

I also “fixed” some nitpicky things along the way. I’ve always thought that the drag/drop feedback was a bit confusing, so I changed the behavior in a subtle way (see if you can spot it!).

In the end, the true test of whether this refactoring worked is to see how easy it is to add a new layout. Whereas the original DragTile code was 600+ lines of code, the CircleLayout code is only about 100 lines of code, and all of it pertains to geometry. There is virtually no code in there to manage renderers or animators or anything like that.

public class CircleLayout extends Layout
{
// ILayout interface
override public function getMeasuredSize():Point
{
	return getMaxSize();
}

override public function findItemAt(px:Number, py:Number, seamAligned:Boolean):Number
{
	// Can't execute this if we aren't attached to a container.
	if (!container || container.renderers.length == 0)
		return NaN;

	// Get the radius and center of the circle.
	var radius : Number = Math.min(unscaledContainerWidth, unscaledContainerHeight) / 2;
	var hCenter : Number = unscaledContainerWidth / 2;
	var vCenter : Number = unscaledContainerHeight / 2;

	var angle : Number = Math.atan2(py-vCenter, px-hCenter);
	if (angle < 0)
		angle += 2 * Math.PI;

	// figure out the closest "item" by working backwards from the angle to the index, using floating point math.
	var result : Number = container.renderers.length * angle / (2 * Math.PI);

	// depending on whether this is seam aligned, do a ceil or round.
	result = (seamAligned) ? Math.ceil(result) : Math.round(result);

	// do a modulo op to make sure that this is within [0, length-1]. Modulo is the correct
	// operator in this case because this is a circle.
	result %= container.renderers.length;
	return result;
}

override public function generateLayout():void
{
	// Get the radius and center of the circle.
	var radius : Number = Math.min(unscaledContainerWidth, unscaledContainerHeight) / 2;
	var hCenter : Number = unscaledContainerWidth / 2;
	var vCenter : Number = unscaledContainerHeight / 2;

	// Find the max item size.
	var maxSize : Point = getMaxSize();
	var max : Number = Math.max(maxSize.x, maxSize.y);

	// Inset the radius by the max size.
	radius -= max;

	// Loop through the items and position them.
	var length : int = container.renderers.length;
	for (var idx:int = 0; idx < length; idx++)
	{
		var renderer:IUIComponent = container.renderers[idx];
		var target:LayoutTarget = animator.targetFor(renderer);//targets[idx];

		// evenly space each item over 2*pi radians.
		var angle : Number = (2 * Math.PI) * idx / length;

		// position items on a circle.
		target.scaleX = target.scaleY = 1;
		target.item = renderer;
		target.unscaledWidth = renderer.getExplicitOrMeasuredWidth();
		target.unscaledHeight = renderer.getExplicitOrMeasuredHeight();
		target.x = hCenter + radius * Math.cos(angle) - target.unscaledWidth/2;
		target.y = vCenter + radius * Math.sin(angle) - target.unscaledHeight/2;
		target.animate = true;
	}

	// If there is more than one item, and if there is a drag target, nudge the items next to the drag target
	if (length > 1 && container.dragTargetIndex >= 0 && container.dragTargetIndex < length)
	{
		// Find the items to the left and right of the target.
		var leftIndex : int = (container.dragTargetIndex + length - 1) % length;
		var rightIndex : int = (leftIndex + 1) % length;

		var leftTarget : LayoutTarget = animator.targetFor(container.renderers[leftIndex]);
		var rightTarget : LayoutTarget = animator.targetFor(container.renderers[rightIndex]);

		// exaggerate the difference between the two targets by a factor of maxSize/2.
		var dx : Number = rightTarget.x - leftTarget.x;
		var dy : Number = rightTarget.y - leftTarget.y;
		var distance : Number = Math.sqrt( dx*dx + dy*dy );

		leftTarget.x -= dx / distance * max/2;
		leftTarget.y -= dy / distance * max/2;
		rightTarget.x += dx / distance * max/2;
		rightTarget.y += dy / distance * max/2;
	}
}

protected function getMaxSize() : Point
{
	// Can't execute this if we aren't attached to a container.
	if (!container)
		return new Point(0, 0);

	// Find the max item size.
	var maxWidth : Number = 0;
	var maxHeight : Number = 0;

	if(container.renderers.length > 0)
	{
		for(var i:int=0;i<container.renderers.length;i++)
		{
			var itemRenderer:IUIComponent = container.renderers[i];
			maxWidth = Math.ceil(Math.max(maxWidth,itemRenderer.getExplicitOrMeasuredWidth()));
			maxHeight = Math.ceil(Math.max(maxHeight,itemRenderer.getExplicitOrMeasuredHeight()));
		}
	}

	return new Point(maxWidth, maxHeight);
}

Could this be improved? Sure. There are still linkages between the layout and the container that we should probably get rid of. But for now, I think I’m going to stop. Maybe I’ll refactor the rest of it away later. :-)

Code for the final version can be found here.

Until now, we have not had to worry about the contract between the container and the layout manager. All we did in step 1 was decide which methods belonged in the superclass and the subclass on a somewhat haphazard basis.

Now that we want to move this into a separate helper object, we need to ask ourselves how the main object (the container) needs to communicate with the helper object. A good starting point is to look at the members that the DragTile subclass defines.

All of the properties (green dots) seem to be specific to DragTile. Meanwhile, three member functions at the bottom look truly general: measure(), findItemAt(), and generateLayout(). Let’s use these as our initial interface for ILayout.

Because measure() is a method defined on IUIComponent, It doesn’t make sense to just move it to a non-UIComponent object. Instead, I decided to define a helper function, getMeasuredSize(), that we call from the measure() function. And thinking through some of the other complexities that might arise, I added an attach() and detach() method so that the layout manager could do some initialization and cleanup whenever it was used. The interface now looks like this:

I now had to make this “real” by creating a layout property of FlexibleContainer and creating a concrete implementation of ILayout called TileLayout.

How do we get from where we are in step 1 to where we need to get to in step 2? In step 1, DragTile is a subclass of FlexibleContainer. After step 2, we know that there won’t be a class called “DragTile” anymore.

This seems like a hard change to make incrementally, and the whole point of refactoring is to do these changes in small, incremental steps. Which brings me to the next tip.

Tip 5: If needed, build temporary scaffolding to make sure your code continues to “work” as you refactor.

In this case, I used both inheritance and delegation while I was in the middle of the refactoring. In other words, I wrote a little bit of scaffolding code to keep the DragTile class around even after I had created the TileLayout class, and slowly moved code over from one to the other.

For those of you who are not familiar with the ideas behind refactoring, this writing of temporary code might seem kind of insane. However, once you get used to it, you will never go back. Big changes are much easier to do successfully in small, bite-sized pieces. Sometimes this means writing a few lines of shim code to hold things up as you change things incrementally.

The next step was to move all the functionality out of the DragTile subclass. During this phase, I didn’t move entire methods. Instead, I dissected methods line by line and moved the correct functionality over to the appropriate class using the following simple rules:

• If the logic contained in the line of code was “general”, it move it to the FlexibleContainer superclass
• If the logic contained in the line is specific to tiles, move it to the “TileLayout” class

This process worked fine for most of the logic, but the styles were a different matter. TileLayout is not a UIComponent, so it doesn’t participate in the CSS system. Meanwhile, the styles that DragTile defines are specific to tiles (vGap, hGap, etc). While it is possible to have things that are not UIComponents participate in CSS, it takes a lot of work, and I didn’t feel like tackling it right then.

What I decided to do was to turn off the style functionality temporarily. This brings us to the next tip:

Tip 6: When temporarily disabling functionality during a big refactor, be sure to do so in a way that preserves information, ideally through stub functions.

One way to turn off the CSS functionality would have been to comment out the lines of code that refer to CSS and restore them later. The problem with this approach is that it is difficult to make sure that the the code inside your comments continues to be “correct” as you move your code around.

To help make sure that the CSS knowledge that was embedded in Ely’s code didn’t get lost, I created a stub getStyle() function that always returned NaN. This meant that all of the CSS logic in Ely’s code was still there and still functioning, but it was attached to a CSS style sheet where nothing was ever defined.

By keeping Ely’s code alive, it was easy to make sure that I was making the right edits to it as I refactored. As I moved code around, the compiler would remind me if I was doing something terribly wrong. This doesn’t prevent all coding errors, but it helps prevent many of them.

After all this, I was able to move all of the code from the DragTile code into one of the other two classes. The final version of the DragTile class looked like this:

public class DragTile extends FlexibleContainer
{
	public function DragTile()
	{
		super();

		layout = new TileLayout();
	}
}

We are now (obviously) at the point where we can get rid of the DragTile object. Code for step 2 can be found here

Back? Ok. Now, let’s look at some code.

Step 0 – the starting point

The original files for my investigation can be downloaded from Ely’s site, or you can get my slightly munged version here.

Step 1 – pull up the FlexibleContainer superclass

Even though we said we were going to use composition instead of inheritance to separate these classes, we do this as a first step because it is easier than pulling out a helper class.

Tip 3: Always refactor in small steps that leave the external behavior unchanged

The basic procedure is to create a superclass (which I called “FlexibleContainer”) and to walk through the DragTile code method by method and property by property to move things to the superclass if it seems appropriate.

I started by moving all of the local variables that seemed “general” to the superclass. This included the _items array, the renderers array, and so forth. The variables that seemed specific to the Tile layout were left in the DragTile class.

Because most of these variables were private, moving them to the superclass caused a lot of compile errors, most of which I fixed by moving the appropriate methods to the superclass.

In one case (dragTargetIndex) I needed to create a protected accessor so that the subclass could get at this information. If you want to be a stickler about it, making a private member protected requires some thought. Is this the right way for a subclass to get information from its superclass? In this case, it’s probably not the right thing. The “right” thing is probably to pass the drag information as a parameter during the drag operation. This brings us to the next tip:

Tip 4: When refactoring, don’t try to make it “perfect”. Just strive to incrementally improve the code each time you touch it.

Creating a protected accessor here was the quickest way to separate these two classes without overcomplicating the design. We can come back and fix this later after the dust has settled.

At this point, the FlexibleContainer class and the DragTile class have been completely separated. The outlines look like this.

Original API:

After the first refactoring, the new API looks like this. Remember that our goal here is to put all the logic that is specific to a specific layout (Tile) into one class, leaving as much of the general code in the superclass as possible. The DragTile class should be as small as possible (but no smaller!) :

Source code for step 1 can be found here.

What is refactoring?

Refactoring is the process of incrementally changing the structure of your code without changing the outward functionality. It may seem silly to focus on not changing the functionality, but it is actually pretty important.

The idea is that there are two distinct phases of work: coding and refactoring. During coding, you add new functionality. During refactoring, you restructure your code while making sure that it continues to work properly. Not changing functionality during refactoring gives you a strong reference point as you make lots of iterative changes to the structure. You know your refactoring was successful if the new code still does what the old code did.

Refactoring for better reuse

Usually, you refactor code so that it can be more flexible or more reusable that it currently is. Sometimes, the change that is required is obvious. In other cases, you have to think a little before figuring out how to transform your code.

In this particular case, we want to make it easier to change layouts. Looking at the DragTile code, there is quite a bit that would be the same no matter what the layout is, and relatively little that needs to change with each new layout algorithm. Because the layout algorithm is something that is likely to change in various use cases, it is probably a good idea to isolate this functionality into a separate class.

Tip 1: Cleanly separate out the code that you think will need to change often into a separate class.

The most obvious way to divide up the DragTile layout code from the rest of the DragTile code is through inheritance:

Splitting things up in this way allows us to create a new subclass with a different layout (say, a circle) while reusing the logic that might be common to both, such as the code to talk to item renderers and do animation.

The other main way to split things up is through composition:

In this case, the container delegates to another object in order to do layout. There are a number of advantages to this approach:

1. Using delegates often makes it possible to modify behavior at runtime. After we are finished with this particular refactoring, we should be able to change the layout of one of our containers without reparenting. Woohoo!!
2. Decomposing larger classes into smaller classes can make it easier to evolve different parts of the system separately as needs change. For example, let’s say we later decide to split up FlexibleContainer into two classes: one that is lightweight for easy download, and another that is robust, to handle caching, localization, etc. Should “DragTile” inherit from the light one or the robust one? If layout is handled through delegation, you may not need to choose.
3. Composition often allows for greater decoupling. For example, let’s say you are building a photo organizer module. With the inheritance approach above, it would be difficult to create the module in such a way that the photo module knows absolutely nothing about the layout. With the composition approach, you could provide a default layout (say, Tile), while allowing the user of the module to pass in a different layout if needed.

All of this leads to the next tip, which is:

Tip 2: Think hard before using inheritance. Composition is almost always a better way to separate out the flexible part of a class from the invariant part.

So now we have a general idea of what we want to separate out, and how we want to do it. We’ll start digging into actual code in the next post.

One of my concerns around open sourcing Flex is around how we stay disciplined about what goes into the framework. As it stands, it is quite difficult for the Flex engineers to balance between the things they would like to add to the framework versus practical considerations like download size and runtime performance. We are going to make sure we don’t get bogged down in feature-itis or “design by committee”.

One thing that I think could help is a clearly articulated philosophy about what Flex is, what Flex is not, and how it should evolve going forward. One community that has done a particularly good job at this is the microformats community. In many ways, the microformats movement grew up as a reaction to some of the more ambitious movements around adding semantics to the web. Because of this reactionary nature, the value of practical, small, incremental steps was greatly appreciated by everyone in that community.

As we open up Flex development to the world, my hope is that we can build a strong, core philosophy around Flex that is similarly grounded in keeping things practical, small, and focused.

Today, we announced that we are going to open source the Flex SDK under the Mozilla public license. in my mind, this is just another step in our continued push to open up our platform to make sure that our community can feel confident in building their applications (and in many cases, their businesses!) on top of it.

I’m obviously pretty excited about this, which begs the question: should we have open sourced it earlier? I don’t think so. We have gone through quite a bit of change between Flex 1.0 to where we are now (remember ActionScript 2? remember the old pricing model? remember the huge API shift from 1.5 to 2.0?) and IMHO, it might have been more difficult to make some of the radical changes we did if we were following a completely open process.

Now, the situation is quite different. The Flex community has reached critical mass and is growing daily. The Flex SDK codebase has had most of the rough edges smoothed off of it, and we are at a point where we no longer expect huge API changes in our existing core API. Most importantly, it feels like the right time to invite the community to become part of defining what Flex is.

We are still working out the details, but I think this is pretty exciting. More details can be found here.

Note that this is a more basic (and common?) case than the stuff I was talking about earlier. For more advanced solutions, see here, here and here.

From: XXXX@XXXXXXXXX

I have two loops. One grabs an Xml file that contains a list of a bunch of Xml files I use to layout data to print. (What I am doing is printing a set of documents).

So, as I loop through each, I call the URLRequest to grab the Xml to process and register the Complete event (which takes care of processing the Xml).

So if I have 20 documents, I find only the last one gets handled, the rest are ignored. I am guessing this is because the thread does not stop. I am thinking synchronous events are not an option either.

What I want to happen is one fires, it lets me do what I want to do, then the next one fires. Or alternatively, one is processed, then the next one is processed.

Am I making sense?

Yes, it does make sense, and I bet a lot of people get stuck on this. So here’s the answer.

~

The problem

Let’s take a look at the following (simplified version) of the code that was sent to me:

var loader : URLLoader = new URLLoader();
public function loadItAll(tree: XML)
{
    for each (var elem:XML in tree.elements())
    {
        loader.load(new URLRequest(elem.text().toString()));
        loader.addEventListener(Event.COMPLETE, onComplete);
    }
}

public function onComplete(event: Event)
{
    myXMLResult = new XML( loader.data );
    // handle the URL request here
}

The expectation here was that onComplete() would be called n times, one for each URL request. As it turned out, onComplete() was only called once.

So what’s happening?

Flash network calls are asynchronous, which means that the loader.load() call doesn’t happen right away. In fact, all the code in the for loop runs before any of the network calls happen.

To understand the order of events, it might be easier to use a physical analogy, like asking a valet to go get a car. (It’s easier for me, anyway. I think it’s because of the way human brains have evolved — it’s a lot easier for me to think about physical things like people and vehicles, not network calls and data packets!)

Imagine the following pseudocode.

public function doItAll()
{
    for each (person in line)
    {
        ask the valet to go get the person's car.
        ask the valet to say "car ready" when the car is ready.
    }
}

public function carReady(car: Car)
{
    get in the car and drive home.
}

Remember that all of the ActionScript code has to finish running before the asynchronous methods start executing. In the above psuedocode, the valet takes all the requests for all the people in line before going to get a single car.

As it turns out, this valet is only capable of returning one car at a time (not surprising) and more importantly, can only remember one request at a time. Ack! So when we went through the line of people and asked each one of them for their ticket, he only remembered the last request! This is the reason that only one car is returned.

There are a few ways to fix this problem:
1) Hire lots of valets (one for each person in line).
2) Don’t ask for the next car until the first car is back.
3) Teach the valet to remember multiple requests.

Let’s stop our analogy right here and get back to our original psuedocode for each of these three strategies.

Strategy 1: Hire lots of valets

This is probably the simplest strategy, but it doesn’t work in all cases. Here is the pseudocode:

public function loadItAll(tree: XML)
{
    for each (var elem:XML in tree.elements())
    {
        var loader : URLLoader = new URLLoader();
        loader.load(new URLRequest(elem.text().toString()));
        loader.addEventListener(Event.COMPLETE, onComplete);
    }
}

public function onComplete(event: Event)
{
    var loader = URLLoader(event.target);
    loader.removeEventListener(Event.COMPLETE, OnComplete);

    myXMLResult = new XML( loader.data );
    // handle the URL request here
}

Notice that every time through the loop, we are creating a new URLLoader. Because of this, we have to make sure we are referring to the correct URLLoader during the onComplete() method. We do this by getting the URLLoader from the target of the complete event that was fired.

It’s probably also a good idea to remove the event listener to avoid having lots and lots of URLLoader objects created without being destroyed.

This strategy will not work if you need to have items loaded in a certain order, or if spawning lots and lots of URLLoaders will cause a performance problem. (In this case, I think this is throttled by the network stack, so I think you are OK. In other cases, it might not be OK).

Strategy 2: Don’t ask for the next car until the first car is back

This is probably the next simplest strategy.

var loader : URLLoader = new URLLoader();
var list : XMLList;
var i : int;

public function loadItAll(tree: XML)
{
    loader.addEventListener(Event.COMPLETE, onComplete);
    list = tree.elements();
    i = 0;
    loadNext();
}

public function loadNext()
{
    if (i < list.length())
    {
        var elem: XML = list[i++];
        loader.load(new URLRequest(elem.text().toString()));
    }
}

public function onComplete(event: Event)
{
    myXMLResult = new XML( loader.data );
    // handle the URL request here

    loadNext();
}

The cons of this method are that none of the network operations are happening in parallel, which can be a performance problem. Also, the logic to walk through the list of entires is scattered throughout multiple methods. You can clean this up using state objects or other strategies, but you quickly get to strategy three, which is:

Strategy 3: Teach the valet to remember multiple requests

This is the most work, and you can make this as complex as you like. The benefits are that it centralizes the handling of this loop into a single place.

class MyLoader extends URLLoader()
{
   override public function load(string: URL)
   {
       // put stuff on a queue
       // if there are no pending requests, call loadNext();
   }

   private function loadNext()
   {
       // remove one thing from the queue and load it
   }

   private function onComplete()
   {
       // dispatch the COMPLETE event
       // initiate the next load
   }
}

var loader : MyLoader = new MyLoader();
public function loadItAll(tree: XML)
{
    loader.addEventListener(Event.COMPLETE, onComplete);

    for each (var elem:XML in tree.elements())
    {
        loader.load(new URLRequest(elem.text().toString()));
    }
}

public function onComplete(event: Event)
{
    myXMLResult = new XML( loader.data );
    // handle the URL request here
}

There are a number of things to worry about here, such as whether it is OK to be returning data in loader.data, given that the same object is being reused for multiple requests. Probably the right thing to do is to create a token object (using the AsyncToken class?) that holds all the information and to pass that to the user. And then you can start building callback mechanisms into that AsyncToken. And then... well, it gets more and more complicated.

Details of some more advanced solutions around this can be found here, here and here.