Tag Archives: ActionScript 2

Memory Management in Flash Lite and ActionScript 2 using ASUnit

In my new position the team I have joined and me are carying out some in depth testing of an Action Script 2 code base for Flash Lite 3 using, among other things, ASUnit based unit and acceptance tests. The early stage of development means it is too soon to leverage the new automated testing features of Adobe Device Central CS4. One of the most important aspects of our testing has been to check memory use over the lifetime of the applications we are developing. We are interested in tracking any memory leaks in our code and also any memory space fragmentation as the Flash Lite player creates or destroys objects and classes.

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.

MemoryPanel.png

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.

Forum Nokia launches Flash Lite Developer’s Library

I missed this yesterday. Nokia have released the Flash Lite Flash Lite Developer’s Library 1.1 . One of the important aspects of this launch is the inclusion of documentation for using the new Nokia S60 Platform Services.

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.

Free Flash Lite Components Bonanza!

I you are a Flash developer producing mobile content for Flash Lite then this week end you really hit pay dirt. First Nokia announced a set of Components for Flash Lite 2. Next Adobe also release a set of Components, for use with Flash Lite 1 and also Flash Lite 2, courtesy of Mark Doherty. Finally Scott Janousek resurrected the google code links for Shuriken, a set of open source Flash Lite2 components from last year.

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

  • Scott mentioned, the Shuriken Components. I stumbled upon these components some time ago, I am not sure if the project is still live or has fallen dormant. The project offers a fairly comprehensive attempt at providing a full component framework to Flash Lite 2 developers. Included in the distribution zip are source class files, and example .fla’s for each component in the library.
    • Button
    • Calendar
    • CheckBox
    • ComboBox
    • DateEditor
    • LinkButton
    • List
    • Loader
    • NumericStepper
    • RadioButton
    • RadioButtonGroup
    • ScrollableList
    • SimpleButton
    • TextArea

    While the examples are good they do seem to be quite heavy in terms of memory usage, and they are not without issues. The scrolling list example for instance takes around 700k to display, but more concerning is that this memory usage raises during operation, implying the component has a memory leak somewhere. The complexity of this initiative while making development easier, may be its problem. Complex class structures in Flash Lite tend to give rise to cross references and memory leaks quite quickly.

    Download the Shuriken Open Source Flash Lite 2 Components

    So there we have it 3 sets of components, all certainly have there advantages and disadvantages. The Nokia Flash Lite components are great for Plug and Play development, I would say the Adobe UI examples are great for producing engaging canned demos as they stand, but with a bit of work could be converted for very memory efficient project use, and the shuriken component frame work may be a little heavy at the moment, but keep a watch on them, they could certainly offer a great, familiar framework for Flash Lite development, when they can solve the memory issues.

    Also worth a note is that Mark Doherty has put a shout out at the end of his post regarding a shelved component framework that he could release from Adobe if interest is great enough. Mark has asked the FlashLite comunity to provide some support if it were released, to document and update the project, but this could offer a great opertunity to unify the current state of disperate component solutions emerging.

    Credit where its due: