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.

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 http://tjdownes.github.com/Jedi-TimeTracker/. 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!