The Future of Flash as an Application Development Platform. In My World. Part II

About a month ago, I spewed my thoughts on the future of Flash and Flex as it relates to me and my career path. Today's news from Adobe has solidified much of what I believe. If you haven't read the article, I would definitely recommend reading it before reading the rest of my blog post.

First of all, I'll start by stating that I am just a little bit angry today. What I say in this post reflects my feelings at this moment. Who knows, I could change my mind tomorrow. I'm such a fickle person. But I don't think I will.

So what am I so ticked off about? Well, the key phrase in Adobe's press release is

We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook.. Now take a second to read that again. You got it, no more Flash Player on mobile devices. Adobe has announced the death of Flash.

No longer will you see Flash content on websites on your mobile devices. Because of this, developers will not continue to develop website functionality or web applications using the Flash Platform. Executives will not want to budget for two versions.  It makes no sense to develop two versions of web application or animation assets. It's too expensive, and developers are used to working within limitations of the web. We will use HTML and make it work for our needs. Flash for websites is dead.

Leveraging AIR to compile your Flash or HTML applications to the native mobile platforms is appealing. And there is a lot of merit to the argument that this is a space where AIR could thrive. However, I am of the opinion that native apps will soon be dead. As developers become more comfortable writing applications for HTML on mobile, and as the platform matures, HTML applications will replace native. This cycle has already happened on the PC. And it will repeat itself on mobile. App stores are simply a third-party service, just like record companies. As more competition comes into this space and more HTML applications are produced, there will be less demand for the traditional native apps sold through app stores. Developers can sell through third-party app stores that facilitate HTML applications, or they can self-promote. Developers will get a bigger split of revenues, making HTML apps more profitable. With only a single code base to manage, HTML applications make much more sense for mobile and are more agile.  Thus, AIR for mobile is dead (soon).

But, you may argue, that Flash in the Enterprise still makes sense because it's primarily targeted at the desktop/browser experience for PCs. However, as companies want to leverage mobile and build applications that integrate with their PC applications, it cannot make sense to support two platforms. Companies will begin to migrate away from the LiveCycleDS, BlazeDS and Flex platforms in favor of DHTML, JavaScript, and AJAX. Duplicating components and classes for cross-platform applications does not make sense and becomes expensive to maintain two platforms. Flash Platform for Enterprise Applications is dead.

"But, Flash will still live through games! Flash is an awesome game development platform. Especially now that it has Stage 3D!" You'd think this would be true. However, there are a few major flaws with this thinking. First, game developers are excited about HTML for gaming. With Flash making little sense for mobile devices, and HTML games becoming bigger, it makes less sense to support Flash for gaming. If you want to deploy a Flash game for mobile, you will either need to package it as an AIR application, or write an HTML version. Again, this makes little sense and really limits the use cases for Flash for games.

For 3D Games, Adobe does not understand the hardcore gamer audience. For us, performance is key. Sure, Flash 3D looks great in demos. But these games are dumbed down, and have very little flair. Gamers aren't looking to move backward in technology, we are looking for the next best thing. We have old consoles and games if we want to experience old 3D technology. Console manufacturers will have much less trust in Adobe now, and getting the Flash runtime on XBox and other consoles may prove difficult. Where is the incentive for console manufacturers to include Flash games? What's the incentive for current game developers to switch to using Flash? If Flash had remained a force in the browser, this may have made sense. But without the browser, Flash gaming has no place to go. Flash for games is dead.

So, by now, you've figured out what I am saying. Flash is dead. Yea, that's pretty harsh. And a lot of my points can be hotly debated. But the sentiment seems to be rippling through the Flash community, and I am seeing the same thoughts from other long-time Flash developers. So it's not just me anymore. It's a huge community of Flash developers who feel the same way.

It makes me sad. I love Flash as a platform, and it had a huge amount of potential (it was far from perfect). But, maybe it's time has come and it's time for me to move on gracefully. I could be mad at Adobe and spew all the things I've thought about them over the last 24 hours, but I won't. Because if this is what Adobe decides they need to do to stay alive, so be it. They've been around a long time, and they've certainly been more successful than I.

However, I have worked with the platform for many years, starting with Allaire's ColdFusion in 1996, to Macromedia with Flash and Flex, all the way up to Adobe's AIR initiative. The one thing I've finally come to realize is that I can no longer stake my career on a vendor that controls the platforms I work with. My time will be better spent investing in open platforms such as HTML, open source JavaScript frameworks, and open source back end technologies like Groovy and Clojure. With open technologies, I can allow the market to drive my skillset and not a vendor. I won't have to wait months or years for bug fixes. I won't need to spend money on licensing fees. I can contribute to the platform.

I could have never foreseen Adobe ditching the Flash Platform this way, but I'll allow you all to tell me "I told you so" now.

One final note: I do have to say thank you to many folks at Adobe. You've worked hard at making a platform we all loved and made a good living with. You've helped me with some of my toughest problems, and supported my technical needs for many years. While I don't agree with your decisions on the Flash Platform, and have not for a couple of years, I still appreciate the contributions you have made to my life and the web as a whole.


The Future of Flash as an Application Development Platform. In My World.

Let me preface this article by stating that I am a pretty big fan of the Flash Platform. Over the last 5 years,  I fell in love with Flash and the Flash Platform. Heck, I've been a comanager of the NorCalFlash User Group for the last 3 years.

But lately, that love affair seems pretty one-sided. I've been pretty wed to the platform for UI development, and even switched my role from an application developer to a front-end developer. I faithfully report SDK bugs, try to promote the various frameworks and practices behind Flex and try to defend it's position as a powerful and relevant platform for application development. Flex, on the other hand, really hasn't been all that committed to me. Instead, it's been out courting the mobile platforms, and has pretty much forgotten about me. So here I sit, pining for what could have been and pondering my future.

Really, most serious Flex developers will agree that Flex 4 was an unfinished product. The Tree control, Advanced DataGrid and several other components have yet to be replaced in the framework, leaving the developers with components that have literally dozens of bugs filed against them. In my project, I am working around serious bugs that have existed for three years or more in the Tree. Other components that were built in Flex 4.5 are still incomplete.

All this would be fine, if the project were truly managed as an open source project. The community could contribute to providing new components, and Adobe could continue to focus on their mobile initiatives. However, even though Flex is touted as an open source project, the community has very little control over what makes it into the product and when.  We are once again at the mercy of Adobe dedicating resources away from the core and into emerging trends. To date, much of this has left many developers with a bad taste in their mouth, and some even have serious angst against the platform and Adobe.

To give credit to the development teams, some amazing functionality came out of both the Builder IDE and the SDK for 4.0 and 4.5 releases in terms of application development for the browser. However, when your days are spent deep in the SDK customizing every little aspect of an existing control, or building deeply complex controls from scratch, not being able to fix serious issues with the SDK that prevent you from delivering a quality product is frustrating and difficult to justifty after a long period of time.

What it's made me realize is that it's not just the Flash Platform. This occurs with EVERY platform I use that is vendor-specific and the source of that platform is controlled by the vendor. No, I'm not going to go all fanatical open source on you, but there's something to be said for being able to fix the bugs in the platform you are using WHEN YOU NEED IT. Not three years later.

Can I see myself using Flex in 4 years for my development platform? That all depends on where Adobe goes with the Flex SDK and the Flash Platform in general over the next year. Listening to the Adobe keynotes, one gets the impression that the web browser application developer is not high on their priority list for the Flash Platform right now. It's looking like I really need to be putting as much focus in the next generation UI platforms as I am the current platforms I am vested in.

Jedi Time Tracker, an Open Source AIR Time Tracking App

Time for my biannual blog post! I actually have something worthy to discuss, so I figured I would share.

NorCalFlash has, for some time, been using Ray Camden's TimeTracker app to learn about cool stuff in the Flash Platform. So far, we've learned about skinning and Swiz, and some general refactoring and project structuring techniques. Ray kindly provided us the permission to fork his project for the learning experience. I've taken the time to implement all of these practices into the project, providing it with a completely new architecture, leveraging Presentation Model and Command patterns, as well as ORM via airORM. The result is a major change that will allow us to rapidly build in new features, adds enhanced skinning, and overall extensibility. Eventually, we will tackle mobile versions of the app as well!

The app is a small time tracking app that can be used by contractors, freelancers and small businesses for tracking time. Records are stored locally in the SQLite database, and currently there is no export mechanism.

Refactoring Ray's application gave me a great opportunity to really get a feeling for the command and presentation model design patterns. I recently started working with these in a much larger project, so it was nice to see how this sped up the development of the Jedi TimeTracker application, and see how much it really made a difference in the maintanability of my code. The biggest value I can currently see is how easy it is to swap out core logic without touching views, and without having to deal with large, messy controller files. Also, one could technically implement client/server storage with JTT very easily, by adding delegates for remote services instead of or in addition to the SQLite database.

I definitely encourage you to check out the code. If you're new to Swiz, command and presentation model patterns, SQLite in AIR or airORM, it's a neat little app to learn from.

The project details can be found at The code is now in the repository, and an installer is available. You can contribute to the project by forking on GitHub and submitting pull requests! Anyone is welcome to contribute, as I initially started this project with the goal of helping people learn about Flex and AIR with an application that can be used in the real world. That being said, I'm also open to code reviews and critique!

Documentation is in the works, and members of the NorCalFlash User Group can expect more presentations using Jedi Time Tracker as the model.

Thanks again to Ray Camden for allowing us to fork his project. It's been a great learning experience!

Fix FireFox Plugin Container Crash When Debugging Flash

I'm mostly posting this for my future reference, as this is the third time I've had to fix this issue. The basics are this:

Since FireFox 3.6, Mozilla added a plugin container that runs plugins in their own process. This prevents nasty browser crashes when the plugin crashes. Overall, it was a good move on Mozilla's part.

However, for Flash and Flex developers, this can represent an issue when debugging your movie. When in debug mode and you have set a breakpoint, FireFox will think the plugin is hung if you have it paused for more than 15 seconds. When this happens, FireFox will kill the plugin container process, crashing your debug session.

The fix to this is easy. Go to about:config in your FireFox address bar. After confirming the disclaimer, you can set the dom.ipc.plugins.timeoutSecs to the value you want. A value of -1 will turn this off completely and will not timeout the plugin. The downside to this, of course, is that it will not kill plugins that are actually hung. It is the main reason I now use Chrome for my primary browser and FireFox mainly for testing.

I found this fix at

Using the Flex 4 StyleManager: Getting Style Declarations

As you may know, in Flex 4 you no longer call the StyleManager class as a singleton (StyleManager.getStyleManager()). Instead, StyleManager implements IStyleManager2 and you can get a reference to the styleManager directly, like this:

var styleManager:IStyleManager2 = FlexGlobals.topLevelApplication.styleManager;

A new gotcha I ran across today, while converting a Flex 3 project to Flex 4, was the way style declarations are referenced. Take my current issue as an example:

var styleSheet:CSSStyleDeclaration=FlexGlobals.topLevelApplication.styleManager.getStyleDeclaration("DragManager");

I worked for a while to understand why the stylesheet variable was null, every time. Then I decided to actually inspect the selectors attribute of the stylemanager and realized that the reference to the selectors has now changed! The reference must now include the full package of the class. This makes a lot more sense, considering that Spark added a whole set of new classes with the same name. Now I changed my code to the following:

var styleSheet:CSSStyleDeclaration=FlexGlobals.topLevelApplication.styleManager.getStyleDeclaration("mx.managers.DragManager");

Perfect! Now my style delcaration was being set as I expected. I hope this tip helps you.