1. Adobe will stop development of the Flash mobile browser plug-in, but mobile operating system and hardware developers are free to continue developing on top of Adobe’s existing source code if they wish to license it from Adobe.
2. The Flex framework will be freed from Adobe’s control, and will become more open under the guidance of an as yet undecided open source foundation which will include Adobe contributors and the Spoon project.
3. Development of the Flash plug-in for desktop browsers continues as normal.
4. Development of Adobe Air, including publishing for mobile apps, continues as normal.
5. There’s renewed emphasis on the Flash platform as a platform for game development.
6. There has been some movement of jobs on the Flash CS Professional team, but the team still exists and the next version of the product is in development.

There’s been a lot of hand-wringing as Flash developers struggle to figure out what this means for them. I don’t propose to resolve that here – what this means for you depends on both your skill-set and your job. But I guess if I had one bit of advice it would be, if Actionscript is the only development language you know it’s well past time for you to diversify your skills. Learning a second programming language makes you a better programmer in general, and learning a third, fourth, etc becomes easier with each language. I have lost track of the number of programming languages I have learnt, but each one has made me a better programmer.

What follows is merely my personal take on the situation. Make of it what you will. I’ll start with an important question.

Why did Adobe buy Macromedia?

For some time I’ve been meaning to write a blog post about why Adobe bought Macromedia (it only happened six years ago ). I don’t actually know the answer, but I have my suspicions and they’re different from those I hear voiced elsewhere.

I suspect it is true that Adobe bought Macromedia to get their hands on Flash. This is a common assumption, and I see no reason for it to be wrong. There was nothing else in the Macromedia toolkit that mattered much to Adobe, except perhaps Dreamweaver which is now taking on renewed significance.

I suspect that the Flash platform tools (Flash Builder and Flash CS Professional) were not the target. These tools are for developers, unlike Adobe’s other tools, and are built atop a free plug-in which Adobe also have to develop and maintain. I also suspect the Flash platform generates far smaller profit margins than Photoshop, Illustrator and InDesign.

One reasonable suspicion is that Adobe bought Macromedia simply so that someone else didn’t. They didn’t want Macromedia’s design tools in the hands of a company with deeper pockets. This may well be true.

But my suspicion is, back when Adobe bought Macromedia, they looked at the application landscape and concluded, as many others did, that the future of applications was as web-based services. They needed a platform on which to develop web-based versions of Photoshop, Illustrator and InDesign and Flash was an obvious choice for that platform. By buying Macromedia, Adobe gained control of Flash’s development, and hence of the platform they proposed to use for web-based applications. This enabled them to move development of the Flash player in directions that they needed.

Unfortunately for Adobe, while they were following this strategy the world moved in a different direction. Six years later, the present is not web-based applications, it’s small, cheap, sometimes throwaway, native applications that use the web as a data source and nothing more.

Adobe were not the only ones caught out by this – Apple themselves, when they launched the iPhone, thought most phone apps would be web apps. They were just more agile in moving with the times and switching emphasis to native apps.

Adobe are making their move now. In fact, they have been for the last couple of years, but it’s only now that killing bits of the Flash platform (specifically the mobile browser plug-in) has become part of that move.

What now?

So now Adobe find themselves with a profitable, but not massively so, set of products in the Flash platform that don’t fit neatly within their product portfolio. I wonder if Adobe now wish they hadn’t bought Macromedia, but that’s all in the past. They need to make the best of the current situation.

Killing Flash on the desktop would be madness, although I suspect maintaining Flash’s 98% desktop penetration is now less important, and it’s a decline in this figure that will be the first indication of Flash’s true decline. But, while there’s money to be made and a reasonable profit margin available, the Flash plug-in and the tools surrounding it will continue.

On top of that, the one thing the development world needs is a good cross-platform mobile app development platform. Unity3d provides a good tool for cross-platform game development, but the best cross-platform tools for general app development are mediocre at best. Adobe Air is currently one of those mediocre platforms, and with sufficient work it could become a good platform for mobile development. I hope it does. It has a lot of merit.

It sounds like Adobe may have identified this need and the potential of Air, so it’s just possible that Actionscript developers have a bright future ahead of them. Time will tell.

Meanwhile, if you’re an Actionscript developer it’s high time to diversify in whatever direction makes most sense to you. Javascript/Unity3d/Objective-C/Ruby… there’s lots of interesting stuff out there. Go and have fun. But you don’t have to abandon Flash and Actionscript just yet – Adobe haven’t.

1. It will start as something simple, with a strong foundation and the potential to grow.
2. It will have some very strong developers at its core.
3. It will have at least one project member with an ability to market effectively to the developer community.
4. It will be open source.
5. Its roadmap will develop through open discussion with the community.
6. It will have a very active developer community around it.
7. It’s probably a project that has already begun.

I can think of three excellent projects that meet most or all of these criteria. Whether any of them will one day replace the flex framework depends on many things, including in two cases whether the developers would even want to do such a thing. Here are the projects.

Reflex

The most obvious candidate is Reflex. It actually styles itself as a Flex replacement. It’s also not a first generation project, having evolved from Ben Stucki‘s experiences developing OpenFlux and Jacob & Tyler Wright’s experiences developing the Flight Framework. Reflex is designed as a straight improvement on the way Flex is designed. A key element in this is the use of containment rather than inheritance when creating the component architecture.

The result is aiming to be a simplified, lightweight, extendible component architecture with core features from Flex like MXML and CSS all in a tiny (~50kB) package.

The project is in its early stages but appears to be progressing well. The three core developers are all experienced and talented. Ben knows how to make a noise in the development community so they have that angle covered too.

Robotlegs

Like the original Spring for Java, Robotlegs (which is built on top of SwiftSuspenders) is a lightweight architecture built around a dependency injection container. Currently it complements the Flex framework, but if, like Spring, Robotlegs grew to cover more aspects of development it could perhaps be the foundation for a new approach to simplifying the development process. Put simply, maybe dependency injection could be the foundation for a component architecture.

Robotlegs was founded by Shaun Smith and it has skilled developers, an active and open community and, in Joel Hooks, at least one developer who has an aptitude for promoting the project to the wider world. Moving beyond an elegant micro-architecture into the world of Flex replacement therapy would be a big leap but I suspect the Robotlegs team would be up for it if they want the challenge.

Swiz

Swiz started life as a personal project for Chris Scott, but has evolved into a community project with a number of strong developers. It’s also changed at its core from a dependency injection based lightweight architecture to a metadata processing architecture, with a dependency injection container and event bus architecture built atop it. This puts Swiz in a position to build an architecture around metadata as well as Actionscript/MXML/CSS. Adding additional metadata processors to the Swiz toolset might open up new architectures to replace the traditional Flex model.

Swiz has had issues with documentation (it’s limited and updated intermittently) but the team are getting better at telling the community what’s going on and what their roadmap is, and they are quick to respond to questions which mitigates many of the documentation issues.

Only three?

There are other projects I could have mentioned but from those I know these three most closely match my criteria above. I also like and am excited by all three of these projects.

What would be your candidate for a project with a bright future and the potential to grow into a Flex replacement?

I’ve dipped my toe back in the Java world recently, and I’m reminded of some interesting Java history that may be echoed in Flash’s future.

Back in the distant mist of Java’s past, most large Java web projects were built using something called Enterprise JavaBeans. EJB was a complex framework developed by Sun, the developers of Java itself (with some input from IBM). EJB had a number of good things going for it, in particular

• It had respected advocates in Sun and IBM
• It addressed some real and difficult problems

but some developers also thought that the architecture and APIs were too complex.

Then a smart guy called Rod Johnson wrote a book about an idea, and he created a small framework called Spring to illustrate that idea, and the Java world started to change. Now, EJB is no longer the de-facto standard in the Java world. A smaller, lighter, more agile, more flexible framework called Spring has taken over. There are some who still use EJB (and EJB has become smaller and lighter in response to Spring’s success) but Spring is the framework in demand.

What has all this to do with Flash?

Replace Java with Flash, replace Sun with Adobe, and replace EJB with Flex and you might see a parallel in which Flash is ripe for a smaller, lighter, more agile, more flexible framework than Flex.

That shouldn’t be seen as a suggestion that Flex is rubbish – far from it. I use Flex every day and am often amazed at how good it is. Yet just as often I’m annoyed by its faults. Because Flex isn’t perfect, and its imperfections run very deep. All the new stuff in Flex 4 is great (most of it at least), but it keeps getting bigger, more unwieldy, more complicated.

So I suggest that, as with Java and EJB a few years ago, Flash is ready for a newer, lighter framework to evolve to replace Flex. I don’t know what that framework is but I suspect it will have most of the following attributes

1. It will start as something simple, with a strong foundation and the potential to grow.
2. It will have some very strong developers at its core.
3. It will have at least one project member with an ability to market effectively to the developer community.
4. It will be open source.
5. Its roadmap will develop through open discussion with the community.
6. It will have a very active developer community around it.
7. It’s probably a project that has already begun.

It may be one project, or it may be a merger of many. Maybe it’s that little project you’ve been working on in your spare time. Whatever it is, I suspect a couple of years from now we’ll have a serious alternative to rival the Flex framework.

There is also a follow-up post looking at some projects that might evolve to replace Flex.

The problem

How to show DHTML content (e.g. a pull-down menu) on top of flash content?

The cause

By default, browser plug-in or activeX content (from now on I’ll refer to plug-in content when meaning both) is displayed in its own window. It doesn’t look like it’s in it’s own window because the window in question has no borders, title bar or anything else we normally associate with a window, but from the computer’s point of view it is a window. Windows occupy rectangular areas of the screen and each window is displayed above or below other windows.

In the case of plug-in content, the plug-in renders its content in a borderless window that is displayed above the content of the browser window. So, by default, the flash content will always be displayed above all the html page content, regardless of the z-index setting in the css style for the content.

The simple reasons for this are speed and simplicity – the plug-in gets to display whatever it likes in it’s area of the screen without the need to merge this content with the html content displayed by the browser

The solution

Fortunately, flash has a setting to prevent the plug-in content being displayed in its own window. The object and embed tags have a parameter/attribute called the “wmode”. This parameter takes one of three values – “window”, “opaque” or “transparent”. The value controls how the plug-in displays the content with respect to the default behaviour described above. Most modern browsers support the wmode parameter (see Adobe’s list of supported browsers).

The “window” setting is the default and behaves as above, with the flash content rendered in its own borderless window above the page content. The other two settings, “opaque” and “transparent”, render the flash content within the browser window itself, with transparent showing the flash movie with a transparent background so elements behind it can be seen. Choosing either of these settings will enable you to display the DHTML content above the flash content. I’d recommend opaque unless you really need transparent, since transparent can cause some slowdown in the flash movie playback.

So, in brief, set wmode to opaque and then you can display the DHTML content above the flash using the z-index css property to control the layering.

There are a number of commercial and free obfuscating and encryption tools to help protect your code, three of which are ASO, SWFEncrypt and SecureSWF, so I’m not going to say any more about them (maybe in a later post). Here’s a few ideas for how to limit where the swf movie may be used.

What domain is the swf running in?

The swf can check to see what domain it’s running in and exit if the domain isn’t allowed. You can do this with a function like this

function isDomainAllowed( allowed:Array ):Boolean
{
    var lc:LocalConnection = new LocalConnection();
    var domain:String = lc.domain();

    for( var i:Number = 0; i < allowed.length; ++i )
    {
        if( domain == allowed[i] )
        {
            return true;
        }
    }
    for( var i:Number = 0; i < allowed.length; ++i )
    {
        if( domain.substr( - ( allowed[i].length + 1 ) ) )
                        == "." + allowed[i] )
        {
            return true;
        }
    }
    return false;
}

This function receives an array of allowed domains and checks the domain in which the movie is running against the array. If the swf is running in any of the domains or a subdomain of any of them then the function returns true, otherwise it returns false.

You use it like this

var domains:Array = new Array(
    "bigroom.co.uk",
    "example.com",
    "localhost"      // allow local testing
    );
if( isDomainAllowed( domains ) )
{
    gotoAndPlay( "content" ); // play the movie
}
else
{
    gotoAndPlay( "forbidden" ); // display some error message
                                // - more about this later
}

What flash player is the swf running in?

In the previous method, the localhost value in the array is to allow testing of the movie locally, in the Flash development environment or in a local web page. It also allows users to download the swf and run it locally or to load it into a projector. If you want to ban all local use of the swf then you can just remove the localhost value from the array of allowed domains. However, if you want to restrict the local use to some instances only (e.g. the Flash IDE only) you need to test what flash player the movie is running in. That works like this

function isPlayerAllowed( allowed:Array ):Boolean
{
    var player:String = System.capabilities.playerType;

    for( var i:Number = 0; i < allowed.length; ++i )
    {
        if( player == allowed[i] )
        {
            return true;
        }
    }
    return false;
}

The possible values of System.capabilities.playerType are

• ActiveX - the active-x control used in Internet Explorer
• PlugIn - the plug-in used in other web browsers
• StandAlone - the stand alone player and projectors
• External - the test movie mode in the Flash IDE

So the isPlayerAllowed function is used like this

var players:Array = new Array(
    "ActiveX",
    "PlugIn",
    "External"      // allow local testing
    );
if( isPlayerAllowed( domains ) )
{
    gotoAndPlay( "content" ); // play the movie
}
else
{
    gotoAndPlay( "forbidden" ); // display some error message
}

Load a file from the server

A third option is to try to load a file from your web server. If the load fails, abort the movie. Something like this

function testWithServer( callback:Function ):Void
{
    var receiver:LoadVars = new LoadVars();
    receiver.onLoad = callback;
    receiver.load( "http://example.com/testswf.txt" );
}

Which is used like this

function testResult( success:Boolean ):Void
{
    gotoAndPlay( "content" ); // play the movie
}
else
{
    gotoAndPlay( "forbidden" ); // display some error message
}

stop();
testWithServer( testResult );

This is quite basic - The file can be an empty text file - it needs no content. The function succeeds if the file can be loaded and thus is dependent only on the cross-domain policy for the domain hosting the test file that's loaded. If the policy allows the movie to load the file then it succeeds. The advantage to this is that we can update the allowed domains for our swf simply by modifying the cross-domain policy file on the server - there's no need to touch the flash movie. (More info on cross-domain policy files here)

It's important that the url is not a relative url - that would enable someone to bypass the security simply by placing an appropriate file on their own server.

There are many ways that this method can be enhanced, for example

• by sending the domain to the server and recieving a response that indicates whether the domain is allowed (and logging any disallowed domains)
• by generating a unique id each time the page containing the flash movie is loaded and passing it to the movie via the FlashVars. The swf then passes this back to the server when asking permission to run. The server allows each id to be used once only.
• by using encryption in the query and response (see ASCrypt for some actionscript encryption code).

But the basic system of an absolute URL and one or more (you can give each swf a unique policy file that it loads via the System.security.loadPolicyFile() method) cross-domain policy files is enough in many cases.

Conclusion

Each of these three ideas can be used individually or all together. Personally, I like the way that the first two are contained within the flash movie and require no special content on the server. Alternatively, the last method lets you update the allowed domains without editing the flash movie itself so each have their advantages. Note that if your source code can be decompiled then all these tests can be circumvented by simply removing the test altogether, so you may want to take another look at those encryptors and obfuscators.

What to do if playback isn't allowed?

If your test reveals that the movie shouldn't be allowed to play, then what should you do? There's two basic policies you could turn to

• Tell the user what's going on - display a message like "This movie/game/whatever can be viewed at http://example.com/funkyswf.html".
• Cause the player to crash - a simple while( true ); creates an infinite loop to achieve this.

I choose between these options based on specific circumstances. The second option gives a potential thief fewer clues as to what's going on, but you could use the first option to tell the thief where to legitimately obtain the swf (and how much it will cost).

I hope this is useful to you. What security techniques do you use?

I used to charge a small fee for them but they’re getting a bit long in the tooth now. Since updating them doesn’t fit with my current plans I’m making them available for free so please help yourself.

The components are not compiled so you can read and modify the code. They are written in Actionscript 1 and they work with Flash MX, Flash MX 2004 and Flash 8.

Download the components – includes the components, documentation and examples

I wanted the sudoku game in this site to be as simple as possible to use and to that end I implemented a context menu (accessed via right-click in Windows and control-click in Mac OS) that contained most of the command options, along with keyboard shortcuts for many of these commands. This supplements any buttons that may be available.

The Flash Player already has a context menu, but this can be modified to remove some of the default options and to add your own options.

To modify the context menu you have to create a new ContextMenu object and modify that. I chose to extend the context menu with my own class and use that to modify the menu as follows.

class SudokuMenu extends ContextMenu
{
    public function SudokuMenu()
    {
        super( onSelect );
        hideBuiltInItems();

        customItems.length = 0;
        customItems.push( new MenuPen() );
        customItems.push( new MenuHowDoing() );
        customItems.push( new MenuPause() );
        customItems.push( new MenuPrint() );
        customItems.push( new MenuRestart() );
        customItems.push( new MenuShowSolution() );
        customItems.push( new MenuSpinner() );
        customItems.push( new MenuTimer() );
        customItems.push( new MenuErrorCells() );
        customItems.push( new MenuAbout() );
    }

    public function onSelect( obj:Object, menu:ContextMenu ):Void
    {
        for( var i:String in customItems )
        {
            customItems[i].Prepare();
        }
    }
}

First we call the parent constructor passing it the method to call when the user right-clicks to display the menu. This method will be used to prepare the menu items for display.

hideBuiltInItems() is used to clear out the default menu items. You can’t clear them all but this will clear most of them leaving just the Settings and About Flash Player items.

I then clear any custom items by setting the length of the customItems array to zero.

The customItems array holds any custom items we want in our menu so the next few lines push all the custom items into this array.

Finally, the onSelect method is called when the user right clicks in the flash movie – just before the menu is displayed. This lets us customise the menu for viewing. So, in the onSelect we call the Prepare method of each menu item.

Every custom menu item extends Flash’s ContextMenuItem class. The pause menu item looks like this.

class MenuPause extends ContextMenuItem
{
    public function MenuPause()
    {
        super( "Options    esc", onSelect );
        Key.addListener( this );
    }

    public function onSelect():Void
    {
        _global.sudokuManager.TogglePause();
    }

    public function Prepare():Void
    {
        if( _global.sudokuManager.IsPaused() )
        {
            caption = "Resume    esc";
        }
        else
        {
            caption = "Options    esc";
        }
    }

    public function onKeyDown():Void
    {
        if( Key.getCode() == Key.ESCAPE )
        {
            onSelect();
        }
    }
}

All items in the context menu must be ContextMenuItem objects, so my MenuPause class extends this class to add additional functionality.

The constructor calls it’s parent object’s constructor with the default menu caption and the method which should be called when the menu item is selected. The caption contains the keyboard shortcut code separated from the caption by a tab – this pushes the keyboard shortcut to align right in the menu display.

Also, in the constructor I add this object as a listener to the keyboard so I can catch the keyboard shortcut.

The onSelect function is called when the menu item is selected so this contains the necessary code to pause or unpause the game.

The prepare method is called from the SudokuMenu object above just before displayingteh menu. The pause item checks whether the game is currently paused and sets its caption to Options or Resume accordingly.

Finally, the onKeyDown method checks whether the keyboard shortcut for this option was pressed and if so it calls the onSelect method to do the appropriate action for this menu item.

And that’s it. All the other menu items are implemented in a similar manner. The result is a more flexible interface that can be seen on the Strictly Sudoku site.

When I created the search providers for PHP and MySQL, I really wanted one for the Flash LiveDocs too, but the LiveDocs search is driven from JavaScript which makes it hard (impossible?) to do the search directly from a simple URL query.

The solution I’ve come up with is instead to use Google’s site search to search the LiveDocs. I’ve also added Google’s “I’m feeling lucky” feature to some of the scripts to jump straight to the first result from the search. This works well in most cases. Google’s coverage of the Flex 2 documentation seems weak but I’m hoping this will improve over time.

Just click the appropriate link below to add the search you want.

• Coldfusion MX 7 LiveDocs Search
• Coldfusion MX 7 LiveDocs search – jump directly to top result
• Flash 8 LiveDocs Search
• Flash 8 LiveDocs search – jump directly to top result
• Flash Media Server 2 LiveDocs Search
• Flash Media Server 2 LiveDocs search – jump directly to top result
• Flex 2 LiveDocs Search
• Flex 2 LiveDocs search – jump directly to top result

Flash movies can’t start in full-screen mode and can only switch to full-screen mode in response to a user action – either a button click or a key press. The facility to use full-screen mode is governed by a parameter in the object and embed tags. The parameter name is allowFullScreen and it defaults to false. Set it to true to enable full-screen mode -

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"
codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs
/flash/swflash.cab#version=9,0,18,0" width="550"
height="400">
   <param name="allowFullScreen" value="true" />
   <param name="movie" value="fullscreen.swf" />
   <embed src="fullscreen.swf" allowFullScreen="true"
      width="550" height="400"
      type="application/x-shockwave-flash"
      pluginspage="http://www.macromedia.com/go/getflashplayer" />
</object>

On its own, this isn’t enough to enter full-screen mode. You also need a little bit of Actionscript -

Stage.displayState = "fullScreen";

and to switch back from full-screen mode -

Stage.displayState = "normal";

As mentioned before, this code must be run in response to a key press or a button click for it to work.

Unfortunately, if you just type this in and compile your movie, you’ll get an error. that’s because Flash 8 knows nothing about the new displayState property on the Stage class. There’s two ways around this. The first is to add the appropriate code to the Stage intrinsic class, so open the Stage class file in your flash installation – for the English version this is at Flash 8/First Run/Classes/FP8/Stage.as – and add the following line of code after the other property declarations -

static var displayState:String;

The second, uglier but easier, option is to simply use the associative array syntax to access the new property, so use

Stage["displayState"] = "fullScreen";

and

Stage["displayState"] = "normal";

There’s more info, demos and AS3 instructions in the Adobe Labs Wiki. Have fun.