o you've been a Java developer for most, if not all, of your career. You've been writing business logic in your Java classes and you've been creating application interfaces using JSP pages. More recently you may have used JSF (Java Server Faces) and/or Struts to improve things. But have you really succeeded? You are still writing JavaScript code to bring more life to your interface and to make it dynamic. JavaScript also helps you load XML data from the server without a round trip (otherwise known as AJAX). But don't you get the feeling that it's all the same, that nothing is better for you, the developer, or for the end user? Well, if you are asking yourself these questions, then you are in the same state of mind as I was back in the summer of 2004.
In the summer of 2004 I started work on a mini-CRM application called Phoenix with specific features for my company. I started creating the application interface using JSP pages, but I found I wasn't delivering a better quality application. So I began looking, and trying a whole bunch of technologies—namely the ones I mentioned above—to improve things. But some things still weren't right: It took too much effort to create reusable parts; the browser was always in the way with its JavaScript issues; and the code still looked in some cases like a plate of spaghetti. That's when I got lucky and got my hands on Adobe Flex. Needless to say, several months later, Phoenix was completed using Flex 1.0 as the basis for the interface. Since then, my company has used Flex on six other projects.
So why should any Java developer be interested in integrating Flex into an application? There are several reasons, and I will take a look at them one by one in this article.
Get started using Flex
Flex 2 (Flex Builder, Free Flex SDK, Flex Data Services)
Flex will be familiar to a Java developer
One challenge in introducing a developer to a new technology is the learning curve: No one wants to spend hours or days understanding the basics of a new technology. Learning Flex boils down to two things: MXML and ActionScript. If you know JavaScript, and if you know Java, then you know ActionScript. There are minor differences in the syntax, but you won't get stuck. See for example the following ActionScript code:
package demo
{
public class Person
{
// class fields
private var firstName:String;
private var lastName:String;
/**
* Constructor with parameters
*/
public function Person(fn:String, ln:String) {
firstName = fn;
lastName = ln;
}
/**
* Returns the full name of the person,
* exposed as a property on the class.
* @return the full name
*/
public function get fullName():String {
return firstName + " " + lastName;
}
}
}
With MXML, if you have worked with HTML or any kind of XML document, once again you know MXML. You just have get familiar with the properties of the components; there is great reference documentation for that. I'll let the following example demonstrate the simplicity of MXML:
width="400" height="300">
From looking at the code, you can see that it's a panel with standard buttons and a form for a typical registration page. Don't forget about CSS! Flex can load and use any CSS file you provide, either at compile-time or runtime.
The languages that Flex uses will be familiar to anyone coming from a Java background. This way, you don't waste everything you have learned over the years, you are only applying it a little differently. It comes down to the old proverb: Everything old is new again.
The Flex development process: It's a lot like the one you use for Java
One of the things that took me a while to realize was that developing in Flex is very similar to developing in Java. In any Java application you create classes: some are classes that encapsulate your business logic, some are utility classes, some are classes that communicate with a database, and much more. This is no different from what you do in Flex. In Flex, you create ActionScript classes that encapsulate your interface logic, utility classes, and classes that communicate with your middleware, which in most cases comprises the Java classes that I just mentioned.
In the last two Flex-based applications that I created, I found myself, more ever before, writing all the MXML code I needed first—thus defining all the various parts of the interface, to ensure that it fit the specification. Then I spent the rest of the time coding in ActionScript classes. Also, you can apply the J2EE patterns you've learned over the years to Flex. Many Flex developers use an MVC (Model-View-Control) framework called Cairngorm that uses many of the J2EE patterns you already know, such as the Value Object Pattern and the Service Locator Pattern. For me, with the architecture similarities, developing in Flex and Java are almost the same.
Another similarity between Flex and Java is application testing. In Java you write unit tests using JUnit and incorporate those tests into your nightly build script to see the results by morning. For Flex, you can unit test your ActionScript classes using FlexUnit. There is virtually no difference between FlexUnit and JUnit. You create test cases in ActionScript, run them using Ant, and then generate test results in HTML in the same fashion as for your JUnit tests. Basically, with every build, you run the Java and Flex unit tests at the same time, thus fully testing your application and making it as robust as possible.
I just mentioned the build process and that's the last thing I am going to bring up about similarities between the two technologies. Just like Java, in Flex code the MXML and ActionScript has to be compiled so that you can execute it within a VM (Virtual Machine), or in this case, Flash Player that resides within your user's browser. The great thing is that the Flex compiler resides within a JAR file, so you can execute it from an Ant build script. You can also run it by executing an EXE file in Windows and a shell script for Unix/Linux. Therefore, you can use your Ant build script to compile both the Java and Flex code.
Flex is simple to use and helps you develop code faster
Lastly, I'll discuss development speed with Flex. Flex comes with the familiar and basic components (Label, Button, TextInput, and so forth.) and more advanced components, such as the DataGrid, Tree, Charts, and more. Flex optimizes development time because the advanced components provide a lot of functionality (such as sorting, highlighting, and so forth) that there is no need for you to develop that advanced functionality over and over again. For these advanced components, you simply pass the component the data you want, set some properties, and it will render the information for you.
Secondly, you know how JSP pages look from a coding perspective: They're HTML mixed in with Java code and then some JavaScript sprinkled in here and there. It can get messy fast. Another challenge is that you have to hold lots of data on the server side to track what is happening on the client side; and you have to do many page refreshes to update the display. Some developers might call this technique "hacking things in order to make them work." With Flex there is no such weaving since everything is deployed and run on the client side. You generate the MXML code and put all the logic in ActionScript classes. With clear separation, it is easy for you to maintain and enhance MXML and ActionScript code. Instead, you can spend more time ensuring the product is easy to use and conveying the right information to the user.
Finally, don't forget what you create when you build a Flex application. It's not a set of pages that are simply connected together, it's an application. In fact it is an application deployed to the web with desktop-like features. It's a responsive, familiar, cross-platform, powerful, and visually pleasing application for your users. Check out Flex sample applications on the Flex Developer Center.
Some differences between Flex and Java
One of the key differences in using Java and Flex in the same project is the changes in the development process. These changes are due to the fact that there now is a distinct and clear separation between the business layer (Java code) and the presentation layer (Flex code).
During a typical project cycle in our team, one set of developers works on the interface while another set of developers works on the business layer independently. After the initial set of requirements for the project, our team either starts writing the business layer first or the interface first, depending on which developers are available and when. Developing each part is completely independent. The business layer developers design, write unit tests, and then write the business code to satisfy the unit tests. Meanwhile, the development on the presentation layer begins, such as reviews with users, and refining the look and feel. The best part is that the interface will actually be functional and it doesn't even do anything yet! Yes, it is possible because you are creating a pure client-side application. Users will see the interface change states and be able to manipulate data—the application will look like it's working.
Once both teams complete development and the application passes all of its unit tests, the last step is to plug the interface into the business layer, do one last round of testing, and, you're all done!
So in the end, what have we learned? First, you know that Flex will be familiar if you're coming from a Java background and that most of your skills and development techniques will carry over. In many cases, parts of the interface will be easier to develop, have more features, will be delivered more quickly, and adjustments will be easier to perform.
When you really think of it, this is the best marriage of two technologies in recent memory—Java for the business layer and Flex for the presentation layer. Basically, you can use the best technologies in each domain and your products will thrive because of it, especially the interface, which is the part of the application that users see and use. Your users will be impressed; meanwhile, you'll have a smile on your face because you didn't even break a sweat.
tag, you’re doing yourself a disservice in at least two ways by utilizing this technique. The first problem with this method of image sizing is that web browsers aren’t particularly good at shrinking or enlarging images. The browser doesn’t do any kind of resampling, so you often get a pixelated version of your original image, even when shrinking it. The second issue with sizing images by way of the browser is that you may be wasting a lot of bandwidth. An image that’s 1000 pixels by 800 pixels has a much larger filesize than one that’s 200 by 160 pixels, so if you’re forcing it to appear at the smaller size anyway, you’d be transferring a lot of extra data for no reason by resizing it on the client side. To resize images to the size you need, use any of the widely available free tools or websites that allow you to do so. 
, is applied to this Firefox extension to turn your GMail account into a Getting Things Done Inbox. Very useful and well written.