I recently published a series of tutorials around the topic of “moving stuff” across Adobe Air applications (via copy&paste and drag&drop). Here is the complete list of all the tutorials.

• Native Drag and Drop in Adobe Air
  The first tutorial, to get started with drag and drop.
• Drag and Drop of Text in Adobe Air
  An overview of how to drag and drop textual content in Adobe Air.
• Drag and Drop of Images In Adobe Air
  A tutorial on drag and drop from OS to Adobe air and across Air apps.
• Copy and Paste Images in Adobe Air
  The first tutorial on copy and paste, focused on images.
• Copy and Paste a complex object in Adobe Air
  Description of how to move a custom object across Adobe Air applications.
• Copy and Paste Sets of Complex Objects in Adobe Air
  A tutorial about how to copy and paste arrays of custom objects.

I am planning to release more series about Adobe Air/Flex. Any topic your prefer? Leave a comment below or contact me.

This is a followup post to the previous one, where we have seen how to copy and paste a complex object across two Adobe Air applications. We will see how to copy and paste more than one object from an Adobe Air application to another. First of all we have to enable multiple selection in our Datagrid, that’s easy.

1
2
3

<mx:DataGrid id="grid" 
	dataProvider="{collection}"
	allowMultipleSelection="true" >

We then modify the function that copies data to the clipboard. Instead of a single element we want the list of the selected items in the datagrid (line 3).

1
2
3
4
5
6
7
8

private function copyToClipboard():void {
 
	var selection:ArrayCollection = new ArrayCollection(grid.selectedItems);
	Clipboard.generalClipboard.clear();
	Clipboard.generalClipboard.setData("myCustomFormat", selection);
	feedback.text = "Data copied to the clipboard";
 
}

The rest of the code remains the same of the previous tutorial. The destination application needs a bit more of tweaking to handle an array of items. We have to store data in an ArrayCollection (line 2,5). At this point we could set up a renderer and a repeater to populate the form, but let’s have some fun with actionscript (lines 8-31).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

private const HEIGHT:int = 20;
private var myItems:ArrayCollection;
 
private function pasteFromClipboard():void {
	myItems = Clipboard.generalClipboard.getData("myCustomFormat") 
		as ArrayCollection;
 
	for each (var i in myItems) {
 
		var nameLabel:FormItem = new FormItem();
		nameLabel.label = "Name:";
		var nameText:TextArea = new TextArea();
		nameText.height = HEIGHT;
		nameText.text = i.name;
 
		var emailLabel:FormItem = new FormItem();
		emailLabel.label = "Email";
		var emailText:TextArea = new TextArea();
		emailText.height = HEIGHT;
		emailText.text = i.email;
 
		nameLabel.addChild(nameText);
		emailLabel.addChild(emailText);
 
		pastedItems.addChild(nameLabel);
		pastedItems.addChild(emailLabel);
 
		var hr:HRule = new HRule();
		hr.width = 40;
		pastedItems.addChild(hr);
	}
}

Here is an example of the final result.

Source code is available.

In Adobe Air you can store data in the object to enable cross application data transfer. We have already had a look at how to copy and paste images. In this tutorial we will see how to copy complex objects. By complex objects we mean a type of object which is not the usual String, but something a bit more complicated, like an instance of Person.

1
2
3
4
5
6
7
8
9
10
11
12

public class Person extends Object {
 
	public var name:String;
	public var email:String;
 
	public function Person(name:String, email:String) {
		super();
		this.name = name;
		this.email = email;
	}
 
}

We will create two Adobe Air apps: the first is the source from which we copy data, the second is the destination where we paste data in the clipboard. Let’s start with the source application. We create some instance of Person to populate an ArrayCollection which we feed into a DataGrid.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<mx:WindowedApplication 
	xmlns:mx="http://www.adobe.com/2006/mxml" 
	layout="vertical" 
	creationComplete="init()">
 
	<mx:Script>
		<![CDATA[
 
		import mx.collections.ArrayCollection;
 
		[Bindable] 
                private var collection:ArrayCollection = new ArrayCollection()
 
		private function init():void {
			collection.addItem(new Person("John", "john@john.com"));
			collection.addItem(new Person("Mary", "mary@mary.com"));
		}
 
		]]>
	</mx:Script>
 
	<mx:DataGrid id="grid" 
		dataProvider="{collection}">
 
	</mx:DataGrid>
 
</mx:WindowedApplication>

We will add a button to trigger the copy action of the selected item. Then we need a way to detect the selected item in the grid and store it into the clipboard. We do this in the copyToClipboard function.

1
2
3
4
5
6
7
8

private function copyToClipboard():void {
 
	var selection:Person = grid.selectedItem as Person;
	Clipboard.generalClipboard.clear();
	Clipboard.generalClipboard.setData("myCustomFormat", selection);
	feedback.text = "Data copied to the clipboard";
 
}

Here we should remember to be consistent with the key, myCustomFormat, that we adopt to store data in the clipboard (line 5). We’ll use the same key when we want to retrieve data in the Destination application. Below is the complete code of the Source application.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication 
	xmlns:mx="http://www.adobe.com/2006/mxml" 
	layout="vertical" 
	creationComplete="init()">
 
	<mx:Script>
	<![CDATA[
	import mx.collections.ArrayCollection;
 
	[Bindable] 
	private var collection:ArrayCollection = new ArrayCollection()
 
	private function init():void {
		collection.addItem(new Person("John", "john@john.com"));
		collection.addItem(new Person("Mary", "mary@mary.com"));
	}
 
	private function copyToClipboard():void {
		var selection:Person = grid.selectedItem as Person;
		Clipboard.generalClipboard.clear();
		Clipboard.generalClipboard.setData("myCustomFormat", selection);
		feedback.text = "Data copied to the clipboard";
	}
	]]>
	</mx:Script>
 
	<mx:DataGrid id="grid" 
		dataProvider="{collection}">
 
	</mx:DataGrid>
 
	<mx:Button label="Copy to Clipboad" 
		enabled="{grid.selectedItem != null}" 
		click="copyToClipboard()"/>
 
	<mx:Text id="feedback" />
 
</mx:WindowedApplication>

Now let’s move to the Destination application, which we will have just a form and a button to paste data.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication 
	xmlns:mx="http://www.adobe.com/2006/mxml" 
	layout="vertical">
 
	<mx:Script>
	<![CDATA[
 
	[Bindable] 
	private var myObj:Object;
 
	private function pasteFromClipboard():void {
		myObj = Clipboard.generalClipboard.getData("myCustomFormat");
	}
	]]>
	</mx:Script>
	<mx:Form>
		<mx:FormItem label="Name:">
			<mx:TextArea text="{myObj.name}" height="20"/>
		</mx:FormItem>
		<mx:FormItem label="Email:">
			<mx:TextArea text="{myObj.email}" height="20"/>
		</mx:FormItem>
	</mx:Form>
 
	<mx:Button label="Paste" click="pasteFromClipboard()"/>
</mx:WindowedApplication>

As said above, to retrieve data in the clipboard we have to use the same key, myCustomFormat. The binding does the rest, populating our form. Here is a video of the result.

Source code is available.

After learning drag and drop we will dig into copy and paste. We have already seen how to use the clipboard class to temporary store data during the drag action. Now we will use the same class to copy and paste an image within an Adobe Air application. We will start with the following layout.

This corresponds to the following mxml code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<mx:WindowedApplication 
	xmlns:mx="http://www.adobe.com/2006/mxml" 
	backgroundColor="#222222" color="#f5f5f5" 
	layout="vertical">
 
	<!-- Feedback -->
	<mx:Text id="feedback" height="20"/>
 
	<!-- Image to copy -->
	<mx:Image id="im" source="logo.png"/>
 
	<!-- Commands -->
	<mx:HBox>
	    <mx:Button label="copy" 
	 	click="copyToClipboard()"/>
	    <mx:Button label="paste" 
		click="pasteFromClipboard()"/>	
	    <mx:Button label="clear" 
		click="Clipboard.generalClipboard.clearData(ClipboardFormats.BITMAP_FORMAT)"/>
	</mx:HBox>
 
	<mx:VBox id="copies" width="{im.width}"/>
</mx:WindowedApplication>

Let’s have a look at the copy mechanism. We want to be sure that, before copying, the clipboard has no bitmap (line 3). Then we create a BitmapData object to store the content of the image (lines 4-5) and we put it in the clipboard (line 6). We gently provide some feedback (line 7).

1
2
3
4
5
6
7
8
9

private function copyToClipboard():void {
 
    Clipboard.generalClipboard.clearData(ClipboardFormats.BITMAP_FORMAT);
    var data:BitmapData = new BitmapData(im.width, im.height);
    data.draw(im); // this copies the content in the clipboard
    Clipboard.generalClipboard.setData(ClipboardFormats.BITMAP_FORMAT, data);
    feedback.text = "Data have been copied";
 
}

The paste mechanism is pretty similar to the one illustrated in previous tutorials. We read data from the clipboard (line 3), create a new Image class to store the Bitmap and then add it to the duplicates area (lines 4-7).

1
2
3
4
5
6
7
8
9

private function pasteFromClipboard():void {
 
    var b:Bitmap = new Bitmap(Clipboard.generalClipboard.getData(ClipboardFormats.BITMAP_FORMAT) as BitmapData);
    var i:Image = new Image();
    i.height = b.height;
    i.addChild(b);
    copies.addChild(i);
 
}

This is the intended result.

Source code is available.
Next time we will see how to copy and paste a complex object.

If you are planning to build a RIA both in web and desktop format Flex is a good candidate. I suspect that both will be pretty similar, and probably the desktop version will have extended functionalities that exploit the capabilities of the operative system. If you are the programmer of such a RIA you probably might not want to have two separate projects. Or at least you might need to have some core code, shared by projects, which you change just once. Although some solution has already been proposed, here is my take, a very simple one: a symbolic link!
Just put the core code in a Flex project and then create a folder in the Air project, which is not a real folder but a symbolic link to the folder already contained in the Flex project.

Step by Step

Let’s start with a Flex project. We’ll name it MyFlexProject. Then we create a class, called MyClass, as in the picture below.

We will add a trace statement to show when an instance of MyClass is created.

1
2
3
4
5
6
7
8
9
10
11
12

package com.studiomagnolia.shared
{
	public class MyClass extends Object
	{
		public function MyClass()
		{
			super();
			trace("Created an instance of MyClass");
		}
 
	}
}

Now we create the Air project. Let’s call it MyAirProject. And here comes the trick. Open a shell and move to the src directory of the Air project. Here you have to create a symbolic link which points to the src/com folder of MyFlexProject.
The code for bash shell is the following:

      ln -s ../../MyFlexProject/src/com

Now if you refresh MyAirProject you will see that the src folder contains a com subfolder. Cool uh? Now let’s write some code to see whether we can use MyClass in the Air project.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="onCreationComplete()">
 
	<mx:Script>
		<![CDATA[
 
			import com.studiomagnolia.shared.MyClass;
 
			private function onCreationComplete():void {
				var c:MyClass = new MyClass();
 
			}
 
		]]>
	</mx:Script>
 
</mx:WindowedApplication>

In the console you should see the trace statement. You can access/edit/save the core code from both the Flex and the Air project. Try changing the trace statement within the Air project and you’ll see changes reflected into MyFlexProject.

Hope this helps.

Flash running on the android platform? Yes. Flash was already been demonstrated as running on android. Now Bsquare has been charged to make the porting of the flash technology to the android platform. I started the study of the iphone sdk a while ago, and so did many flexers/actionscripters. But this news makes me mumble. I like learning new languages/frameworks a priori but I probably will have to set a preference: android or iphone?

I have set up a poll here. State your opinion!

In case you are wondering: “Can I pass parameters to an Adobe Air application at startup?” the answer is … YES. I didn’t know and I didn’t expect to ask myself a question like that. But it happened. For an interanl project there was a requirement to startup an application via shell and pass some parameter as input. A query to google with these keywords “adobe air passing shell parameters” does not return relevant information. So I decided to write a blog post.
The WindowedApplication class has an interesting event called InvokeEvent. As you can imagine it is fired when the application is invoked. This is the right place to detect whether there are parameters to be considered before drawing the main window. Let’s see some code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" 
    layout="absolute" 
    invoke="handleOnInvoke(event)">
    <mx:Script>
    <![CDATA[
	private function handleOnInvoke(event:InvokeEvent):void {
	    trace("arguments: "+ event.arguments.toString());
	    feedbackText.text = "arguments: " + event.arguments.toString();
	}
    ]]>
    </mx:Script>
 
    <mx:Text id="feedbackText"/>
 
</mx:WindowedApplication>>

At line 3 we bind the event to a function, handleOnInvoke. The InvokeEvent handled by the function has some interesting properties attached. One is the arguments array. If you simply debug the application, the array is empty. To test it you have two ways:

• specify parameters in the Flex builder
• create an application and run it from the shell

Specify parameters in the Flex builder

Runner and debugger can handle parameters that are passed to the application. Follow this procedure.

1. Right click on the project’s folder and select ‘Properties’
2. On the left select ‘Run/Debug settings’
3. Select the current launch configuration (there should be one) and click edit
4. In the field ‘Command line arguments’ specify your parameters (e.g. testParameter) and hit Apply (see figure below)

If you now debug the application you’ll see the trace message in the console tab, as in the figure, and the text field will display parameters as well.

Create and run an application

Another way to see the parameters is to export a .air file and install it. In this case you have to run it from the shell (Terminal for MacOsX users, command line for Windowsians). Once you installed the air application move to the installation directory and try to run it with some parameters, as in the figure below.

The InvokeEvent contains interesting data about the application. For example you can easily find out which is the local directory where the application is running.

    event.currentDirectory.nativePath;

The source code for this post is available here under the New BSD license.

I finally found some spare time to organize the stuff presented at flexcamp and make it a blog post. I “argue” with the Flex profiler almost daily and we had an “intense” relationship the month right before the flexcamp. So I felt a talk about profiling and Garbage Collection (GC) was really fit. Right, it is impossible to decouple profiling from GC. If you want to improve the memory management of your application you have to know how the Flash Player (and Adobe Air) manage memory allocation and deallocation.
Let me start by saying there are many blog posts about issues related to GC and profiling, ranging from documentation, presentations, how-tos, etc. I list them at the bottom.
The present post can be considered useful to beginners and medium experienced people which use Flex almost daily and have the need to optimize memory consumption. After introducing the fundamental concepts I will list a set of lessons learned during the development of Posty and Focused. I will particularly focus on the use of renderers’ caches.

Virtual Machine (VM)

The flash player is based on a virtual machine (to be precise the machines are 2, one for actionscript2 and one for actionscript3). VMs dynamically allocate memory when you create new objects. For example the following line of code creates a new Object.

1

var o:Object = new Object()

At startup the VM reserves some memory and when the code above is executed decides where the object goes in the application memory and how much space it takes. As you create objects the VM might use all the memory allocated at startup and, when needed, requests some more to the operative system. Unless you have a program which nonsensically just creates new objects, there will be some time during the execution when an object becomes “useless”, e.g. it is not needed anymore for the correct execution of the program. You’ll see that it is not easy to “understand” when an object is not needed. For now let’s assume we are able to detect it.
In the Flash VM achitecture you cannot explicitly say “delete it”. Memory usage is managed, that is the VM itself is responsible to check which objects are useless and delete them. Such a mechanism is called Garbage Collection.

Garbage Collection

So what can I do as a programmer? Well, you can ease the task of the garbage collector. Let’s see what we expect to happen with the help of a figure.

At startup the application reserves some memory to be used, say four blocks. When you create a new object the VM allocates it using the first slot. Let’s say that after a while o1 is not needed anymore and you set it to null. When you create a new object, o2, you expect that it takes the place of o1. Sometimes it happens, sometimes it does not. This depends on the garbage collection mechanism, which is a pretty complex procedure we are not describing here (a good article has been written by Grant Skinner).
At this point we already have a lesson learned: “setting an object to null does not necessarily free the memory it was occupying“.

This depends on the way GC has been implemented in flash. GC is triggered by allocation” and not deletion. This means that the GC cycle is run when you say new Object() and not when you set it to null.

Memory Consumption

If you have to do with AS3 and Flex you probably know that you can dynamically add UI elements to the graphical interface via a simple method called addChild(). The opposite method is removeChild(), which removes a display element from the UI. To be more precise, the element is deleted from the view (it is not displayed anymore) but this does not mean it has been garbage collected. Let me introduce you to a simple scenario to show you easy is to put too much trust in the removeChild() method.
Many Flex applications load data from a server and display it dynamically, according to the values returned. Usually the view code is isolated in a component, often referred to as renderer, which is responsible of showing the data loaded from the server. We devise a very simple renderer that is made of two text fields, embedded in a VBox. Data shown are field1 and field2, properties of the object provided as input.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" 
    borderStyle="solid" width="200" 
    >
    <mx:Script>
        <![CDATA[
	    [Bindable] private var _field1:String;
	    [Bindable] private var _field2:String;
 
	    override public function set data(value:Object):void {
		_field1 = value.field1;
		_field2 = value.field2;
	    }
	]]>
	</mx:Script>
 
	<mx:Text text="{_field1}" />
	<mx:Text text="{_field2}" />
</mx:VBox>

Let’s simulate data loading by means of a simple function, which returns an array of objects.

1
2
3
4
5
6
7
8
9
10
11

private function getData():Array {
    var a:Array = new Array();
 
    for (var i:uint = 0; i< 200; i++) {
	var o:Object = new Object();
	o.field1 = "field "+Math.random().toString();
	o.field2 = "field "+Math.random().toString();
	a.push(o);
    }			
    return a;
}

To render data we use a simple function which creates a renderer, sets its data, and adds it to the VBox.

1
2
3
4
5
6
7
8
9
10
11

private function loadData():void {
    vbox.removeAllChildren();
    var array:Array = getData();
 
    for (var i:int = 0; i < array.length; i++) {
	var rend:MyRenderer = new MyRenderer();
	rend.data = array[i];
	box.addChild(rend);
        i++;
    } 
}

Do you see the dangerous statement? Not yet? Let me show you. To simulate a repeated action I add a timer which calls the load function each N seconds.

1
2
3
4
5

private function init():void {
    var t:Timer = new Timer(2000);
    t.addEventListener(TimerEvent.TIMER, tick);
    t.start();
}

Now try running the profiler. Do you see an ever growing graph like this?

Congrats! We have found a memory leak! A memory leak happens when the same action is repeated and memory consumption grows instead of being constant. Did you find the dangerous statement? It is when you create the renderer. Why? Because you assume that removeAllChildren() removes renderers from the memory. Wrong! As said above that method only removes renderers from the display tree. In fact, as you can see in the profiler, renderers are still there, consuming memory.

UPDATE: Technically speaking this is not a memory leak, because there is nothing that prevents the garbage collector to clean up memory from renderers. A memory leak happens, in fact, when there is something that is supposed to use the renderer (e.g. a listener) even when you remove it from the display tree. In this example renderers are ‘free” and could be garbage collected. But they are not. So the result is the same of a memory leak, an ever growing memory consumption.

There are many techniques to solve this situation. We will show two: caching renderers and dynamic caching.

Caching

Let’s assume you know in advance how many renderers are needed. One way to solve the memory leak is to create a cache of renderers at startup.

1
2
3
4
5
6
7

private var cache:Array = new Array();
 
private function initRenderers():void {
    for (var i:int = 0; i < 200; i++) {
	renderers.push(new MyRenderer());
    }
}

We can then modify our loadData method like this:

1
2
3
4
5
6
7
8
9
10
11

private function loadData():void {
    container.removeAllChildren();
    var array:Array = getData();
 
    for (var i:int = 0; i < array.length; i++) {
	var rend:MyRenderer = cache[i];
	rend.data = array[i];
  	container.addChild(rend);
	i++;
    } 
}

As you can see in the code we don’t create new renderers but we look for one in the cache. There are cases when you don’t know in advance which data are returned from the server and then you don’t know how many rendereres you need. In this case you need a dynamic cache.

Dynamic cache

Dynamic caching is based on an elastic mechanism. You have a place where you can look for a renderer: if there is one in the cache, that is returned, otherwise a new one is created temporarily. Better to see some code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public class MyRendererCache extends Object {
 
    private static var cache : ArrayCollection = new ArrayCollection();
 
	public function MyRendererCache() {
	    super();
            for ( var x : Number = 0; x < 20; x ++ ) {
		cache.addItem( new MyRenderer() );
	    }
	}
 
	public static function getRenderer() : MyRenderer {
	    var renderer : MyRenderer;
 
	    if ( cache.length <= 0 ) {
		renderer = new MyRenderer();
	    } else { 
		renderer = cache.removeItemAt( 0 ) as MyRenderer;
	    }
 
	    return renderer;
        }
 
        public static function setRenderer( renderer : MyRenderer ) : void {
	    cache.addItem( renderer );
        }		
}

In the constructor you populate the cache with the minimu number of renderers, say 20 (lines 7-9). The cache has two static methods, getRenderer and setRenderer. The first is used to obtain a renderer, the second to give it back when done. If you look and lines 15-16 the cache returns a new renderer when the cache is empty. This way the number of renderers in memory can grow beyond the minimum number set in the constructor, but just temporarily, since the GC will delete them when not referenced anymore.
An important issue is related to the setRenderer. When you don’t need a renderer anymore you have to return it back to the cache, otherwise we fall again in a memory leak as explained above. To achieve this we exploit the remove event of the renderer. The remove event is triggerer whenever a UI element is removed from the display list. For example when we call removeAllChildren() such event is triggered for each renderer.
We can modify the renderer like this:

1
2
3
4
5
6
7
8
9
10

<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" 
    borderStyle="solid" width="200" 
    remove="onRemove()"
    >
 
    private function onRemove():void {
	MyRendererCache.setRenderer(this);
    }
....
</VBox>

If you now run the profiler you will notice that memory grows until a given point and then keeps stable as in the figure below.

Congratulations! You have solved the memory leak!

Suggesting the GC

Besides favoring the job of GC Adobe has allowed programmers to suggest the intervention of the GC. The command is in the flash.system package and it is System.gc(). By documentation this “Forces the garbage collection process” but in my experience it is just a vague suggestion of intervention. It can solve some situation, so it is worth trying it at the beginning, when you need a quick way to save some memory.


Here are the slides of my talk at flexcamp.

Full screen slides available here.

The source code of this post is available under the new BSD license.

References

• Garbage Collection and Memory Leaks by Alex Aharui. Somehow outdated but a good introduction.
• Tip to force GC via local connection.
• GC and Flash player 9. Good article by G. Skinner.
• GC and reflections on Adobe Air vs the design of Flash player by Sean Christmann (creator of the Ebay Desktop application).
• The downside of developing Adobe Air application via Html/JS. Reflections on the lack of a profiler.
• Tips to optimize Air/Flash applications presented by Sean Christmann at Max 2008 Milan