Interestingly this is a concept I began to scratched the surface of with my presentation at Flash On the Beach Last Year, and over the last few months has been a subject I have continued to keep close to hand both in my day job and my personal development projects. At the moment the Flash Player Fragmentation offers a considerable challenge to any developer wanting to design and or develop for multiple devices and multiple screens.

Articles like the one posted over at ADC on adaptive screen layouts offer a great foot up. But before we get to visual display we need to know what player version we are targeting. And to do that, we have to hit the time machine button and roll back all the way to Flash 4.....

The Following code should be exported as a Flash 4 ActionScript 1 .swf. This will ensure it can run on the broadest client base. The resultant .swf acts a cross platform redirect that should work within both stand alone and browser based flash clients. Once the .swf loads it will identify the player variation and then redirect the viewer to the appropriate content for there player platform by loading a replacement content swf at the main player level.

 
/**
Declare flash platform player strings here. As more devices are discovered this list will grow, the strings are from the getVersion() function
*/
// FlashLite 1.1 player platform string
FL1PLATFORM = "5.2";
// FlashLite 2 or 3 player platform string
FL2PLATFORM = "FL ";
// psp Flash Player Platform string
PSPPLATFORM = "NF3";
// Wii Player Platform String
WIIPLATFORM = "WII"
// windows Flash Player Platform string
WINPLATFORM = "WIN";
// mac Flash Player Platform string
MACPLATFORM = "MAC"
/**
Declare files names for flash files of different device configurations
NOTE! Include the full path name here
*/
flashLite1 = "fl_fl1.swf";
flashLite2 = "fl_fl2.swf";
flashLite3 = "fl_fl3.swf";
flash6PSP = "flash6PSP.swf";
flash7WII = "flash7WII.swf";
flashFull8 = "FullFlash8.swf";
flashFull9 = "FullFlash9.swf";
// get the player version
flashVersion = getVersion();
// display full player information
trace(flashVersion);
// test for existence of player version for very early players
if(flashVersion == "")
{
	/*
	Player does not support $version so is VERY early Flash PLayer
	Decide how you wish to handle this case here
	*/
}
// crop the player version to store the platform
playerPlatform = substring(flashVersion, 0, 3)
// Assign a player version for testing
// playerPlatform = PSPPLATFORM;
// display platform information
trace("playerPlatform");
trace(playerPlatform);
// use flashLite 1.1 file
if(playerPlatform eq FL1PLATFORM)
{
	// launch a FlashLite 1.1 version of the file.
	trace("Launch FlashLite 1.1 player version");
	loadMovie(flashLite1, "_level0"); //+"?stgWidth="+Stage.width+"&stgHeight="+Stage.height);
}
else
{
	if(playerPlatform eq PSPPLATFORM)
	{
		// launch a PSP or Flash 6 version of the file
		trace("Launch PSP player version");
		loadMovie(flash6PSP, "_level0"); //+"?stgWidth="+Stage.width+"&stgHeight="+Stage.height);
	}
	else if(playerPlatform eq WIIPLATFORM)
	{
		// launch a PSP or Flash 7 version of the file
		trace("Launch WII player version");
		loadMovie(flash7WII, "_level0"); //+"?stgWidth="+Stage.width+"&stgHeight="+Stage.height);
	}
	else if(playerPlatform eq FL2PLATFORM)
	{
		// grab the player version number for flash lite
		playerVersion = substring(flashVersion, 4, 1);
		// display version information
		trace("playerVersion");
		trace(playerVersion);
		if(playerVersion == "7")
		{
			// launch a FlashLite 2 version of the file.
			trace("Launch FlashLite 2 player version");
			loadMovie(flashLite2, "_level0"); //+"?stgWidth="+Stage.width+"&stgHeight="+Stage.height);
		}
		else if(playerVersion eq "8")
		{
			// launch a FlashLite version of the file.
			trace("Launch FlashLite 3 player version");
			loadMovie(flashLite3, "_level0"); //+"?stgWidth="+Stage.width+"&stgHeight="+Stage.height);
		}
	}
	else if((playerPlatform eq WINPLATFORM) || (playerPlatform eq MACPLATFORM))
	{
		// grab the player version number for desktop player
		playerVersion = substring(flashVersion, 5, 1);
		// display version information
		trace("playerVersion");
		trace(playerVersion);
		if(playerVersion == 8 )
		{
			// launch a desktop version 8 of the file.
			trace("Launch desktop player version");
			loadMovie(flashFull8, "_level0"); //+"?stgWidth="+Stage.width+"&stgHeight="+Stage.height);
		}
		else if (playerVersion == 9 )
		{
			// launch a desktop version 9 of the file.
			trace("Launch desktop player version");
			loadMovie(flashFull9, "_level0"); //+"?stgWidth="+Stage.width+"&stgHeight="+Stage.height);
		}
	}
}
stop();
 

The below zip includes the full source and example 'redirection' movies. If you have any other Client version strings that can be added please let me know and I will try and keep the script updated. For example I would love to know what the Sony Ericcson Java client version reports.

Identiying Flash Client Versions

The issue I have with the patent is its broad and sweeping coverage of very common interface and application GUI design systems. As an example reading one portion of the "Summary of The Invention".

When editing a component, the user may modify a number of features associated with a component including, but not limited to, the volume of an acoustic component, the link between a menu entry and an associated component, the font, font size, color, or effect of a text field, or the layout, size, transparency, rotation, color, position, or level of any graphical rich-media component. The user may modify these components by means of a slider bar or a textual input field. In addition, the user may modify the volume of a sound component by means of up and down volume buttons. The user may undo modifications made to a component's parameters. The user may also modify the position of a graphical rich-media component by a graphical input field, by clicking and dragging said component, or by text fields. When the user modifies the position of a graphical rich-media component by means of clicking and dragging said component, said component may align itself to a grid point or a guide line. The user may also modify the style and the Uniform Resource Locator (URL) of a component linked to a menu entry.

Unless I am mistaken the recently posted link to Netvibes would actually infringe on this part of the patent. In that the user can select 'panes' or 'graphical rich-media components' of the netvibes application and alter there position within the application by clicking and dragging them to a new position.

In this example, because there is no specific technology linked to the patent claim, any RIA in any technology, Flash, Ajax, Appolo, XUL Runner, HaXe, Sparkle, add any other future technology here..... These systems would all be in break of the patent claim.

And this is just ONE of the EIGHTY THREE different claims in this patent.

Very worrying I think any developer would agree. Everyone involved in Internet application development, in my opinion, should take a serious look at this patent. Think about ANY work they have done or seen in past. The work they are doing today. Then consider the possible implications of future networked development. If you know of anything that has been posted, exhibited or shown publicly that can bring this patent down, it is in every ones interest to make it known to strengthen the Magix reexamination.

And remember we are not just talking about flash applications or work here. If you remember or are aware of ANY online application, in any technology, be it DHTML, Director, Java or anything else. If it used any, all or even one of these systems to allow user interation then it may well be enough to show that Mr Neil Balthaser did not invent these systems, and certainly has not right to lay claim to doing so as he has in his patent application.

As you will have seen Mike Jones (FlashGen.com) and I are meeting to take notes, share war stories and generally reminisce the 'Good OldSkool Days'. To find out what files we still have, and even which URLs are still live (Flash 3 (alpha) circa 1997/8 btw JD produced by Spooky & the Bandit - you may remember them :p)

Keep your eyes peal for more news as events unfold....

First a little background to the site. The first version of the site was a journey into a completely code generated flash movie. That is to say, every possible aspect would be generated using ActionScript 2. The rational being to learn some more about the Draw API and also get clarify the ideas of OOP and MVC that i had heard so much about all over the web, but had yet to apply to flash properly. That first development has also offered a great focus for development in terms of learning Flash 8 and more recently both Flash 9 or Action Script 3 and now this latest version for the PSP version of the flash player.

So with the exception of the loaded Bitmap Images and the XML obviously, the rest of the production is all code. In addition this whole experiment has given me some great learning experiences in Eclipse, mtasc, and ant and the whole OpenSource Flash Development.

In my previous post on flash development for PSP I highlighted the need to be very careful with the amount of animation and data being thrown around in the flash player and the need to monitor specifically the memory usage. This is something I have been keeping in mind as I built up the code for the PSP version of my development here:

First I have the base BittubeClass that contains the mtasc main entry point and an application level control class. This handles loading XML, Images and also the creation of Interface Classes. Then I have the various interface elements split into four classes, Loader, NavBar, NavItem, and ContentArea.

Between these classes I am also using some of the mx core classes, or versions of them. These include.

mx.events.EventDispatcher;
mx.transitions.Tween;
mx.transitions.easing.Regular;
mx.xpath.XPathAPI; (modified to work in mtasc)
mx.utils.Delegate; (modified to work in mtasc)
MovieClipLoader (based on MovieClipLoader6)

The base output from mtasc of the project is a swf that is about 14k in size. Which I am pretty pleased with. I did wonder if generating all the visual assets being created via code was as efficient as using the flash IDE to create the assets. So with this question in mind I produced the following test code:

[as]//generate and display 4 sqaures
var drawSolidRectangle = function(mc_target:MovieClip, str_clipName:String, int_depth:Number, int_w:Number, int_h:Number, int_fillC:Number, int_lineC:Number, int_lineW:Number):MovieClip
{
var mc_retClip:MovieClip = mc_target.createEmptyMovieClip(str_clipName, int_depth);
if(int_lineW != undefined && int_lineC != undefined)mc_retClip.lineStyle(int_lineW, int_lineC);
mc_retClip.beginFill(int_fillC);
_drwRct(mc_retClip, 0, 0, int_w, int_h);

mc_retClip.endFill();

return mc_retClip;
}
var _drwRct = function(mc_clip:MovieClip, int_x1:Number, int_y1:Number, int_x2:Number, int_y2:Number):Void
{
mc_clip.moveTo (int_x1, int_y1);
mc_clip.lineTo (int_x2, int_y1);
mc_clip.lineTo (int_x2, int_y2);
mc_clip.lineTo (int_x1, int_y2);
mc_clip.lineTo (int_x1, int_y1);
}
drawSolidRectangle(_root, "square0_mc", 0, 100, 100, 0xff0000);
drawSolidRectangle(_root, "square1_mc", 1, 100, 100, 0xff0000);
drawSolidRectangle(_root, "square2_mc", 2, 100, 100, 0xff0000);
drawSolidRectangle(_root, "square3_mc", 3, 100, 100, 0xff0000);[/as]

This results in a file that is 972Bytes in size.

However by simply having a square symbol in the flash library, and placing it on the stage 4 times, and then providing the same instance names as are used in the code above, the swf output is a file of 183Bytes in size. So a smaller initial file in comparison to the code generated assets.

Both movies were exported as Flash 6, using ActionScript2. All other settings were identical.

Further on from this I monitored the memory usage of both movies in task manager. The code generated movie actually appeared to use slightly less memory than the IDE generated movie (6,964K as opposed to the IDE created movie which used 6,988K). So in this particular test Code generated assets actually made a lower impact in memory usage, something, I confess, suprised me.

Returning to the larger development I don�t know if the findings above scale into a more complex project, I would assume that as the code generation continues there would be a point where it will become more efficient to reuse existing IDE based assets than storing dynamically generated assets in memory. I have yet to find time to run an experiment in this way.

Through testing my existing file on the in the PSP flash player I discovered however that my movie still eventually toppled the memory barrier. The initial load of my movie is quite modest. The SWF is 14K compressed The 2 images I load are about 15K in total. The XML Document for the navigation is 285 bytes, the XML documents for the 3 areas are 81K in total. This all gives a total file space requirement of around 115K rounded up to the nearest 5K. This is well within the memory constraints of the 1.5Mb available on the PSP. Yet eventually after clicking through the movie a few times I see the "Out Of Memory" message.

I have checked the movie on the flash 8 player on my windows box. The initial Load of the movie reports 8,576K of memory usage, although as previously explained part of this is the actual stand alone player, not the movie it loads. Once I start navigating the movie, each interaction with the navigation adds between 4-12K to the memory usage. This seems to occur BEFORE anything else happens, i.e. it is a direct result any of the onPress, onRollover or onRollOut events being dispatched, and the generated clip that constitutes the NavItem that is being interacted with having its colour changed. In addition that memory never seems to be released?

Of course this is only the Windows Player, and of course it is a different version. But as I continue to work on this experiment I can safely say this form of memory leak is certainly not an isolated case. I have witnessed my 100K flash movie continue to consume many megabytes of memory once i began to load the XML data. Yet at no point does the memory get released. If there is anything close to this level of leakage within the PSP version of the player I fear that any serious development may well be impossible at the moment on this device.

My next development track will be to explore returning to more OldSkoolFlash development and construction methods, relying less on the dynamic scripting I tend to use today. Bring back, the invisible button, jump movie, and any number of other flash techniques either I developed or help others develop almost 10 years ago.

In addition to the technical limitations regarding the platform and the 'bulk' or the file size of any presentation that is deployed to it. It has become apparent that a good deal of thought should be held over to the 'flow', or the way users will navigate any work that you intend to deploy to the PSP flash player platform.

The more I investigated flash development for the PSP, the more it occurred to me that these are not new challenges. 'Back in the day' when working on Flash 3 development the equipment that I was deploying to was also rather less powerful than is available now.

Many flash developers will be aware of the dark days that Flash 3/4 heralded as developers neglected both the limitations end users had in both bandwidth and also the horsepower of the machines viewing the web back then. It was incredible how quickly and inappropriately (some) people (my self included) adopted the new Alpha tween capabilities, despite the fact that they would often cripple the target machines.

More recently we have seen the flash player ported to a myriad of other devices, from Set Top Boxes, to mobile phones and even fridges, many of which still suffer from these limitations on processor power that we take for granted when developing our nice new 'Web 2.0' all singing all dancing uber apps.

With all this in mind I have started to dig through the interweb to get my head round the development challenges that are held in this dark arena of mobile or multi modal flash development. If nothing else it would be a nice way of getting a tax break on a new fridge as a development tool .

What I have discovered in the limited testing I have put together developing flash for the PSP is fairly simple stuff.

Frame rates for the flash movie I am using as a base for my testing on the PSP vary hugely. The testing movie I have been working with is exported at 31fps. As part of my testing i have added an FPS component to show what�s roughly going on as the movie plays out. On a PC this reads on average 20-30 most of the times, with it dropping slightly as some of the elements fade in. However when this tween operation is played out on the PSP the fps plummet to around 2 fps. In the flash movie I am working on the tweens are code driven by the Adobe tween libraries; however after reading some documentation it may well be that a timeline based or even key framed tweens would be more effective when deploying flash to a PSP.

Text Display for the development Flash content on the PSP is wonderful. In order to keep the file size down I have chosen not to include any font embedding or font outlines. On a PC viewed through a monitor the text does suffer from the 'jaggies' that we have all come to know when using Non Aliased fonts. Readability is maintained by ensuring all text is positioned on non-decimal x & y positions, but it is still evident. The same Flash movie displayed on the PSP seems have some level of Anti-Aliasing applied. So not only do we get the benefit of the smaller file size by not embedding the fonts, but also thanks to the innate anti-aliasing, there is no jaggyness either.

XML Load times seem pretty reasonable so far. I am loading a specifically tailored XML document for my flash delivery to PSP.This is a smaller more concise structure than the XML I Load into the PC delivery. I am also still making use of the mx.xpath.XPathAPI class to handle all my XML data. Although I have slightly modified the core class to work with mtasc (commented out //var currAttr:String; within getPath()). There have been no issues with either the XML parse speed or with PSP compatibility.

I am sure there will be more to come on this as I continue, but for now here are a list of some of the sites I have found useful in my (limited) development of flash for the PSP

Marco Casario, Animation on Mobile devices best practice summary here

Adobe Dev Center Mobile Best Practice here

PSP Specific Development Info here

Web Design for PSP here

My Flash development for PSP (slow) progress here

So far I have only produced a single movie suitable, or rather, targeted for the PSP version of the flash player. It has been developed using ActionScript 2 and mtasc to compile the swf. Where possible I have tried to use the Macromedia Class Framework, although in some cases this hasn’t been possible due to issues compiling in mtasc. The two most obvious class issues I have come across have been the with the MovieClipLoader class, and the Delegate class. MovieClipLoader seems not to compile to flash 6/mx compatible swf's and Delegate was causing mtasc to throw errors. As a result of this I have substituted the MovieClipLoader with the open source MovieCLipLoader6 class from osflash and Delegate has been replace with Delegate from Steve Webster.

In addition I have found the Macromedia Tween classes cause mtasc to throw warnings due to the use of #include statements. But this does not seem to affect compilation.

The PSP display is in a wide screen format, which is of course is a different width height ratio to most standard monitors. With this in mind some consideration needs to be giving to the layout onscreen. Movies should be compatible with the PSP's screen resolution pf 480 pixels by 272 pixels. In my development I opted to produce a movie that would dynamically resize based on the size of the Stage.width and Stage.height properties. This allows me to produce content to both the PSP flash player, standard monitor resolutions and also as an added bonus the movie should make best use of the growing number of wide screen format monitors available.

The PSP only has limited browser caching, from what I can gather the browser cannot have more than 2048 kB (This page has reference to that figure) of data held with in the 3 'tabs' although JD suggests on his page that it is less than that.

There's about 1.5 megabytes of RAM available for viewing content on this device

Whatever the actual figure is, it’s nowhere near the amount of memory that we have become use to in modern computing. With these memory considerations in mind I wanted to provide 'smaller' content for the 'PSP Flash' than the 'non PSP flash' presentation. As mentioned in my earlier post this would be done using the System.capabilities.version property of the player.

The PSP flash player returns the following version information;

Player version = NF3 6,0,72,27

Based on this information not only have I been able to load a lower quality and smaller image if a user is using a flash enabled PSP but also the movie only loads a single image rather than 2 separate images (the image is in fact the same image loaded twice, but the principle still holds).

Another important factor is the size of the flash movie 'in memory' on the PSP flash player. After compiling my action script classes into an swf with mtasc I was left with a SWF that was reported as 4.96k in size. However this movie is compressed, now I believe this does not truly represent the actual size of the movie in the PSP browser memory. In order to find this out you should check the size of the file uncompressed. In the flash IDE this is simply a matter of un-checking the 'compress movie' box in the publishing settings. I couldn't find a way to do a similar operation with mtasc, so instead made use of flasm using the -x option to decompress the SWF. The result was a movie that was closer to 13k in size.

This gave me a guide to the actual size of the movie, but it still doesn’t really represent the 'running cost' of the movie. Obviously as the movie runs, movie clips, variables and new objects will be created and loaded. These will all add to the overall memory 'cost' of the flash movie in memory.

To get an idea of this 'memory cost over time' I simply opened the movie in the flash player on my PC, opened task manager and looked at the memory usage for the flash player (on a windows machine the stand alone flash player is listed as 'SAFlashPlayer.exe').

Task manager reported memory usage of 13,672k. However i figured some of that was the actual running cost of the player application, not just my movie. Running just the Flash 8 player with no content Task manager reported 7,004k so my movie once loaded appears to take about 6k of memory in running cost (13 – 7). I would assume once on the PSP this running cost is in addition to the swf file size, the file sizes of the loaded image, and also the loaded XML document.

Now at this point I should point out these memory calculations are all hypothetical. It would be nice to get some formal documentation for development on the new PSP Flash player, and also information regarding the management of memory or profiling of memory cost of a given swf.

As I go forward with this project the main assumption I intend to make is that with the PSP flash player being based on flash player 6 the memory management and garbage collection will be as poor as that player, and unlikely to be up to the level of the new flash player 8. As a result I will need to do that garbage collection manually to ensure users don’t see the 'Out of memory' message. In addition all content will have a 'Lite' version specifically for the PSP flash player, for the same reason.

Usefull PSP Flash Development Links

PSP Flash Player info
JD's Viewing Flash on PSP
PSP browser usage information

Tools Used in this development

Flasm - http://flasm.sourceforge.net/
mtasc - www.mtasc.org/

To test flash locally on your PSP

1. Create a folder on the root of yout MemoryStick.
2. Put your development files into the new folder.
3. Open the browser on your PSP
4. Hit Triangle and navigate to the address entry and enter URL like the following
   file:/YourFolderName/YourDevFile.swf
   file:/YourFolderName/YourDevFile.html

('file:/' can be found on the http:// button at the bottom of the list)

**In local testing I have experienced unexpected results in my loading class although this may be an isolated event in my development.

Over the weekend while researching some bits and pieces I put together a quick Flash File that tests the player on the PSP and also displays the values provided by the System.capabilities.playerType and System.capabilities.version properties.

For reference and so you don�t have to go and find the flash file. The Values are as follow:

player type =
player version = NF3 6,0,72,27

I assume the player type is undefined. Given that this property is a only available in Flash Player 7, but I thought it worth checking for completeness.

Some useless information about this movie its the first time for me producing an entire flash movie without the aid of the flash IDE. That�s right the whole dawg gone flash 6 file was produced in a text editor and compiled using MTASC, drop shadows and all....