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.

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

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.

When googling for solutions to any number of Flex challenges, I commonly find posts that include monkey patching as part of the solution.  Monkey patching is basically replacing a Flex class with your own.  For example, if you want to change something in UIComponent you can create a mx.core.UIComponent in your project, and the Flex compiler will use your class instead of the frameworks class.  So, basically you take the source code from the framework and modify it to meet your needs.

While it is interesting to have this option, its seems like a horrific idea to actually do this on a real enterprise project.  With this sort of solution upgrading the Flex SDK will be painful at best, and impossible at worst.  I think the only time I would ever do this is to get a bug fix into my code before it is available in a release, with the intent to throw away my class once the next release of the SDK is available.

From all the posts out there, it does appear this is a common thing to do in the Flex community.  So, am I missing something here, or is this as evil of an approach as it seems?

I just finished a write up for InfoQ on the Flight Framework. Flight compares themselves to Cairngorm, without all the “boiler-plate” code.  The association with Cairngorm is a turn off for me to seriously consider using Flight, as I still don’t understand what value Cairngorm provides (old post 1 & 2).  That doesn’t mean I don’t believe that Flight may have value, but in learning about the framework there seem to be the typical assumption that everyone is out there looking for the perfect MVC solution (old post 3).

I lived through the countless MVC frameworks in Java.  So, I don’t believe it is naive when I ask, what is so great about MVC anyway?  We all love to work in code where the separation of concerns (SoC) have been adhered to, but do I need MVC to accomplish this in Flex?  I don’t believe I do…

Anyway, back to Flight, they did allude to some additional features in the framework, like history management.   Although that specific feature is available in Flex 3, there maybe other features that make it useful.  The documentation is pretty slim right now – we will see what else is there when the docs evolve.  For me, I guess I want to see frameworks that do more than attempt to enforce a pattern.

Last month, We posted a Drunk On Software video interview with Anvil project founder, Ryan Knight.  This month Ryan shared more about the project in an InfoQ.com email interview I just posted.  Check it out and let Ryan know what you would like to see in the next release of Anvil.

It has been fun to see the open source model working with FlexMonkey.  Stu put our testing tool out there for the world only a month or two ago, and we are already seeing significant contributions.  The latest contribution is from Marvin Froeder (VELO), who has helped us update the framework to work with Flex-mojos (the popular build tool).

I have been hearing really good things about Mate for a few months now.  I have been rebelling against dragging additional frameworks into Flex just for MVC for a while now (Flex and MVC /  Cairngorm).  I finally got a chance to spend some time coding with Mate on a flight back from San Fransico this weekend.  I think it looks promising.  I am still not sure the leverage is enormous, but the cost seems low.  It appears to provide a reasonable structure for Separation of Concerns and managing events, without requiring much additional code.  Hopefully, I will have some more time to do something more complex soon with it, but I think it may be the type of framework I have been wanting.