|
|
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.
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.
To get started with Flex, check out the following resources:
Download the Flex trial.
Try the Thirty-minute Flex test-drive for Java developers (Tomcat-based), by Adobe Flex evanglist Christophe Coenraets.
Try the Flex quick starts, which give you the fundamentals of using Flex.
See the Flex and Java area on the Flex Developer Center.
Check out the community on the flexcoders mailing list.
