Interfaces and why MM needs to take the tutorial

OK I don't have the time for a long blog entry and you don't have time to read it lol. So this is the first in a series of thoughts on why and how Flash needs to improve as a development platform.

No its not another MM components bash, anyway as a maker of Flash components ourselves we wouldn't have much credibility if all we did was bash them.

What I hope this is, is some serious, reasoned and constructive arguments about ways in which things could be improved for all of us.

As I have said before, with FMX2004 MM wear two hats, developers of an application platform and developers of a component set. If its easier to see it this way they are like MS, developer of Windows and developer of Office.

Many people have complained about the bloat of MM Components and a number of third party developers have stepped up to provide lighter alternatives but as some one commented recently its not difficult to make a lighter component, the question is not is it lighter but what functionality did you leave out to make it lighter.

In almost every case the answer includes Focus and Depth Management. To be honest I don't believe Focus or Depth management SHOULD be part of a component developers task, its a platform level task not component level.

Focus and Depth management in the player are broken or lack the features needed for real application development. To their credit MM realized this and fixed it in FMX2004. Unfortunately they didn't fix it in the player but instead fixed it in actionscript code but by itself that's not really so bad.

So why don't third party components make use of these fixes provided by MM?

Well the answer to that lies in the implementation. Taking FocusManager as an example, FocusManager imports the UIObect, UIComponent and SimpleButton classes directly and many other classes indirectly. These classes are basically the "core" of the component framework that you are trying to replace so you have basically shot yourself in the foot as your slim component is now even more bloated then the original component you are trying to replace! Not a good idea.

So here we see we have a key element at the platform level bringing in most of the component level classes. The question is why does it need to do that?

If you go through the code you can break the reasons down into two categories first as an identifying "tag" i.e. the FocusManager wants to only process certain object so it specifies that they must be UIComponents for example and secondly so it can call methods on objects, for example to call setFocus.

Ok fair enough that is needed and probably your first reaction is well ok how else could they have done that?

So the platform level is inextricably linked to the component level, you cant have one without the other and therefore third party developers have to leave it out.

But there is an alternative way that this could have been designed so that the two levels aren't linked;

By using Interfaces.

Using interfaces is almost second nature in Java, it is very common to find Interfaces being defined and then implemented in Java. Incredibly, with FMX2004, MM gave us Interfaces so we could do just that, and then basically threw them out the window and ignored them when it came to writing there own code.

So how might they be used?

Well first where a "tag" is needed, lets say you want to identify those objects that will come under your Focus Mangement, you can define an IFocusable interface. For a tag interface it needs not define any methods at all a class just implements it to sort of put its hand up and say "me to". In Java you can see this with things like the Serializable interface, its just says, ok save me.

Now the second part was where we need to actually execute methods but this is also straightforward we could simply add those methods to our IFocusable interface. So when I implement IFocusable I am saying I want to be managed and I know how to react to a setFocus call.

The FocusManager then doesn't care about what type of object you are just that you implement that interface. FocusManager has no link to the component level other than a small IFocusable interface class so now it happily can mange both the MMComponents and third party components without being bound directly to either of them.

As I mentioned FocusManger also includes the SimpleButton class (which derives from UIComponent). It does this because it has to implement a system default push button functionality and it needs to be able to execute an action when some user action results in a default "click". It might seem harder to follow but again here an interface solves the problem. We just define an IDefaultClick interface which defines the signatures for methods that the FocusManger needs to use, any class can implement that interface not just a SimpleButton and again everything works without mandating that only certain specific classes are acceptable.

Now before you worry that with the framework being already bloated the last thing we need is more classes, lets understand that interfaces don't contain code or method implementations, they simply contain definitions or signatures of methods. They are very light weight and probably would only add a few hundred bytes to your movie but in return you now have a way to integrate a wider range of components into your clips, ones that might indeed be lighter or have functionality that the standard set don't have and yet they could still provide the basic platform level functionality that any real application needs.


This only starts to scratch the surface of where interface's could be used to improve the current architecture and provide us all with a trully open development platform.

I hope also you can maybe start to see that interfaces could be a way to start to break down the "framework" as a single monolithic block and start to make at a series of interchangable services.

Anyway maybe more thoughts later when I get some time.