Using Unit Testing to Test GWT RCP Calls

This is a short note. I'm working on a GWT application and ran into a problem with an RPC call which gets some objects from the database using Hibernate and passes them back to the client. I'm going to solve the problem using Dozer, but I needed to confirm this was the problem and simplify the testing of this in future. So, I decided I want to unit test this service from the client's perspective. Here are my notes from this exercise:

• The easiest way to create a GWTTestCase is using the GWT's jUnitCreator. Creating it by hand is possible but tricky.
• The asynchronous test needs to use delayTestFinish(delayMs) and finishTest(). In my case, I had to set 5000 Ms. For some reason, 500Ms, which I thought would be more than enough was timing out.
• The good news is, that when using Eclipse plugin for GWT, starting initiating Run as JUnit Test on the GWTTestCase test starts for you also the server. And doing the same with Debug as JUnit Test allows to debug the client as well as server code.
  

Note: the similar test is supported in Flex application!

Developing Flex Applications with Java Middle-Tier

Intro
In my job we are using Flex with Java to develop web applications that support the activity of the agency I'm working for. It's my first experience with Flex and I'd say, I'm duly impressed. I had experience of developing using GWT and I must say, that Flex is an equally good tool.

A Simple Way
Just follow this tutorial.

Tools Used
We use the following toolset:

• eclipse with FlexBuilder plugin (plugin is not free)
• jBoss
• Java for back-end
  
• LCDS to communicate between Flex and Java (not free, but there are free alternatives: BlazeDS and the LCDS Express is also free, I think).
  
• Cairngorm pattern for Flex client structure
  

Tips and Gotchas

• A great intro to Cairngorm (and Flex itself) is one by David Tucker.
• He is using ColdFusion for the back-end, so switch to this or this for how to do it with Java.

The Cairngorm pattern for calling a remote service is a bit complex. Here's how it goes:

• In the main mxml file (the one where you define mx:Application): instantiate the ServiceLocator: . The id "services" is irrelevant, it seems. And instantiate the FrontController.
  
• Let say, the command LOGIN is to be handled by the back-end. Dispatch the command by initiating the LoginEvent and calling dispatch() on it.
• Each event is mapped onto a command in the FrontController. Let say, in this case, onto a LoginCommand.
• In loginCommand, instantiate a delegate, say LoginDelegate and call the login(event)
• In LoginDelegate, obtain the service proxy using:
  ServiceLocator.getInstance().getRemoteObject("myRemoteObject");
  and call the login(args) on it.
• Now, two additional files need to be setup: Services.mxml and remoting-config.xml
• In the first one, Services.mxml, define a mx:RemoteObject with id="myRemoteObject" and the destination="myRemoteClass".
  
• In the second, the remoting-config.xml, define a destination with id="myRemoteClass" and the Java class package+classname in the source tag.
  
• In the Flex Server properties (access through project properties), set the Root Context as the /YourProjectName.
  

If you need to pass an object between client and the server, create two corresponding value objects (usually named *VO, like LoginVO), one in ActionScript in flex branch and one in Java branch:

• The ActionScript version, needs to have an annotation above the class definition: [RemoteClass(alias=org.sjb.LoginVO)].
• The Java version needs to be public and have public setters.

If you want to debug not only Flex (which is done the usual "eclipse" way), stop the JBoss server and start it in Debug mode. That's all that is needed.

Conclusion
Altogether, using Flex with Java is very simple. Enjoy it!