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.
