10 Things Every Java Developer Should Know About Flex

Java developers make great Flex/Flash developers. As an Adobe Certified Technical Trainer who has taught many Java programmers in the last several years, I have seen first-hand how quickly Java developers adapt to ActionScript. As a RIA Project Manager I have found Java developers not only pick up the Flex API quickly, but they use it correctly and generally follow best practices almost instinctively. Notwithstanding the above, Java developers tend to encounter some stumbling blocks along the way. First of all there is a paradigm shift in the way they approach applications that are considered "movies" by the Flash Player runtime. Generally speaking, I would say the area of the runtime is where my classes tend to slow down and the questions come quickly. In addition to the runtime, there are some unique features of ActionScript vs. Java or ActionScript vs. JavaScript. To explore some of these differences and shed some light on some of the more unique features of the Flash Platform, I interviewed Darryl West, Chief Technology Officer of roundpeg (San Francisco), a Web Development firm.

In many ways Darryl represents the Java developer I typically find in my enterprise training classes. Darryl is extremely well-versed in Java and deeply involved in open source, as well as Spring and Hibernate.  In addition to Java, Darryl actively programs to varying degrees in Ruby, Groovy, Grails, Javascript, Ruby on Rails and Flex. He is an excellent source of information regarding Flex from a Java programmers’ point of view and has worked on both the back and front-end (including Swing GUI experience) in both Java and Flex. He also has had significant exposure to database work and multi-threaded environments. My own experience involves the training, developing and managing of those who create Flex applications using the Flash Platform tools, servers and runtimes. In addition to being a technical trainer that specializes in HTML, CSS and Javascript, I am also an Adobe Certified Instructor for the Flash Platform. For the past five-plus years I have trained approximately 2,500 designers and developers representing over 700 small to large organizations. To provide further perspective, five of these firms are in the Fortune 25, 12 are in the Fortune 100 and 21 are in the Fortune 500.

The List

The result of my interview with Darryl is a list of ten things Java developers will find helpful, interesting and sometimes unique about the Flash Platform. Specifically the list includes some happy discoveries Darryl made in the course of his Flex development as well as some challenges he experienced along the way. The list also touches on some significant changes in thinking the Java developer might consider making in order to use the Flash platform most effectively.  It seemed appropriate for us to include some of the similarities and differences between ActionScript and JavaScript as well. Some of the lists’ topics include: the runtime, handling data access, and specifics of the ActionScript language including closures, cookies vs. shared objects, the external interface class and the local connection classes. We also looked at some specific MXML features regarding the user interface and mx components vs. spark components.

#1: The Flash Player is Single-threaded

When I tell my students that the Flex runtime, the Flash Player is single-threaded, it often causes confusion and results in misconceptions. Developers will often erroneously conclude that new operations such as a search attempt cannot occur while some other operation is in place, such as a view state change or remote procedure call. As Darryl states "the Flash Player is not really single-threaded, but threads are not exposed." Darryl has sometimes created pseudo-threads with various techniques (see # 10: Using the LocalConnection class) such as timers, "but they don’t operate like a real thread." While at first Darryl was surprised at this he doesn’t consider it a serious issue or flaw. "…with Swing you have to be real conscious of threads and cleaning them up when creating and destroying them…[Flash] eliminates the concerns a Java programmer might have such as if you begin a process, which thread to put it on…the runtime is multi-threaded but the programmer has no opportunity to use the threads."

Conclusion: "Compared to Swing, Flex applications are easier to develop and test."

#2: Write Once and Run Anywhere

Darryl reiterated a comment I make early on in my Flex training classes. "The Flash runtime is truly write once and run just about anyplace!" The Flash runtime is cross-platform, cross-browser and cross-browser-version. Although I am aware of known issues regarding frame rate and Internet Explorer vs. Firefox, Darryl has not encountered any problems in his applications. In this regard, Flex contributes to rapid application development, particularly in comparison to HTML, JavaScript, CSS applications where much time is devoted to testing and fixing cross-browser issues.

Conclusion: "With [Flash Player] rendering is nearly identical across browsers."

#3: Draw Once and Leave It Alone

As a Java developer if you are accustomed to using Java 2D or writing applets, you draw every time you need to update. With Flex, you draw once and leave it alone. The API has numerous transformations that can be applied – to rotate, to skew, to scale, etc.  "There is no need to loop through re-draws" according to Darryl, who once again found this a welcome change as well as a time-saving feature.

Conclusion: "Draw once and leave it alone."

#4: Flex is Extremely XML-friendly

While Darryl considers Java equally xml-friendly, he has found Flex to be extremely xml-friendly right "out of the box", eliminating the step of locating and using xml libraries. ActionScript natively supports EcmaScript for XML (also known as e4x). This provides Flex developers with an alternative to a DOM interface. e4x uses a simpler syntax for accessing XML documents treating the XML  as a primitive.  The effect is typically faster access, better support, and a resulting data structure for the program. On the other hand Darryl found Flex not as JSON-friendly and relies on the standard AS3corelib for JSON support.

Conclusion: Flex has "built-in" support for XML data exchange.

#5: Java projects can suffer from class bloat

"While Flex projects can also suffer from class bloat, the programmer is at the mercy of the runner. SWF’s larger than 300k should be considered ‘huge’ projects and therefore separated into Modules or separate SWFs." I asked Darryl to elaborate on this and the differences between custom components, modules and separate swfs. "A module is in the same space as the main swf that loaded it. A separate swf is running as if it were in another browser, so it doesn’t tie up the swf in the main space." Darryl suggests that the developer does not attempt to use a typical "Java Structure" with eight or ten tabs, a lot of input forms, etc. that result in increasing the size of your main swf to greater than 300k. Instead, split the main swf into a separate project and swf." He recently stripped out the printing feature of a main application which was pulled out into its own swf project. The application had an info tab with stats that was also moved into a separate swf as well as a user preferences panel. Darryl states that this was "not for memory but for initial load time."

Conclusion: "Rethink the application in order to break things out that are not used all of the time and can live completely independently."

#6: Flex has closures.

With a background in Groovy, Ruby and Lisp Darryl found it helpful to know that Flex has closures whereas Java programmers use inner classes.

"Every function has a special [scope] property that represents the environment it was in when it was defined. If a function is returned from another function then this reference to the old environment is closed over by the new function in a "closure"." ¹

Conclusion: To achieve object oriented polymorphism consider the use of closures as a good alternative to inheritance.

#7: Use Spark for lightweight components.

Flex components are not a complete or pure Model View Controller architecture like Swing. With Spark components you must attach skins and scrollers to complete the component. When comparing mx to spark components, spark is similar to Swing. "Spark pulls the extra stuff out…you can load it on if you want, but you don’t have to."

Conclusion: Spark-built Flex applications can be made lightweight and have a much simpler API when compared with Swing.

#8: Browser Cookies vs. Local Shared Objects.

Most Javascript developers are familiar with Cookies (also known as an HTTP cookie, web cookie, or browser cookie) small text files containing name/value pairs. The cookie is sent as a field in the header of the HTTP response by a web server to a web browser and then sent back unchanged by the browser each time it accesses that server. The Flash Player provides a similar mechanism in the form of the Local Shared Object. The Flash Player runtime has a specific area where it stores files that are controlled and managed by the runtime. The SharedObject class uses a static, lazy instantiation factory method called getLocal() that returns the SharedObject instance which is a proxy to the local shared object file on the client computer. The developer passes the file name reference to the getLocal method and if the file doesn’t exist the Flash Player creates and opens the file for reading and writing by the application. Shared objects can be shared by all swf files within the same domain.  Unlike cookies, shared objects are "machine centric" and browser independent, so objects stored with browser A are readable by browser B.

Conclusion: Local Shared Objects provide the Flex developer with another nice feature for authentication, storing user preferences, data persistence, etc.

#9: Use GZip with the ByteArray.

Like most Java programmers Darryl dug through the API for relevant classes. While researching the ByteArray class (The ByteArray class provides methods and properties to optimize reading, writing, and working with binary data), he discovered the opportunity to use gzip with the ByteArray classes compress and decompress methods. While many Flex developers favor using the Action Message Format (AMF) object serialization for transferring data from server to client, the ByteArray class supports zlib compression and decompression. gzip is not part of AMF, and since it's binary, it would not compress well, which is an argument for not using AMF – binary is smaller than XML or JSON text, but not as small as compressed XML/JSON.  In addition XML/JSON is cross platform and language so more portable than AMF. According to Darryl, the best alternative to AMF is HTTPService, but HTTPService is non-binary, so you can't use gzip directly, you have to also base64 encode.  This adds a size payload to the compressed data, so the typical net compression of XML/JSON using gzip and base64 encode is about 45 to 50%.  This is about the same as using AMF, but again you gain portability (and much easier testing) with XML/JSON.

Numerous websites exist that demonstrate benchmark tests using 5,000 to 100,000 or more rows of data. However the majority of web applications that I have been involved in return far fewer records per page. Darryl also reports greater compression results on the more real-world row numbers versus compression on 100,000 + rows, resulting in performance that not only exceeds AMF, but also eliminates the need for BlazeDS or LiveCycle.

Conclusion: For remoting, consider using compressed XML or JSON packettes using gzip on the server and ByteArray compress/decompress on the client.

#10: Use Local Connection class

Another helpful class is the LocalConnection class used to facilitate swf communication from browser-to-browser. This is analogous to Java’s applet to applet communication in the same domain. One use Darryl discovered for this class was to overcome the lack of multiple threads by using local connection to provide swf to swf communication, even between two independent browsers.  One application in particular loads the main swf while a pop-up windows, or a separate browser communicates with the main swf via messaging through local connection.

Conclusion: Flex applications offer a module to module communication similar to applets but extend that capability to cross/independent browsers.

¹ Caswell, Tim. Learning Javascript with Object Graphs. 30 September 2010

    <http://howtonode.org/object-graphs>

Darryl West is the Chief Technology Officer at roundpeg, a San Francisco-based software development company that focuses on dynamic, data-driven applications for the Web, Wireless, and Interactive TV space.  Our vision for the future embraces new media application architectures for the next generation Web-enabled devices.