This approach requires the creation of a getter method for the eventDispatcher from the Application Shell’s context. The eventDispatcher is then injected into the contexts of each module using:

1
2

// injects the application shell's eventDispatcher into the module's context
injector.mapValue(EventDispatcher, Application.application.applicationEventDispatcher, "ApplicationEventDispatcher");

The “ApplicationEventDispatcher” is then used to listen to events and to dispatch events throughout the entire application.

Here is the demo and the source code.

The benefits of using this workaround is that you can have modules in their own encapsulated contexts, the disadvantage is that this solution is not very scalable if you have lots of events that need to be mapped between the contexts.

The basic idea is to create a getter for the _eventDispatcher property in the context of each module. Once the root application has fired the creationComplete event, the handler for creationComplete needs to use the getters so that the root application can perform the necessary event mapping which will allow the two modules to communicate.

Here is the demo and the source code.

I’ve added inline comments within the source code explaining how to map the events between the modules.

I created a very simple demo which I used to learn how to implement the Robotlegs Modular Utility and this post will provide a step by step walkthrough of how to setup a modular Robotlegs project in Flex 3.5. This tutorial is for people that have some knowledge of the Robotlegs framework & Flex. You can learn more about Robotlegs at the Robotlegs knowledgebase.

To get started you will need the following:

• Flex Builder 3 or Flash Builder 4 with the Flex 3.5 SDK
• Robotlegs framework & Robotlegs Modular Utility

The simple demo application features two modules and an application shell. The first module is a button which will send the timestamp from the Date Object’s getTime() method to the second module, which will then display the timestamp. The application shell simple holds the two modules.

Here is the demo & source code for those of you that don’t want to read the whole tutorial. The links are provided again at the end of the posting for those that want to finish reading the tutorial.

The first step is to create a new project in Flex and then to copy the files for the Robotlegs Modular Utilities into the src folder of your project and then to create the project structure for the sample application. The project tree in Flex should look like the following image after you have completed setting up the project.

Part 1 – setting up the first module – ButtonModule

Now that the project has been setup, we’ll begin with creating the view for the ButtonModule; simply create a new MXML Component named ButtonModule.mxml under the buttonModule folder.

Code for ButtonModule.mxml:

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

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml" width="200" height="200">
	<mx:Script>
		<![CDATA[
			import org.robotlegs.utilities.modular.core.IModuleContext;
			import org.robotlegs.core.IInjector;
 
			protected var context:IModuleContext;
 
			[Inject]
			public function set parentInjector(value:IInjector):void
			{
				context = new ButtonModuleContext(this, value);
			}
		]]>
	</mx:Script>
	<mx:Button id="myButton" width="100%" />
</mx:Canvas>

The ButtonModule.mxml view defines the UI of the ButtonModule and also initializes the ButtonModuleContext by specifying the contextView and the injector when
the ButtonModule view is instantiated. The contextView is specifies the view that scopes the ModuleContext; i.e. the ModuleContext is only able to map injections/mediators within the contextView. The injector is used to insert classes into any other classes that as long as both the target and source classes are mapped within the scope of the ModuleContext.

Next, we need to create the a context for the ButtonModule; create an ActionScript Class named ButtonModuleContext.as with a superclass of ModuleContext under the buttonModule folder.

Code for ButtonModuleContext.as:

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

package com.digitaldogbyte.buttonModule
{
	import com.digitaldogbyte.buttonModule.views.ButtonModuleMediator;
 
	import flash.display.DisplayObjectContainer;
	import flash.system.ApplicationDomain;
 
	import org.robotlegs.core.IInjector;
	import org.robotlegs.utilities.modular.mvcs.ModuleContext;
 
	public class ButtonModuleContext extends ModuleContext
	{
		public function ButtonModuleContext(contextView:DisplayObjectContainer, injector:IInjector)
		{
			super(contextView, true, injector);
		}
 
		override public function startup():void
		{
			trace("button module context");
			mediatorMap.mapView(ButtonModule, ButtonModuleMediator);
		}
 
	}
}

The ButtonModuleContext simply maps the ButtonModule view to the ButtonModuleMediator. The mediator acts as the “code-behind” for the view; it is often used to map event listeners to event handlers for the view and is often contains business logic & presentation logic for view.

The mediator is the last piece required to complete the ButtonModule; create an ActionScript Class named ButtonModuleMediator.as with a superclass of ModuleMediator under the buttonModule/views folder.

Code for ButtonModuleMediator.as:

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

package com.digitaldogbyte.buttonModule.views
{
	import com.digitaldogbyte.buttonModule.ButtonModule;
	import com.digitaldogbyte.labelModule.events.LabelModuleEvent;
 
	import flash.events.MouseEvent;
 
	import org.robotlegs.utilities.modular.mvcs.ModuleMediator;
 
	public class ButtonModuleMediator extends ModuleMediator
	{
		[Inject]
		public var view:ButtonModule;
 
		public function ButtonModuleMediator()
		{
			super();
		}
 
		override public function onRegister():void
		{
			view.myButton.label = "display timestamp";
			addViewListener(MouseEvent.CLICK, onButtonClicked, MouseEvent);
		}
 
		private function onButtonClicked(event:MouseEvent):void
		{
			var date:Date = new Date();
 
			dispatchToModules(new LabelModuleEvent(LabelModuleEvent.DISPLAY_MESSAGE, date.getTime()));
		}
 
	}
}

In the ButtonModuleMediator, we are telling the mediator to listen for a mouse click on the view and handle the mouse click by invoking the onButtonClicked method. The onButtonClicked method then invokes the dispatchToModules method (inherited from ModuleMediator) which checks to see which module has a listener for the LabelModuleEvent.DISPLAY_MESSAGE event and then dispatches the event to that module.

At this point, your project explorer should look like this:

Part 2 – setting up the second module – LabelModule

The steps for creating the LabelModule are nearly identical to the steps taken to create the ButtonModule. You will need to create a view, context and mediator.

Code for LabelModule view – LabelModule.mxml:

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

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml" width="200" height="200">
	<mx:Script>
		<![CDATA[
			import org.robotlegs.utilities.modular.core.IModuleContext;
			import org.robotlegs.core.IInjector;
 
			protected var context:IModuleContext;
 
			[Inject]
			public function set parentInjector(value:IInjector):void
			{
				context = new LabelModuleContext(this, value);
			}
		]]>
	</mx:Script>
	<mx:Label id="myLabel" />
</mx:Canvas>

Code for LabelModule context – LabelModuleContext.as with a superclass of ModuleContext:

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

package com.digitaldogbyte.labelModule
{
	import com.digitaldogbyte.labelModule.view.LabelModuleMediator;
 
	import flash.display.DisplayObjectContainer;
	import flash.system.ApplicationDomain;
 
	import org.robotlegs.core.IInjector;
	import org.robotlegs.utilities.modular.mvcs.ModuleContext;
 
	public class LabelModuleContext extends ModuleContext
	{
		public function LabelModuleContext(contextView:DisplayObjectContainer, injector:IInjector)
		{
			super(contextView, true, injector);
		}
 
		override public function startup():void
		{
			trace("label module context");
			mediatorMap.mapView(LabelModule, LabelModuleMediator);
		}
 
	}
}

Code for LabelModule mediator – LabelModuleMediator.as with a superclass of ModuleMediator in the labelModule/views folder:

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
40
41
42
43
44
45
46
47
48
49

package com.digitaldogbyte.labelModule.view
{
	import com.digitaldogbyte.labelModule.LabelModule;
	import com.digitaldogbyte.labelModule.events.LabelModuleEvent;
 
	import org.robotlegs.utilities.modular.mvcs.ModuleMediator;
 
	public class LabelModuleMediator extends ModuleMediator
	{
		[Inject]
		public var view:LabelModule;
 
		public function LabelModuleMediator()
		{
			super();
		}
 
		override public function onRegister():void
		{
			setMessage("timestamp will display here");
			eventMap.mapListener(moduleDispatcher, LabelModuleEvent.DISPLAY_MESSAGE, onDisplayMessage);
		}
 
		private function onDisplayMessage(event:LabelModuleEvent):void
		{
			if (event != null)
			{
				if (event.data != null)
				{
					setMessage(event.data.toString());
				}
				else
				{
					setMessage("event data was null");
				}
			}
			else
			{
				setMessage("event was null");
			}
		}
 
		private function setMessage(message:String):void
		{
			view.myLabel.text = message;	
		}
 
	}
}

In the LabelModuleMediator you will notice that we are register the onDisplayMessage event handler for the LabelModuleEvent.DISPLAY_MESSAGE event.

To allow communication between the ButtonModule and LabelModule, we need to create a custom event. I decided to create the event as the LabelModuleEvent since the LabelModule is the module that will be listening and handling the event, while the ButtonModule only needs to dispatch the event.

The event can be created by adding a new ActionScript class named LabelModuleEvent.as with a superclass of Event in the labelModule/events folder.

Code for LabelModuleEvent.as:

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

package com.digitaldogbyte.labelModule.events
{
	import flash.events.Event;
 
	public class LabelModuleEvent extends Event
	{
		public static const DISPLAY_MESSAGE:String = "displayMessage";
 
		private var _data:Object;
 
		public function LabelModuleEvent(type:String, data:Object, bubbles:Boolean=false, cancelable:Boolean=false)
		{
			_data = data;
			super(type, bubbles, cancelable);
		}
 
		override public function clone():Event
		{
			return new LabelModuleEvent(type, bubbles, cancelable);
		}
 
		public function get data():Object
		{
			return _data;
		}		
 
	}
}

At this point, your project explorer should look like this:

Part 3 – setting up the application shell – ApplicationShell

You will need to create a view, context and mediator for the ApplicationShell.

Code for ApplicationShell view – ApplicationShell.mxml:

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

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml" preinitialize="preinit();" width="100%" height="100%" xmlns:buttonModule="com.digitaldogbyte.buttonModule.*" xmlns:labelModule="com.digitaldogbyte.labelModule.*">
	<mx:Script>
		<![CDATA[
			import org.robotlegs.utilities.modular.mvcs.ModuleContext;
 
			protected var _context:ApplicationShellContext;
 
			protected function preinit():void
			{
				_context = new ApplicationShellContext(this);
			}
		]]>
	</mx:Script>
	<mx:HBox>
		<buttonModule:ButtonModule id="buttonModule" />
		<labelModule:LabelModule id="labelModule" />
	</mx:HBox>
</mx:Canvas>

Code for the ApplicationShell context – ApplicationShellContext.as with superclass of ModuleContext:

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

package com.digitaldogbyte.applicationShell
{
	import com.digitaldogbyte.applicationShell.views.ApplicationShellMediator;
	import com.digitaldogbyte.buttonModule.ButtonModule;
	import com.digitaldogbyte.labelModule.LabelModule;
 
	import flash.display.DisplayObjectContainer;
	import flash.system.ApplicationDomain;
 
	import org.robotlegs.core.IInjector;
	import org.robotlegs.utilities.modular.mvcs.ModuleContext;
 
	public class ApplicationShellConteThext extends ModuleContext
	{
		public function ApplicationShellContext(contextView:DisplayObjectContainer=null, autoStartup:Boolean=true, parentInjector:IInjector=null, applicationDomain:ApplicationDomain=null)
		{
			super(contextView, autoStartup, parentInjector, applicationDomain);
		}
 
		override public function startup():void
		{
			trace("application shell context");
 
			viewMap.mapType(ButtonModule);
			viewMap.mapType(LabelModule);
 
			mediatorMap.mapView(ApplicationShell, ApplicationShellMediator);
		}
 
	}
}

Code for the ApplicationShell mediator – ApplicationShellMediator.as with superclass of ModuleMediator within the applicationShell/views folder:

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

package com.digitaldogbyte.applicationShell.views
{
	import com.digitaldogbyte.applicationShell.ApplicationShell;
 
	import org.robotlegs.utilities.modular.mvcs.ModuleMediator;
 
	public class ApplicationShellMediator extends ModuleMediator
	{
		[Inject]
		public var view:ApplicationShell;
 
		public function ApplicationShellMediator()
		{
			super();
		}		
	}
}

The final project structure should look like this:

Demo & source files for the tutorial.

The Nokia Extension allows users to author, validate, package and deploy Nokia WRT widgets.

The validation, packaging and deployment features were the most challenging to implement.

The validation calls the W3C Markup Validation Service which reads the DocType tag in the info.plist (widget configuration file) file to determine the DTD file that is used to validate the info.plist. Documentation on how to use the W3C Validator can be found here.

The packager used for the extension is a Java class written by Alexey Mykhaylov and his team from Xplorex; the packager is used to compress the files so that they can be deployed to Nokia S60 phones.

The deployment feature required the extension to send packaged widgets to a bluetooth paired phone. To implment this functionality I had to lean on Alexey and his team to create a Java wrapper so that I could use the BlueCove Java library.

I’d like to give thanks:

• Andrew Odri from Konductor for helping me out with his knowledge the Dreamweaver API.
• Alexey Mykhaylov and Xplorex for their assistance with the Java integration.
• Scott Fegette and Chris Bank from Adobe for taking the time to answer my questions.
• Michael Bierman and Matt Evered from Nokia for their patience and professionalism when managing the project under tight deadlines.
• Otto Salminen and Timo Klinga from Sasken for their hard work in finding most (if not all) of my bugs.
• Derek Zarbrook from Xplorex for acting as the contact between Nokia and Nitobi.
• My colleague Chris Stone for his awesome UX work and managing the project from Nitobi‘s side.

To create the codehints for a static javascript class you need to follow this xml structure in your codehints file:

1
2
3
4
5
6
7

 
<menu pattern="exampleObject." casesensitive="true">
	<menuitem label="identifier" icon="shared/mm/images/hintProperty.gif" source="Example Project" object="exampleObject" />
	<menuitem label="onShow" icon="shared/mm/images/hintProperty.gif" source="Example Project" object="exampleObject" />
	<menuitem label="onHide" icon="shared/mm/images/hintProperty.gif" source="Example Project" object="exampleObject" />
</menu>
<function pattern="exampleObject.openURL(String url)" casesensitive="true" icon="shared/mm/images/hintFunction.gif" source="Example Project" />

Codehinting Example for Static Classes

To create the codehints for an instantiated javascript class you need to follow this xml structure in your codehints file:

1
2
3
4
5
6
7
8

 
<function pattern="ExampleItem()" casesensitive="true" icon="shared/mm/images/hintClass.gif" source="Example Project" />
<menu classpattern="ExampleItem">
	<method pattern="append(ExampleItem childExampleItem)" icon="shared/mm/images/hintFunction.gif" />
	<menuitem label="ExampleItemStateChanged" icon="shared/mm/images/hintEvent.gif" />	
	<menuitem label="onSelect" icon="shared/mm/images/hintProperty.gif" />
	<method pattern="remove(ExampleItem childExampleItem)" icon="shared/mm/images/hintFunction.gif" />
</menu>

Codehinting Example for Instantiated Class

The JavaScript codehinting works perfectly in .js files; however I’ve noticed that the codehints for instantiated JavaScript classes do not display when you are working within <script> tags in .html files.

I’ve included a simple example Dreamweaver Extension that implements the exampleObject and ExampleItem JavaScript classes in the codehints. You can use the Example_CodeHints.xml file in the source as a reference point.

Link to source code download.

There are three eventhandlers:

1. after save event – this is triggered when the changes to a file have been saved.
2. before save event – this is triggered before the changes to a file have been saved.
3. on open event – this is triggered when Dreamweaver (and when documents) are opened.

You can find the global events in Dreamweaver’s default Commands directory.

Mac: Macintosh HD:Applications:Adobe Dreamweaver CS4:configuration:Commands

Windows: C:\Program Files\Adobe\Adobe Dreamweaver CS4\configuration\Commands

The eventhandler files are:

1. _afterSave.htm
2. _beforeSave.htm
3. _onOpen.htm

To create your own eventhandlers you simple create a prefixed version of the eventhandler command (e.g. alert_afterSave.htm). You can include the necessary JavaScript within <script> tags in your .htm file or you can write a corresponding .js (alert_afterSave.js) file that needs to be included in your .htm file.

I’ve created a very simple example extension that demonstrates how the eventhandlers work. The .mxp installer and source code can be downloaded at the end of this post. The example extension will install into your user account’s application data folder.

Mac: Macintosh HD:Users:<userName>:Library:Application Support:Adobe:Dreamweaver CS4:en_US:Configuration:Commands

Windows: C:\Documents and Settings\<userName>\Application Data\Adobe\Dreamweaver CS4\en_US\Configuration\Commands

Link to source code download.

Harvest does provide an iPhone application and also a Harvest Widget for Mac OS X & MS Vista. I decided to create an AIR application so that users on operating systems that don’t have widget support can do their time tracking from the comfort of their own desktops.

The harvestcoop AIR application currently works with Harvest accounts that have widget support.

Here are the links to the presentation’s slides, sample application and code.

The following are the default locations for the SQLite database:

Mac OS X:

/Users/<userName>/Library/Preferences/<applicationName>/Local Store/<databaseFileName>.db

Windows:

C:\Documents and Settings\<userName>\Application Data\<applicationName>\Local Store\<databaseFileName>.db

Adobe AIR 1.5 introduces a feature to encrypt the SQLite database so that you can secure the contents of database. This is could come in handy if you are writing an application that stores information such as customer contact data.

The Open method and the OpenAsync method of the SQLConnection class include an encryptionKey parameter; this parameter tells AIR to encrypt the database file.

The code sample below shows you how to create / open an encrypted SQLite database. Links to an example application & code can be found at the end of this article.

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

import com.digitaldogbyte.util.Encryption;
 
private var dbConn:SQLConnection;
private var dbFile:File;
private var dbKey:ByteArray;
 
private function init():void
{
	dbKey = Encryption.retrieveKey();
 
	dbFile = File.applicationStorageDirectory.resolvePath("EncryptionExample.db");
	dbFile.createDirectory();
 
	dbConn = new SQLConnection();
	dbConn.addEventListener(SQLEvent.OPEN, handleDbOpen);
	dbConn.addEventListener(SQLErrorEvent.ERROR, handleDbError);
 
	// by passing in the dbKey variable as the encryptionKey parameter we are telling AIR to encrypt the SQLite database
	dbConn.openAsync(dbFile, SQLMode.CREATE, null, false, 1024, dbKey);
}

Let’s take a look at the Encryption class to see how the dbKey ByteArray is created. The dbKey value is assigned the return value of the retrieveKey method from the Encryption class. The retrieveKey method checks to see if a key already exists in the application’s EncryptedLocalStore. If the key already exists the retrieveKey method will return the existing key, however if the key does not exist; the generateKey method is called to create a key.

The generateKey method uses the as3crypto library’s Random type to create a key. This key is required to read & write to the encrypted database.

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
40
41

package com.digitaldogbyte.util
{
 
	import com.hurlant.crypto.Crypto;
	import com.hurlant.crypto.prng.Random;
	import com.hurlant.crypto.symmetric.AESKey;
	import com.hurlant.crypto.symmetric.ECBMode;
	import com.hurlant.crypto.symmetric.ICipher;
	import com.hurlant.util.Hex;
 
	import flash.data.EncryptedLocalStore;
	import flash.utils.ByteArray;
 
	public class Encryption
	{
 
		private static var _key:ByteArray;
 
		private static function generateKey():void
		{
			// create key - write to encrypted local store
			_key = new ByteArray();
			var random:Random = new Random();
			random.nextBytes(_key, 16);
			flash.data.EncryptedLocalStore.setItem("key",_key);
		}
 
		public static function retrieveKey():ByteArray
		{
			// try to retrieve key from encrypted local store
			_key = flash.data.EncryptedLocalStore.getItem("key");
			// if no key found in encrypted local store - create a key
			if (_key == null)
			{
				generateKey();
			}
			return _key;
		}
 
	}
}

After you’ve created the encrypted database you can navigate to the database file and try to open it. The database file will not open in your database browser application since the actual database file has been encrypted.

Here are the download links to the example application & code.

This feature can be used to secure sensitive information like usernames & passwords for web services.

The encrypted local store can be found at these locations on a user’s computer:

Windows: C:\Documents and Settings\<username>\Application Data\Adobe\AIR\ELS\

Mac OS: /Users/<username>/Library/Application Support/Adobe/AIR/ELS/

To use the AIR’s encrypted local store you will need to include the following packages:

1
2
3

import flash.data.EncryptedLocalStore;
 
import flash.utils.ByteArray;

The following code shows an example of encrypting a string and then storing it in the EncryptedLocalStore object. The strToEncrypt string needs to be converted into a ByteArray since the EncryptedLocalStore stores all of it’s data as a hash table that uses strings as keys and byte arrays for the data. In our example, we convert the strToEncrypt into a byteArray as the myByteArray variable using the ByteArray object’s writeUTFBytes method. We are now ready to save our data into the EncryptedLocalStore, which is done by using the EncryptedLocalStore’s setItem method. The setItem method takes a string parameter that it uses as the key for the hash table and then a byte array as the data that it needs to store.

1
2
3
4
5
6
7

var strToEncrypt:String = "Herman";
 
var myByteArray:ByteArray = new ByteArray();
 
myByteArray.writeUTFBytes(strToEncrypt);
 
EncryptedLocalStore.setItem("firstName", myByteArray);

To retrieve the encrypted data from the EncryptedLocaStore you will need to use the getItem method and the string key for the data that you want to retrieve from the hash table.

1
2
3
4
5
6
7
8

var storedValue:ByteArray = EncryptedLocalStore.getItem("firstName");
 
// get the string from the storedValue byte array and store in the strDecrypted variable
var strDecrypted:String = storedValue.readUTFBytes(storedValue.length);
trace(strDecrypted); // "Herman"
 
// read the string from the storedValue byte array
trace(storedValue.readUTFBytes(storedValue.length)); // "Herman"

More documentation can on the EncryptedLocalStore class can be found on Adobe’s site.