Adobe Flex

Changing Diabetes Barometer is now an Adobe MAX Semifinalist

After winning two awards last year for our “MyHome – Your Intelligent Home” and the “Nasdaq Market Replay”, it was with great interest we here at Hello Group were awaiting the email from Adobe telling us if our very cool application – “Changing Diabetes Barometer” had made it to the next level in the prestigious Adobe MAX Awards.

Today the email came, informing us that it had made it to the Semifinals… a great accomplishment thinking about some of the troubles the project had been undergoing from its inception to its transition into production, and then even some after that (as it most often is the case, I suppose).

Check it out…


The system was build in Adobe Flex 3 with an architecture based on PureMVC MultiCore with a backend in .NET running a MS SQL Server 2005 and a WebORB tying it all together.

Adobe Flex

ClassMappings between WebORB and Adobe Flex

Basically there are three methods to obtain a classmapping between WebORB and Adobe Flex.

1. ClassAlias in WebORB configuration.
2. ClassAlias in your ActionScript code through the “registerClassAlias” class.
3. ClassAlias in your ActionScript classes through the RemoteClass metatag.

1. ClassAlias in WebORB configuration
Add the following to your WebORB configuration file (This can also be done through the WebORB management console):

Name of ClientClass
Name of ServerClass
Name of assembly

2. ClassAlias in your ActionScript code through the “registerClassAlias” class.

var clientClass:Class = getDefinitionByName( clientClassName ) as Class;
registerClassAlias( serverClassName, clientClass );

3. ClassAlias in your ActionScript classes through the RemoteClass metatag.


The result is almost identical (some differences in behavior exists, but outside the scope of this short note) and will eventually mean that serverclasses returned and send to the server will be serialized and deserialized between the two class-definitions automatically by the WebORB server and the Flas Player respecitively.


Debugging WebORB from Visual Studio

Its quite easy to debug applications running within the WebORB for .NET container with Visual Studio, however there are a few precautions to observe before its possible.

Some of the things I mention may seem obvious to you, but based on my experience – some of these very obvious details can be some of the pitfalls that prevent many developers from debugging their applications once deployed to WebORB, so now I include them here in my list for the seasoned developers to ignore and the novices to use.

First make sure that your assemblies are compiled with DEBUG information, you don’t have to deploy the PDB files to the WebORB BIN directory. PDB files are the program database files which holds debugging and project state information for your program, but Visual Studio and the .NET runtime can map the debug assembly to the code in Visual Studio if just the PDB files are available in the output directory of the Visual Studio project.

From Visual Studio (I am using 2008, but its the same for 2005) with the code open used to generate the assemblies, you open the “Attach to Process” window found from the “Debug” menu.

Make sure that the checkbox “Show processes in all sessions” is selected.

Find the w3wp.exe (The IIS Worker Process) and attach the debugger to it.

I have for the sake of convenience mapped the following keyboard shortcut for opening this window: CTRL+SHIFT+ALT+F5. That has enabled me to start the debugging process with the following key sequence:

* “w” or “W”

Now Visual Studio will start the debugging session and map the debugging assembly to the code in Visual Studio.
As the debugging information are loaded you will see your breakpoint indicators be filled out, effectively indicating that debugging information mapping to the current code have been loaded. If your breakpoint indicators remain unfilled circles, it is not working, a likely cause for this is that the deployed assemblies have been compiled without DEBUG information.

Once your assemblies are loaded correctly and your breakpoint indicators are correctly filled, you turn your attention to either your application or the WebORB management console (I recommend the latter as its always a good idea to test each tier isolated).

Once you execute the code which eventually will hit the breakpoints, control will be transferred to Visual Studio and your debugging session should be fully active.

PS. Yes, the code in the second screendumb is a joke 🙂


WebORB : Passing headers from the Client to the Server

Passing custom headers from the client to the server is made very easy using RemoteObjects and WebORB for .NET.

1. Initially during the construction of the RemoteObject in the client-code, we add an eventlistener for the Invoke event on the RemoteObject:

this.service.addEventListener( InvokeEvent.INVOKE, ServiceDelegateCallManager.handleInvoke );

2. In the handler we add the header:

public static function handleInvoke( event:InvokeEvent ) : void
var message:AbstractMessage = event.message as AbstractMessage;
message.headers.MBUserID = User.current.userId;

3. On the server its really easy to retrieve the custom headers side by side with the default Flex DataServices headers. In the respective method called on the server we are now able to retrieve the added header with a mere 3 lines of code:

using Weborb; // to import ORBConstants
using Weborb.Util; // to import ThreadContext

Hashtable props = ThreadContext.getProperties();
Hashtable headers = (Hashtable)props[ ORBConstants.REQUEST_HEASDERS ];
String mbUserID = (String)headers[ “MBUserID” ]

Thanks to Mark Pillar from MidnightCoders for providing the insight in WebORB to do this.
If you are interested in reading more about Flex and .NET security, please check out Mark’s article on – its and excellent primer on this topic (

Adobe Flex

Passing ArrayCollections between .NET and Flex

When using the Weborb communication server from MidnightCoders there is a shortcoming in regards to supporting serverside deserialization of ArrayCollections. It supports Arrays but when trying to send complex types containing a reference to a ArrayCollection it is necessary to add a classmapping manually.

If one tries to pass an ArrayCollection to the server it will throw an error and the client will handle it without explaining exactly what went wrong. Recieving lists and collections and have them deserialized on the client into an ArrayCollection is no problem, its just the other way around that is more complex.

You need to map the (ClientClass) to the omnipresent Weborb.Util.ObjectProxy (ServerClass).
This can be done wither through the management console (Typically the default webpage of the server) or via the weborb.config residing in the “bin” directory of the server.

Why they have ommitted this classmapping from the default configuration beats me, but the operation is very simple, so it should not pose a significant problem once acknowledged.