blog.rive.be

This memory information is viewable from Adobe Device Central in the Memory Panel, where device central provides a graph showing memory usage over time, separating Static Heap and Dynamic Heap consumption of the player as your Flash Lite application runs.

Testing for memory use, loss and leaks is currently not present as standard in ASUnit for ActionScript 2. In order to include this form of testing at a basic level we have employed a trick I picked up at Max San Francisco this year (If you are the person that explained the trick, please leave a comment so I can credit you). The technique makes use of the FlashLite SharedObject as a way of measuring the file size of objects and classes before and after you think you have destroyed them in your code.

The premiss is a simple one. In your test as part of the test setup create a local SharedObject create an empty data property and save the SharedObject to disk, then call the SharedObject.getSize() method and store the size of your empty SharedObject. The code should look something like this.

// size variation threshold for the SharedObject
private static var SIZEVARIANCE:Number = 5;
private var iS:SharedObject;
private var iSSize:Number;
// standard ASUnit test setup
private function setUp():Void
{
instance = new TestableClassObject();
iS = SharedObject.getLocal("iS");
iS.clear();
iS.data.iS = undefined;
iS.flush();
iSSize = iS.getSize();
}

Some things to keep in mind are the following. The length of the SharedObject name and the length of the data property name will have an impact on the result of SharedObject.getSize(). In the above example I have limited both these values to 2 characters ('iS'). All that remains is to link the value obtained from this setup function into a standard ASUnit test which looks something like this:

public function testDestroy():Void
{
instance.destroy();
iS.data.iS = instance;
assertTrue("testDestroy : test that the TestableClassObject 'instance' is destroyed successfully by checking size variation (" + SIZEVARIANCE + ") in SharedObject", ((iS.getSize() - iSSize) < SIZEVARIANCE));
}

In this test I am simply calling the target class instance's destroy method, which should manage the removal of any stored references, arrays and object present in the class. I then save the locally stored instance back to the existing shared object, re-call SharedObject.getSize() and compare the size difference to the value of our initial empty SharedObject (iSSize) from the test setup method.

If the file size of the SharedObject is greater than the SIZEVARIANCE threshold then the test will fail. If that is the case then you have the ability to inspect the shared object using a SharedObject viewer (I use the free Solve by Darron Schall). In the viewer you will be able to see what items are not being properly removed from your class instance oronject. A common issue I have seen is the failure to destroy arrays that are prpperties of my classes for example. Some time over the holiday break I will put together a full example for download.

The Platform Services enable flash application to access Device Capabilities and services that were previously only possible through third party solutions Such as Kuneri lite.

Here is a list taken from the Using Platform Services section of the new Flash Lite Developers Library.

The S60 platform allows Flash Lite applications installed on S60 mobile devices to:

• Access and launch applications on a device using the AppManager Service API
• Access and manage calendar information using the Calendar Service API
• Access and manage information about contacts using the Contacts Service API
• Access and manage information about landmarks using the Landmarks Service API
• Access device logging events using the Logging Service API
• Access device location information and perform location-based calculations using the Location Service API
• Access information about media files stored on a device using the Media Management Service API
• Send, retrieve, and manage messages such as SMS and MMS using the Messaging Service API
• Access data from the physical sensors of a device using the Sensor Service API
• Access and modify system information on a device using the SystemInfo Service API

These new API's are supported through FlashLite 3.x on Series 60 5th edition devices. Flash Lite applications use the S60 Platform Services through Service APIs. The Service APIs are supported through a Nokia-proprietary ActionScript 2.0 library. Before you can create Flash Lite applications that use platform services, you must install the library for use in your Flash Lite applications.

Here is a run down of updates from the Change History section of the Flash Lite Developers Library.

Change history Flash Lite Developer's Library 1.1

• Added information on the S60 Platform Services, the corresponding ActionScript Service APIs, and the ActionScript Service object required to access the APIs.
• Added section "Flash Lite API reference". This section describes the ActionScript APIs provided by the S60 platform for use with Flash Lite applications.
• Added section "Flash Lite authoring and optimization tips". This section provides tips and guidelines for authoring Flash Lite applications and optimizing their performance.
• Added section "Flash Lite with S60 touch". This section briefly introduces the touch UI and Flash Lite touch keypad of S60 5th Edition devices and provides instructions for disabling the touch keypad.
• Added section "Flash Lite example applications". This section contains links to example Flash Lite applications that you can download to your computer and then to a mobile device or emulator.

Check out the Flash Lite Developer’s Library Here.

Mobile Summit
November 16, 2008 at the Marriott from 1pm-6pm
Join Adobe and our partners — Nokia, Qualcomm®, Verizon, Sony Ericsson, GetJar, Thumbplay®, and Zed — to learn about new opportunities for mobile developers this year. Get a sneak peak at what you will see and hear at MAX before anyone else does! Hear from Adobe partners and key industry players as they present the newest mobile solutions, technologies, and distribution opportunities for mobile developers. To learn more and RSVP for this event go to: http://www.eventsadobe.com/mobilesummitmax08/invite.html

Mobile Fast Pitch Networking Party
November 19, 2008 at the Thirsty Bear from 6:16pm-9:30pm
Adobe is hosting a special Mobile Networking Party to allow developers to showcase their mobile applications using our Adobe® Flash® mobile technologies. If you already have a web-based application and are thinking of going mobile, you can also present your idea and get feedback from our industry leaders. Join us to support fellow developers or to present your ideas. For more RSVP and presentation information for this event go to: http://www.eventsadobe.com/mobilenetworkingparty/invite.html

In addition to these 2 events there are also a number of great sessions on at the conference tailored to Mobile:

• Open Screen Project: Delivering Rich Internet Experiences Across Devices
• Creating Mobile Applications: A Real-World Example
• Mobile Workflows with Creative Suite® 4 and Adobe Device Central CS4
• Flash Lite 3: Learn How to Package and Distribute Mobile Content
• Spotlight on Finetune and Teknision™: Building a Multiscreen Application
• Create Unique Browsing Experiences on Nokia Phones
• How to Build a Mobile Business
• Developing the Ultimate Flash Cast™ Channels
• Project Capuchin – Bridging Adobe Flash Lite and Java ME™

Remember the most popular MAX sessions fill very early, so be sure to register today to secure seats in your preferred sessions. You’ll be surprised by what real live Adobe Flash Lite applications exist today.

Headline Numbers for this update:

261 profiles included
57 new devices
updates to 204 existing profiles
In total that makes 525 device profiles for you to create content with

Download Adobe Device Central Update 7 from here.

So with all these 'new' flash lite components available what can you expect from each component set?

Nokia Flash Lite 2 Components
Nokia have provided their Flash Lite 2 Component set as an MXP file for simple installation into Flash CS3, the components are easily accessible from the components panel once the MXP has been installed. Included in the zip file you download is a full readme.txt explaining how to install the MXP file through Adobe Extension Manager. The components also include full usage instructions in the form of flash help files and usage examples. Flash Lite Components that are included in the distribution are:

• Signal Level display, including network generation.
• Battery level display.
• Dynamic List Component.

The Signal and Battery indicator components react to softkey placement/screen orientation. All three of the components have easily accessible skin components in the library, and also allow limited visual control from the properties panel. Mark Doherty noted that the components appear to be quite memory hungry. The Signal and Battery Indicators seem to use in the region of 600k according to Adobe Device Central, the Dynamic List Example reports around 800k although the actual memory usage of the list without a demo data set is closer to 700k.

Download the Nokia Flash Lite 2 Components

Adobe Flash Lite 1 & 2 Components and UI Examples
Over at flashmobileblog Mark Doherty has released some UI components as well. These are provided for both Flash Lite 1 and Flash Lite 2 projects. There is limited documentations for the examples, the Flash Lite 2 examples look like they should be easy to integrate as long as you intend to use them 'as is' in this case they would simply require the addition of key listeners to control them. If you needed the components to be used in a more dynamic fashion, there would probably be some work to do. Included in the Flash Lite 2 component examples are:

• List, this offers similar functionality to the Dynamic list in the Nokia Component set.
• Slider, This offers a horizontally scrolling icon menu.
• Gapper, This is a vertical variation of the slider.
• TileGrid, Shows a gridded icon menu with scrolling screen control.
• NavModel, this demonstrates a full application screen control system, also included are working Signal and Battery indicators and a list components.

The examples in this file are certainly easy on the memory, all of them use less than 500k, this is particularly impressive of the Nav Model example given the amount of interactivity and feedback that is demonstrated.

As with any Flash Lite 1 work, making use of the earlier versions will be a little more fiddly than the Flash Lite 2 counter parts. But the code in each of the examples is clearly identified and if you know your way around ActionScript 1 you should find incorporating the 'components' easy enough. Included in the examples are the following Flash Lite 1.1 components.

• Carousel, A full screen horizontal slider.
• Displays, demonstrates the various device stats you can access from Flash Lite 1, also included are battery and signal indicators.
• IconMenu, offers a FlashLite 1 version of the Slider component in the Flash Lite 2 set, this is similar to the functionality produced in the tutorial here.
• Menu, actually seems to be a Flash Lite 2 example, an alternative dynamic list example.
• Story, This is an example of scrolling text in flash Lite 1, similar to the scrolling text component I have released.

Agin the Flash Lite 11 components are very efficient when it comes to memory usage. None used more than 400k when published, and most were below 300k. The trade of with both these example sets from Adobe seem to be the slight increase in the amount of work you would need to do to integrate them. The other thing to note, is that these examples do offer examples of far more compelling UI methods than simple lists.

Download the Adobe Flash Lite 1 & 2 Components and UI Examples

Shuriken Open Source Flash Lite 2 Components
The last set of Flash Lite components are those that

Its a little hard to make complete sense of the post from EETimes.com. But some interesting quotes from the short, slightly cryptic article:

By using our new IP, one can design a portable device capable of processing Adobe Flash Lite several times faster, when compared with using a processor.

Also in the announcement is a hint of better video quality as well.

After reducing the number of gates required for an IC and further tuning the video quality output by Adobe Flash Lite, NEC will start offering its IP in August this year.

One thing that does seem to be missing is an explanation of which Flash Lite version they are supporting, although the mention of video implies this is based around the FlashLite 3 player.

You can read the full (breif) announcement of NEC's new Flash Lite IP over at EETimes.com.

One further interesting thing is that I could find no mention of NEC being involved with the Open Screen Project from its press release.

Credit where its due: EETimes.com

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

Well, you really believe that Flash is synonymous with the internet and frankly, anybody who wants to browse the web and experience the web's glory really needs Flash support. We were very excited about the announcement from Windows Mobile, adoption of Flash on their devices and the fact that we've shipped 0.5 billion devices now, non-PC devices. So we are also committed to bringing the Flash experience to the iPhone and we will work with Apple. We've evaluated the SDK, we can now start to develop the Flash player ourselves and we think it benefits our joint customers. So we want to work with Apple to bring that capability to the device.

If the mountain wont move to you..

Go Adobe!

Read the full ZDnet article here
Read the SeekingAlpha transcript here

Read the Full Press Release here

Stepping back into FlashLite 1.1 (flash 4/5) scripting has been a nostalgic experience. The halcyon days of ActionScript 0/1 were where I broke my teeth, so to speak, on flash. It has been an eye opener also to return to using Perl as well in order to format data efficiently for consumption in my simple FlashLite 1.1 applications.

In these days of XML, SOAP, SQL, and huge component frameworks, it has been nice to go back the the "demo days" of flash and try and eak every byte out of my data format. Remember of course, no XML or SWX support in FlashLite 1.1.

So what have i been playing with? How about a Live London Tube Status FlashLite 1.1 application?

The Data format?

lnID0=0&lnID1=0&lnID2=0&lnID3=0&lnID4=6&
lnID5=0&lnID6=0&lnID7=1&lnID8=0&lnID9=0&
lnID10=0&lnID11=0&itemLoaded=true


The lack of native structured data in FlashLite 1.1 means you have to think differently about what you are conveying, where best to store it, and how to access it. The example format above allows me to form references between pseudo-arrays in the FlashLite file that store much bulkier text labels, those strings can then be used multiple times in the application.

First I have a pseudo-array with my representation of the London Tube Lines.

lineNames0 = "Bkrloo";
lineNames1 = "Cntrl";
lineNames2 = "Crcle";
lineNames3 = "Dstrct";
lineNames4 = "Est Lndn";
lineNames5 = "Hmrsmth & Cty";
lineNames6 = "Jblee";
lineNames7 = "Mtropltn";
lineNames8 = "Nrthrn";
lineNames9 = "Pcdilly";
lineNames10 = "Vctria";
lineNames11 = "Wtrloo & Cty";


Also I store my interpretation of the common tube status' in a similar pseudo-array.

lineStatus0 = "Normal Service";
lineStatus1 = "Short Delays";
lineStatus2 = "Long Delays";
lineStatus3 = "Suspended";
lineStatus4 = "Part Suspended";
lineStatus5 = "Part Closed";
lineStatus6 = "Planned Closure";


Then once the data has loaded, note the last name value pair (itemLoaded=true) it allows my load script to spot when all the data is in the application. I perform a little loop operation to link my labels to line id's and then use the value of the loaded variable to set the frame of a "status" movie clip.


itemTotal = 0;
i = 0;
/*
loop through the loaded data, we know that there are not more than 11 Tube lines in London, at the moment.
*/
while(i < 12)
{
serviceLine = "/serviceBoard/serviceLine";
lnStatus = eval("/channelData_mc/:lnID" add i);
lnLabel = serviceLine add i add "/:_serviceItemLabel";
stLabel = serviceLine add i add "/:_serviceStatusLabel";
lnItem = serviceLine add i add "/serviceItemLine";
stItem = serviceLine add i add "/serviceItemStatus";
set((lnItem add "/:lnNum"), i+1);
set((stItem add "/:lnNum"), (lnStatus+1));
eval(serviceLine add i add "/:_serviceItemLabel") = eval("/channelData_mc/:lineNames" add i);
eval(serviceLine add i add "/:_serviceStatusLabel") = eval("/channelData_mc/:lineStatus" add lnStatus);
tellTarget(lnItem)
{
gotoAndStop(lnNum);
}
tellTarget(stItem)
{
gotoAndStop(lnNum);
}
++i;
}


The Result?

Download the Live London Tube Status FlashLite 1.1 Application for Mobile Devices.

1. Already using the mx.events.EventDispatcher class in your FlashLite application
2. Planning on or maybe already are, using my com.bittube.core.BatteryBroadcaster class in your FlashLite application. (incidentally if you are I am honored, and would also like to know )

You can download the NetworkBroadcaster classes from the link below.

Download the NetworkBroadcaster.zip

It is also posted in the Downloads area if you loose this post.

see the Flash Version Comparison Chart

Some Points of interest for me were the following:

• The FlashLite 3 player is actually smaller than the FlashLite 2.1 player
• The minimum memory requirements for the FlashLite 3 player is un-altered
• The recommended memory is un-altered for for the FlashLite 3 Player
• There is no improvement in the worst case memory usage of FlashLite 3 content over FlashLite 2.1
• Added support for meta data in FlashLite 3 Content

Also I see that the FlashLite 3 player has "External API for browser scripting", assuming there is a mechanism to update the players within device web browsers this may well offer a clean interface for the detection of screen orientation I have been experimenting with lately.

Another interesting point FlashLite 2.1 and FlashLite 3 seem to both offer support for "Complex languages (Thai, Arabic, Hebrew, etc.)". Yet this is still not supported by the desktop player? Yet.

FlashLite 3.0 Update for Device Central

Flash Lite 3.0 Update for Flash CS3

Interestingly the download for Flash CS3 is rather cryptically called "RobRoy_9_0_0_d156_patch.dmg"? or "RobRoy_9_0_0_d156_patch.exe" for windows?

Also mentioned in the release is the news the new "community for creative professional" from Nokia. This looks like it could offer a great resource for developers looking to deploy to mobile handsets, and devices.

The Full Press Release can be Found on the Adobe press release site.

Adobe Announces FlashLite 3

The full press release from Nokia covering their support for FlashLite 3 can be found on the Nokia Press Release Site:

Nokia Announce Support for FlashLite 3

Creating and Selling Your Mobile Flash Content

I also noticed Bill has a document linked at the very top of his site, under the banner "Addressable devices for developers".

In the file I am simply reporting to screen the Player version, the stage width and height, and then also loadin an image thumbnail from my new gallery of animal themed photography

The bottom 2 fields are reporting the FlashLite players fscommand2("GetFreePlayerMemory") and fscommand2("GetTotalPlayerMemory")

In the first screen the FlashLite movie from this URL loads has loaded in the Vertical page format at a resolution of 240x320 (wxh).

In the second screen shot below the browser has been rotated into its horizontal format. This operation does not seem to cause the Stage.onResize event to fire, and the flash movie still reports a resolution of 240x320 (wxh).

A side effect of this rotation of the flash movie is that it seems to get scaled down in order to view it in the new format. This means the text becomes unreadable. Very frustrating.

The N95 does support JavaScript in its browser, next step i suppose is to see if that can be used to detect the change in format.

So I have spent a little time getting to the usual nitty gritty that us flash developers require in order to produce to the Nokia N95. I.E.

The FlashLite Player on the N95 reports the following from the System.capabilities.version command.

FL 7,1,90,0

When using html that sets the swf files width and height to 100% I get the following information from the N95 browser.

Stage.width == 240
Stage.height == 320

Here comes the but......

When I make use of the rotate screen functionality that the N95 offers to view the SWF in landscape format, and measure the width and height. I get the following.

Stage.width == 240
Stage.height == 320

I extended my movie to make use of the Stage.onResize event. But at no point could I see that event fire through my event handler. As a result I have not been able to see the expected result in landscape format of

Stage.width == 320
Stage.height == 240

Maybe I have made a simple mistake.

The N95 does seem to be a very capable device. The battery is pretty short lived, but the functionality it offers is great. From a development point of view I will be looking to see what I can do in the Browser and out, It would be wonderful if the Browser offers FlashLite 3 once that is available, maybe a later firmware patch. We shall see.

my first example is (very basic) available to view at this location. bittube.com/flashlitehome/index.html

I will package the source, what there is and post it later on.

Aral himself voiced his concern over the loss of 'go at it' attitude within flash development as it has evolved. In part due to the 'rule of the rod' attitude of insisting on Frameworks, Patterns, and Object Oriented development practices. It was truly refreshing to see a developer express sheer glee at returning to a hex editor to decipher the .SWF format with one single goal in mind.

Reading some of the responses to this project has also bought a smile to my face. This time not for particularly good reasons. Its plain to see there seems to be some issue with the 'raw' approach that Aral has taken to accomplish his goal. Some quotes that stick out for me revolve around the 'Hacky' nature of the solution Aral has produced. The use of onEnterFrame as a polling device, or the use of loadMovie as a transfer system. But why should this be a problem? Aren't they there to be used?

The current ActionScript 2 standard is where it is now as a result of just such work arounds and hacks. Thank you very much. Dig deep enough into some of the ActionScript 2 classes and you will find not only hacks like this, but in some cases, what you might consider worse ones. In mx.Transitions package for example we find the OnEnterFrameBeacon a class that not only makes use of onEnterFrame, but also a MovieClip that is created to a 'Magic Number' based depth? There are I am sure any number of other examples.

Flash is where it is today to any number of early flash developers working with very limited action script and coming up with work arounds and hacks to get it to accomplish the myriads of solutions we are now fortunate enough to be able to develop now. Remember 'jump movies' or __proto__ or storing sine tables to do 3d? Before PaperVision. No amount of Java development sensibility is going to change that to quickly.

Even with all this wonderful ActionScript 2 Object Oriented (?) loveliness, developers every day are finding they have to go back to the oldskool to get there applications to work. Flash hacks still have a huge level of relevance today, for the simple reason people are still finding things they want to do in flash that they cant do any other way. Flash Lite, Accessibility and Localization are some pretty good starters that still require copious amounts of hacking at times.

A crossed reference occurs in situations such as this.

[as]
var myFirstObject:Object = new Object();
var mySecondObject:Object = new Object();

myFirstObject.reference = mySecondObject;
mySecondObject.reference = myFirstObject;

myFirstObject = null;
mySecondObject = null;

delete myFirstObject;
delete mySecondObject;
[/as]

In each case the objects above have a property that references an object, and the reference is cyclical in nature. As far as the Garbage Collection routine in the player is concerned each object will always have a usage count of 1 regardless of the delete statements as a result of the reference in the other object. The result is that neither object will be cleared from memory, hence the leak. If such a situation were to arise in a looping operation the loss of memory is compounded.

[as]
var i:Number = 0;
var iTotal:Number = 5;

whie(i < iTotal)
{
var myFirstObject:Object = new Object();
var mySecondObject:Object = new Object();

myFirstObject.reference = mySecondObject;
mySecondObject.reference = myFirstObject;

myFirstObject = null;
mySecondObject = null;

delete myFirstObject;
delete mySecondObject;
++i;
}
[/as]

Now the above example is a very simplistic example, and is very plain to avoid. With more complex applications however, these situations can arise over many classes and may not be any where near as blatant. This little flash extension offers a great interface for highlighting those crossed references in small applications vital for Flash Lite developers to find and remove.

object-explorer

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