A simple AIR / BlazeDS / Remoting example

March 26th, 2008

I'm in the process of implementing remoting using RemoteObject and BlazeDS in my Language Collaborative project's AIR-based player application. It seems that there aren't any example apps out there that show this particular scenario in action. Here's a quick one.

This example builds on my previous post on Running The BlazeDS Sample Applications in (non-turnkey) Tomcat, and assumes that you have completed the process described therein. If you're using the BlazeDS turnkey Tomcat install or some other J2EE server you should be able to translate. If any of these instructions are unclear it may be because you need to refer to that post.

  • Make a copy of the 'testdrive-remoteobject' sample app folder, name it 'testdrive-remoteobject-air', and place it into an Eclipse workspace.
  • Follow the instructions for setting up a Flex Builder project as specified in my previous post, with these changes:
    • Select 'desktop application' under 'application type', rather than 'web application'.
    • Perhaps this is obvious, but the project name, folder name, etc. will have "-air" appended onto them.
  • Open main.mxml and copy the following code below the existing code. We'll compare the two briefly, then delete the original code.
PLAIN TEXT
CODE:
  1. <?xml version="1.0" encoding="utf-8"?>
  2. <mx:WindowedApplication
  3.         xmlns:mx="http://www.adobe.com/2006/mxml"
  4.         backgroundColor="#FFFFFF"
  5.         creationComplete="init()">
  6.  
  7.     <mx:Script>
  8.         <![CDATA[
  9.             import mx.messaging.Channel;
  10.             import mx.messaging.ChannelSet;
  11.             import mx.messaging.channels.AMFChannel;
  12.  
  13.             public function init():void
  14.             {
  15.                 var cs:ChannelSet = new ChannelSet();
  16.                 var customChannel:Channel = new AMFChannel("my-amf", "http://localhost:8080/samples/messagebroker/amf");
  17.                 cs.addChannel(customChannel);
  18.                 srv.channelSet = cs;
  19.             }
  20.         ]]>
  21.     </mx:Script>
  22.  
  23.     <mx:RemoteObject id="srv" destination="product"/>
  24.  
  25.     <mx:DataGrid dataProvider="{srv.getProducts.lastResult}" width="100%" height="100%"/>
  26.  
  27.     <mx:Button label="Get Data" click="srv.getProducts()"/>
  28.  
  29. </mx:WindowedApplication>

Here's what we've changed:

  • We changed two Application tags to WindowedApplication.
  • We're dynamically setting up a channel for our RemoteObject. The code is fairly straightforward so I won't go into the details, but it's worthwhile to understand what this replaces. Typically our channels are set up using configuration files. There are a number of reasons why we might want to configure this or other config settings dynamically, but in this case our reason is that the default setting don't work correctly for an AIR application. I can't explain the details of why this doesn't work (perhaps someone from Adobe can add a comment) but let's take a quick look at the standard approach, and what we've changed.
    • Go to /webapps/samples/WEB-INF/flex/
    • Open remoting-config.xml. Note that in the default-channels tag 'my-amf' is specified. This means that all of the destinations defined below, such as 'product' (the one we use) will use the 'my-amf' channel.
    • Open services-config.xml. Search for "channel-definition id="my-amf"". Note that the 'my-amf' channel's endpoint URL is defined using several tokens: server-name, server-port and context-root. These tokens don't work properly when an app is compiled as an AIR app, thus the need to define the channel and its URL ourselves.
    • Note that while the typical configuration's approach is for our RemoteObject to find its channel set by looking at its destination, we can (and do) set RemoteObject's channelSet property directly, which overrides the channel set specified for its destination in the config files.
    • BTW, another (simpler?) approach would be to simply edit the definition for the my-amf channel in services-config.xml so that the endpoint URL is hardcoded rather than using tokens.
  • That's all that's needed. You can now delete the original code, save, compile, and run and/or debug your AIR application. :)
  • Reminder: If you get an error that says "RPC Fault faultString="flex.samples.DAOException : java.sql.SQLException: socket creation error" it may be because the sample database isn't running.

Here's a link to the docs on Run-Time Configuration for BlazeDS.

Posted by Douglas McCarroll Filed in AIR, AMF/Remoting, BlazeDS, Tomcat
7 Comments »