Dzone.com / JavaLobby has published my ‘A Deep Dive into Flash Builder 4‘ article.  I wrote it over Christmas on the beta 2 release of Flash Builder, so hopefully everything is still up-to-date now that Flash Builder is finally out for production.

Give it a read and let me know if you have any feedback.

At Gorilla Logic we are proud of using our FlexMonkey tool to test the enterprise Flex applications we are building, but my curiosity has been growing at how others in the community are testing their Flex & AIR applications.

• What are you using (FlexMonkey, FlexUnit, Mercury QTP, Selenium, RIATest, FunFX, etc)?
• Have you run into major pitfalls with your Flex testing?
• Are the tools you are using allowing your team to achieve your testing goals?
• How would you rate the state of testing in Flex development?

Thanks! I look forward to hearing from you.

Like many Flex developers, I came to Flex development after a long stay in the Java world. For many years, Java and the surrounding community provided an exciting technical playground. Overall, the community gave developers like myself an amazing set of tools and an excellent group of thought leaders. Yet, we can look back now and realize how many silly ideas there were at the height of Java. I have long thought that Cairngorm borrows on some of my least favorite of these bad ideas, and now it looks like they are continuing down that road.

Now, they are attempting to expand from just a framework to some sort of Flex MVC framework think-tank. Yakov Fain’s reaction to this is priceless:

First, let me ask Java developers a question. Imagine that one day you wake up and read the following announcement, “As of today, Spring framework is the foundation for delivering of successful J2EE projects. In contrast to earlier versions, many parts apply across frameworks. So, if you are using Struts, JSF, and especially Tapestry, just forget about all these complex to pronounce names. From now on, no matter what framework you use, you are actually using Spring’.

Some of you would think, “Yakov is either out of his mind or is writing this blog sitting in one of the coffeshops in Amsterdam”. Wrong! I’m just reading an announcement about the upcoming release of the popular Adobe framework Cairngorm 3: http://opensource.adobe.com/wiki/display/cairngorm/Cairngorm+3

When I first saw Cairngorm (post), it was easy to understand what they were trying to do, as the framework is so heavily influenced by the original version of Struts and the Core J2EE Patterns. Unfortunately, Struts was barely a fit for the original problems it was attempting to solve, and are completely inappropriate for building client-side applications within a real runtime. Struts used an adaptation of the MVC pattern called MVC2/Model 2, which was created to deal with building user interface within request/response model. This model is completely at odds with building a rich Internet application.

So, obviously, I find the move to hold Cairngorm up as a template for architecting Flex applications a bit concerning. Beyond that, one of the other things in the Java community that never proved to bring fruit was the desire to standardize anything and everything, which this idea seems born out of.  I am actually foggy at best with what they are trying to accomplish, and find it completely bizarre that they would try and morph a framework into this “thing.”  Do we really need some sort of Flex specific think tank on a long established pattern?  Also, it seems very bold to attempt to group the work of so many others under their umbrella.

Is this just an attempt to keep the brand name relevant of a framework whose time has come and gone?

I haven’t been very active with writing for InfoQ.com lately. My lack of activity has been primarily due to time constraints, but has also been because I have been a bit bored with the recent RIA news. So, I was excited to get ‘back in the saddle’ with a post on the release of Flash Player 10.1 and AIR 2.0, as both releases are cause for excitement to anyone developing RIAs. The release will improve the development experience for Flex and AIR developers, but will also serve to move the ball forward in the space.

Here is my write up: http://www.infoq.com/news/2009/11/flash-10.1-and-air-2.0

Adobe has published an article that Ryan Knight and myself wrote up a few months ago. It gives a very quick overview of securing the server side of Flex applications that using Spring BlazeDS Integration, and then it introduces using our Chimp project to secure the client by doing things like role based filter of UI components. You can check out the article at: http://www.adobe.com/devnet/flex/articles/flex_enterprise_security.html

Additional Resources:

• Component for Role Based Permissions in Flex
• Flex Security Component Updates
• Project Home

Today, we (Gorilla Logic) announced the first production release of FlexMonkey, our open source Flex and AIR testing tool. We started building the tool last year because we were having a hard time finding anything that really allowed for testing Flex applications in a meaningful way. We soon found we were not the only ones, as early open source versions were met with positive feedback from the Flex community. Since that time, Gorilla has made a major investment in improving the tool and getting it ready for this release. It’s now an AIR application that greatly simplifies getting up and running with a wide range of Flex and AIR applications.

FlexMonkey Resources:

• FlexMonkey Project Page
  
• InfoQ News Posts
• DrunkOnSoftware: Stu Stern Interview
• DrunkOnSoftware: Release Party
• InfoQ: Stu Stern 2008 Interview
• FlexMonkey project blog
• InfoQ Article: FlexMonkey brings unit testing to Flex user interface developers
• Adobe Dev Center Article: Testing Flex applications with FlexMonkey 1.0

For more information on Gorilla Logic’s Flex services check out: http://www.gorillalogic.com/what.development.services.flex.html

In part one, I introduced some of the things that I believe convolute the Flex third party framework space  – primarily the influence of MVC.  The history around this pattern, particularly in the Java world, has allowed frameworks to gain mindshare that do little but help enforce the pattern.  This post is about bringing the focus back to features that make life easier on developers by allowing them to build the things that users care about faster and/or easier. That’s really what third party frameworks should aim to do.

So, moving forward by pretending that no one will disagree with that assertion, here is the overview of what would be in my perfect Flex application development framework:

• Separation of Concerns (SoC):

  In Flex development, there is a need for something outside of the core framework to help developers adhere to a separation in the application code.  In reality it is not the most difficult or interesting part of the problem, but would likely be a part of any complete third-party framework.   I personally prefer the Swiz dependency injection approach for this.  Also, there are likely a number of interesting things one could add on top of a dependency injection foundation, as we have seen with the SpringFramework in Java.

  Looking at the Swiz implementation, one can also conclude that the underlying platform needs to grow so that this can be supported in a more native way and increase the possibility that greater leverage can be gained from introducing dependency injection to Flex applications.

• Client Side Data Management (think client side Hibernate):

  RIA introduced (or re-introduced) the notion of client side data / state.  In traditional page based applications, the developer never had to consider this possibility, as all state is kept and tracked on the server.  With advanced RIA features, state is often changed on the client, but not immediately sent back to the server.  This introduces a number of challenges in managing data state between the client and the server.  Thus, there is a need for infrastructure to support data synchronization between the client and server.

  Both LiveCycle Data Service (LCDS) and Clear Toolkit include features that help the developer with this to a certain extent, but they rely on the specific server implementations.  In my perfect imaginary world, this would all be done client-side agnostic of what server is providing the data so that one could use it regardless of what technology is providing the data.

  This may even be coming in the next version of Flash Builder:

  “Of course, data-centric applications are about more than just binding operations to components. Flash Builder lets you enable client side data management for your services, allowing on-demand fetching of data for easy and efficient scrolling through large collections of data; change tracking, allowing users to undo actions, and automating the common CRUD (create, read, update, & delete) functions that usually need to be hand-coded. The results are applications that deliver users a richer experience than is possible with ordinary HTML front ends.”

• Security:

  In any enterprise application, there are security considerations at multiple levels. There are a number of methods and strategies for dealing with authentication, but not many Flex tools for addressing authorization. In the simplest form, one can break out authorization into the following categories: service/method level, data level, and filtering what each user can view on the screen. Securing services and data pretty much have to be handled on the server, but something is necessary to control what the user sees on the client.

  There are not many libraries I know of for implementing this common requirement. My current preference is my Chimp component for doing this declaratively through Flex metadata. Many just deal with this manually in each component, others monkey patch to add filtering logic on UIComponent or within View States. Ideally, features for dealing with this challenge would make it into any complete third-party framework.

• Global Event Bus:

  In Mate, basically every event is handled through the Mate event bus. Having a global event bus can invaluable in implementing a number of RIA features. Yet, handling every single event this way seems a bit odd to me. I think Flex events can be broken into four categories:

  Component Events: These are events that are only omitted and handled inside the component. Think of a component that has children and they need to communicate between one another.
  Local Events: These events are omitted by components that can be handled by within the context that the component is used.
  Global & Data Change Events: Events that any arbitrary part of the system may want to be notified of when they happen, such as the user profile has changed.

  So, in my mind, the bus is a necessary part of the perfect Flex framework, but shouldn’t be used for handling all events in the system.

Those are my top requirements for the perfect third-party Flex framework. I am sure there are a number of others that it would make sense to add to the list.

In working through this post, I concluded that there is too much focus put into third-party frameworks with Flex. The items I outlined are missing gaps that need to be met with third-party frameworks, or hopefully by the underlying platform someday, but they are not the most challenging things one will encounter when building enterprise Flex applications.

The biggest challenge for Flex applications of any scale is the quality Flash Player virtual machine. The Flash Player has to get faster, better at dealing with memory consumption, and garbage collection. Flex is a good platform for building rich Internet applications, but like any emerging technology it will have to mature to continue to gain adoptions and keep the current developers.

In the past, I have reviewed a number of the popular frameworks commonly used with Adobe Flex (Flight, Clear Toolkit, Cairngorm, PureMVC, Mate, and Swiz).  At Gorilla Logic, we love to debate the merits of each of these frameworks and the MVC pattern in general.  As an enterprise software development shop, we love architectural things and enjoy being as geeky as possible.  Yet, we continue to be a bit confused with the industry’s over infatuation with MVC and frameworks that exist simply to enforce this pattern (or similar patterns).  So, I started down the path of contemplating what would make up the perfect Flex framework…

Over the last decade, most web frameworks in enterprise development seem to just focus on the architectural piece of the puzzle, which actually provides the least value to those tasked with building real applications.  Look at the vast majority of Java frameworks that do not even attempt to provide a built-in set of components.  Also, in the Flex ecosystem, virtually all the major third party Flex frameworks seem to exist with the primary purpose of enforcing / enabling the MVC pattern, with the notable exception of the Clear Toolkit, which provides an interesting set of enterprise features.

Flex brought on a revolution because it exists first and foremost to make developers highly productive in building cool applications.  Thus, Flex is a complete platform, and is often the only framework needed for building real applications.  It provides the pieces for building within the MVC architecture and a full set of components that meet many of the requirements found in enterprise applications.  When looking at any portion of application development, engineers should only be bringing in tools that specifically satisfy the stakeholder’s functional and non-functional requirements, or address risks specifically outlined for the project.  With the strength of the Flex platform, one should not start with the assumption that they need to add in third party frameworks.

That said, Flex does have weaknesses and can be improved upon or extended in interesting and useful ways.  Also, it can be helpful to have infrastructure that supports developers in properly separating concerns within the application code.  Frankly, if the costs of adopting a third party framework to get this infrastructure is low, then there is no reason to fight against bringing in an outside solution.  Let’s look at a few of the Flex frameworks to see how they measure up in this respect:

Cairngorm: The cost of adoption and long-term ownership is too high, with the high volume of code required for implementing even the most trivial feature, for one to seriously consider this as an option.  The leverage just is not here.
Mate: Mate addresses separation of concerns by providing developers a global event bus for handling events.  This approach fits well with the real way Flex applications are built.  Although, I tend to believe that not all events are global and likely do not all need to be externalized, but this is certainly an important piece of the puzzle.  With a reasonable technical approach to managing events, the overall cost of adopting Mate is low.
Swiz: Swiz is similar to Mate in that it has a limited surface area for developers to learn.  Its primary mechanism for separating things out is the use of dependency injection.  It is fairly elegant in its syntax and easy to use.

While two of the three outlined above are low cost to adopt, they are also limited in the number of problems they solve for a Flex developer.  That’s really what this post is about – working through where the leverage is/should/could/would be in the Perfect Flex Framework.  In part two, I make an initial attempt at providing my requirements for the perfect third-party framework.

A while back I started to put together a list of cases where it might be better to avoid using Flex and/or AIR, but never posted it.  I ended up concluding that most of the issues can be addressed if Flex is a fit otherwise.  I have never been an engineer that believes that any one technology is a fit for all cases.  The other side of that coin is that I don’t believe that any platform is perfect, and you have to accept the pitfalls of whatever you choose.

Anyhow, I decided I should dust it off and put it out there.  If, for no other purpose, than to have a good reason to post the facetious list I wrote up to go with it.

Here is the list of potential issues:

1. The iPhone:
   If you are building an application that must be available on every platform, including ones that have not been created or released yet, then targeting the Flash platform is not ideal.  That said, the notion of the platform that is portable across all types of devices and form factors comes up frequently, but in most cases it is entirely unrealistic and undesirable to build real applications with this approach.  A better approach is to build applications tailored to each specific device (or at least each genre), such as a native iPhone application with features tailored to a mobile device.
   
   So, in this case the iPhone is symbolic of platforms that do not support Flash and have no published roadmap for supporting 3rd party runtimes.  If you are building an application that truly has the requirement of being the same application on the desktop and every mobile device (which certainly exist), then using Flash is a no go.  In many of these cases, standard browser technologies are the default option (HTML, CSS, and JavaScript).  RIA features can be added by using frameworks like GWT.
2. Search:
   In 2008, Adobe announced their collaboration with Google and Yahoo to make Flash content searchable.  The ability for major search engines to craw a SWF file is a nice step forward.  Yet, if you have consumer-facing content that must be searchable, then it may be best to avoid RIA features in general (not just Flex).  The search paradigm is heavily dependant on the page-based model.  It is a major challenge to build rich applications that can be entered from any direction and properly reconstitute their state.
3. Low Bandwidth Clients:
   If you are building a system that potentially services a large volume of low bandwidth users, then Flex can present some challenges.  The compiled applications are typically quite sizeable.  Flex does allow for breaking up the applications with runtime-shared-libraries (RSL’s).  With that approach, the Flex SDK still has to be downloaded (just not over-and-over).  So, trying to using Flex in this case is a bit of a stretch.
   
   AIR can actually present some real opportunities with offline clients.  For example, Parleys.com has reported that low-bandwidth clients love their application because it can download videos overnight for viewing offline.
4. Content Centric Applications: 
   There is a class of content centric applications that fit the hyperlink paradigm and should never be made into RIAs, such as Wikipedia and Craigslist.  Certainly, there are a number of applications that combine heavy content along with the need for a number of advanced RIA features.  In those cases, Flex / Flash has presented real challenges because of its limited ability to deal with large bodies of text.  Many of these limitations are being addressed with the next version of Flex and the recent release of Flash Player 10.
5. Local Device Access:
   Adobe AIR makes a compelling case for building desktop applications with web technologies, but if you are building an application that requires local device access then it is worth considering more traditional desktop platforms that offer a greater level of access to machine resources.  The community has responded to this concern with the Merapi project, but for those looking for major vendor support this is still a valid concern.

1. You prefer not to have a full featured easily extensible set of components.
2. You like spending time debugging your Ajax applications in all the different browsers and versions.
3. You are a Java developer and too afraid to shell out $250 for an IDE.
4. You believe that you can do anything you ever wanted to do in Perl.
5. You like working in a 10 year old standard (HTML 4).
6. You like the term Open Web, and believe it actually exists.
7. You hate quality applications, your clients, and yourself.

Let me know if you have any additions for either list!

In addition, to my Top 10 Changes in Flex 4 article, my colleague Justin Shacklette and I published an article on DZone titled, What’s New in Flex 4? The article gives those new to Flex a tour of the most important changes that are coming with Flex 4, including a review of the Spark component architecture.