I’m currently wrapping up three different fairly large AIR applications developed in different ways. In this blog post I hope to describe the methods used in them, what worked well, and what didn’t work so well. Hopefully this will be useful to others starting up projects in the near future.
I’m going to call these “large” applications since they go a lot deeper than a simple toy or small experience site that most Flex apps seem to be. Your definition of “large” may differ. These are full blown desktop applications, not a web-app ported to the desktop or a simple desktop app to augment a web-app. All three were planned on being desktop apps from the start. It’s not a common target audience for AIR, but I believe in the platform for this use.
A description of the projects
First, a quick rundown of the apps.
AgileAgenda
This was my entry for the Adobe AIR Derby so the beginnings were a rapid no-holds barred get-something-out-the-door effort. There was no good planning that went into this, and no framework used. This is one of my solo projects.
It’s since gone through several major UI revisions, with some parts of the application completly changing how they work or look several times over.
It’s a project scheduling application focusing on allowing users to create a schedule by entering tasks, priorities, and durations while letting the software calculate start/end dates. Besides that it’s got some nifty sharing functionality, a PDF export, and a few different ways to look at your data. I’ve been selling it commercially for while and not doing too bad, take a look and let me know what you think. I’m always interested in feedback.
AgileTracker
AgileAgenda was doing pretty good, and a time-tracking application to work with it seemed like the next logical step. I had been looking around and found Parsley and was fairly impressed so I decided to give it a shot. This is also one of my solo projects.
The AgileTracker allows you to subscribe to a schedule in AgileAgenda to get your list of tasks. Then you can use the built in timer, or manually enter time to keep track of how long you spend on various tasks. Someday, it’ll have full read/write capabilities to AgileAgenda for a full round trip exchanging of data.
TimeLiner XE
This is probably where I learned the most. I acted as the project lead on a 3-5 engineer team that grew or shrunk throughout the process depending on other needs. It was developed in a commercial setting (at Tom Snyder Productions, my day-job, which I’ve been very fortunate to find) We’ve got a formal art, engineering, and QA team over there.
TimeLiner XE is the 6th major revision of one of the best selling desktop applications my employer publishes. Previous versions were written in C++ with a proprietary cross platform layer. It was a big gamble betting on Flex/AIR instead of sticking with C++, but we’ve been pretty happy so far. The built in WebKit HTML renderer made one of our features (a web based research mode) a “killer feature” and doing that in a cross platform way in C++ would have been a huge investment compared to what we accomplished in AIR fairly simply.
You can see a pre-recorded webcast seminar at the TimeLinerXE web page. http://www.tomsnyder.com/timelinerxe/
If you jump to about the 3 minute mark, that’s where they start actually showing off the software.
Quick summary…
| App Name |
Info |
Framework |
| Agile Agenda |
~ 25,000 Lines of Code
1 Developer
First released on AIR Beta 1 |
None
(Developed Quickly & AdHoc for the Adobe AIR Derby) |
| Agile Tracker |
~ 8,000 Lines of Code
1 Developer
First released on AIR 1.0 |
Parsley MVC + IoC |
| TimeLiner XE
|
~ 100,000 Lines of Code
3-5 Developers
1 Designer
Several QA engineers
Not yet released |
Cairngorm |
LoC numbers above are just to give an idea of the scope of the project and does not include code from libraries (either internally developed or open source). There’s a similar coding style in all three, so it’s purely meant to give an idea of the relative size of the projects. The AgileTracker is larger than listed, because it reused a bunch of code from AgileAgenda which isn’t reflected in those numbers.
Things we did right
QA / Bug Tracking
Tom Snyder has a first class QA team. Having them involved early in the project helped direct it to be a project that was easier to test, and of higher quality than might otherwise have been possible. Having a dedicated and passionate QA team is the single best thing that can happen to any software project. We’re using Bugzilla for tracking which works pretty well, but will be moving to HP’s Quality Center in the near future (which I hope works even better!)
On the AgileAgenda side of things, this wasn’t so great. I’m looking to rectify that in the near future, but finding the right person (at the right price) is difficult. Since it’s a simple 1-person project I’ve been using TaskPaper to keep track of my list of bugs, my list of future features, and my general todo list. I’m currently looking for a good end-user bug reporting system, but haven’t found anything that really fits my needs yet.
Open Source!
All three applications use some very good open source projects. Without these, the development would have taken a lot longer, and been a lot more labor intensive. Two of the more important libraries were…
Object Handles (Open Source)
ObjectHandles is a library I wrote a while back that makes it easy to create interfaces that let the user drag and resize components around the screen. It’s amazing how having a library like that can make you add that type of functionality into places where you may not have wanted to spend the time implementing without it. Take a look at AgileAgenda’s Light Table. The Light Table is one of the features I get the most positive feedback about. It took an afternoon to implement with this libray. Without it, it would likely have taken a week and would have never gone into the 1.0 version. Almost the entire TimeLiner interface was build with this library.
AlivePDF (Open Source)
The printing in AgileAgenda is completly done with AlivePDF. This lets the usercreate a PDF to print, send to a colleague, post on a website, etc. It’s amazing easy to use and creates high quality PDF’s. (Yeah, AgileAgenda doesn’t deal with margins well right now, that’s my fault and not AlivePDF’s).
Parsley (Open Source)
Parsley is great, unfortunately it was only used in the AgileTracker. Using an IoC container for applications like these makes perfect sense, and the MVC infrastructure it provides makes it super easy to stick to the MVC model without being tempted to just have the UI muck around with your data. The only frustrating thing I’ve found with it, is that it’s harder to debug a parsley based application when problems occur.
When you’re using Java/Spring on the server side, it’s also helpful to use a client side framework where you can think in the same way.
Perforce
We use Perforce for the version control system for all the mentioned projects. It rocks, hardcore. Even for my single-developer projects I find myself more organized with less of chance for losing something important because of it. Subversion, CVS, whatever other version control system you use is fine too, but just make sure to use one!
ANT
All three projects can be fully built through a single ANT command. The release builds of all the projects are made in this way. It doesn’t matter if a developer updates his build environment, or if your FlexBuilder license gets funky, you can always make a known-good build through a simple single command line.
For AgileAgenda we actually end up making several builds (ready why), plus update the download page all automatically from the build script. No more creating a release version from FlexBuilder, copying it to the web directory, using FTP to transfer it and editing a file to update the version on the website!
If you’re making release builds of your software from within Flex Builder, you really are missing out and wasting a lot of time.
CruiseControl (Continuos integration)
For TimeLiner we’re automatically running builds through CruiseControl after every single code checkin. When you have between 3 and 5 developers, it’s very easy to submit code that builds for you but nobody else. By using CruiseControl, whoever submits a change to perforce like that gets an email telling them within 10 minutes. No more yelling “Who forgot to add SomeWeirdClass.as to version control?”
For a while we had it running our unit tests as well, but unfortunately we don’t anymore (see below).
We didn’t try to hire Flex developers
Well, we did try, and then gave up. Flex Developers are hard to find. Really hard. Many people out there claiming to be a Flex Developer are really just coders and not software engineers. Going into TimeLiner there was Me and one contractor that knew flex well. Everyone else was either completely new to ActionScript or only had Flash experience. But every single one of our developers was a good engineer. Having smart people who can get things done (certainly not my original idea) was the best way to go, especially given the duration of the project. Teaching an engineer flex is easy compared with teaching a flex coder to be a flex engineer.
I think a big part of the problem here (besides Flex being so new) is Adobe doesn’t really focus on the developer market all that much. A lot of (non-flash/flex) developers out there still see Flash simply as a way to make annoying advertisements where you punch a monkey or watch a video of a kid setting himself on fire. Adobe is really great to their developers, but I really wish they would go after those developers letting them know what most of us know, that Actionscript is a full featured application development language, and Flex provides a great set of components. When do we get to see Kevin Lynch on stage shouting “DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS“? Of course, I hope they never lose their designer focus, it’s what sets the platform apart.
Design / Artwork
Having a great design team on TimeLiner really made the project. It looks amazing. Unfortunately, I didn’t have the budget for that in AgileAgenda. I ended up getting my design from three main sources.
1) An eager student in France was willing to do some of this for me. Unfortunately as time went one his priorities changed and it was hard keeping that relationship going. (You rock Olivier)
2) I bought a pack of icons from IconShock. I don’t know how I lived without these. Now, whenever I’m creating something new I can look through that library of images and pop on an icon that really spruces things up and maintains a consistent feel throughout the app. Just imagine this, without any icons, booooring.
3) And lastly, I needed a logo. For $150 I ran a contest on a logo design website and got my final design. You can’t beat that price, and it’s better than anything I could have done myself.
It may not win any awards, but it looks pleasing enough and the process of creating it didn’t distract me too much from the development of the software.
Things we did wrong
Plan for modules
The biggest thing I learned is to plan for modules in large applications from the start. At one point during the TimeLiner development we were approaching compile times of 2-3 minutes. Making a 1-line change and then waiting for several minutes kills productivity. We abstracted all of our styles, graphics, and sounds into modules and got that back down to a semi-reasonable compile time, but I think if we had properly planned for modules and broke the application up in a logical manner it would have been even better.
Printing (AlivePDF for screen grabs)
If you’ve been reading along, you might have noticed AlivePDF above and be suprised to see it listed here as well. Well, it’s not a problem with the library, but a problem with how we chose to use it in TimeLiner. We made the mistake of thinking we could take an on screen visual timeline, grab a screen scrape, and dump it into a PDF for all of the benefits mentioned above. Turns out that the antialiasing of text looks horrible after you print one of these out. It’s a problem with the difference in resolution from screen to print. We wrote a lot of printing code targetted at AlivePDF and it turned out not to be high enough quality when we put those PDF’s on paper. Luckily, at least 80% of that code was re-used to create a printing system using the normal Flash/Flex printing API. So in TimeLiner, you can now use a file->export command to make a PDF using AlivePDF to get a PDF that looks great until you print it (and then it just looks “ok”) or you can use the File->Print command to get a great looking printout. This lets people share it either in paper or digitally with decent results in both.
Using AlivePDF’s methods to add text does not have this type of problem.
Unit Tests
For a while we were running our unit tests as a part of the TimeLiner build, but AIR 1.0 broke our unit tests and we never found the time to go back and fix them. I wish we had, because it would have prevented some bugs from going through the QA/Fix/Verify process and saved us some time.
Data Binding directly to the model
TimeLiner and AgileAgenda’s interface both used to bind directly to the data model. That’s fine for smaller applications, but for things of this complexity they break down. Try using AgileAgenda sometime, the interface feels sluggish. That’s because I haven’t done anything about it over there yet. But we did do something about it in TimeLiner. Instead of binding the user interface to the data model, we created intermediary “model adapters”. These adapters act as delegates to the model and only pass on the events that cause binding updates when they’re active. This makes it easy to “turn off” a big part of the UI in on central place. It also makes it easy to present the model data in different formats so we can do things like summarize a table of data for a “totals” label right inside these. Using these adapters, it’s easy to turn on or off access to the model to various parts of the UI without complicated logic in the UI iteself. The work we did covered about half the binding that was in place and makes a noticeable difference. Given more time, I’d convert the entire app over to data model adapters.
Cairngorm
Cairngorm is a great framework. It’s a good implementation of the command pattern and does define a decent set of methodologies of doing things. It suited TimeLiner well and hasn’t given us many problems. It has certainly solved far more problems than it has caused. The only reason I place it in the “things done wrong” category is I believe Parsley to be superior, I wish we had used it for all three projects. Parsley solved all the problems that Cairngorm solved for us, but it also managed to solve a few more.
Also, Cairngorm needs an easier name to say and spell 
Not using AIR distribution
For business reasons, we’re not using the AIR distribution model for TimeLiner. It’s a shame that we have to ship a physical CD to our customers since keeping a .air file on a website somewhere is so much more cost effective. Making an installer, pressing CD’s, printing a user’s guide, and shipping all of that is just a pain and keeps the software away from the end user for an extra few weeks after the end of development. Plus, it’s a whole lot harder to get program udpates out there. (AgileAgenda does not suffer from this problem)
Problems with the tools
Disclaimer… I like Flex Builder. It works well and gets the job done. With Thermo focusing on the designer crowd and Flex Builder reportedly re-focusing on the developer, I think most of these problems will be worked out in future versions.
Eclipse/Flex Builder doesn’t do the “Run in background” thing very well and will constantly re-pop that compile progress dialog up. Before going the module route, this absolutely killed TimeLiner. Afterwards, it was still a constant annoyance. Even with modules we might be interrupted, at seemingly random times, by the “Building workspace” dialog for 5-25 seconds. If the little “stop” button would always work instantly, this wouldn’t be a problem. But it doesn’t. Turning off automatic compiling can help, but then you don’t get all the functionality of FlexBuilder. When FDT gets decent MXML supprt, I’m going to seriously look into it. In the past I’ve used it on AS2 projects and problems like this simply didn’t happen over there.
Coming from an Eclipse/JDT and an Eclipse/FDT world, FlexBuilder is missing a lot of functionality. Snippets, decent code generation, and refactoring like “extract method” or “create delegate” would be very helpful. From what I hear, with Thermo coming out, the FlexBuilder team will be focusing on developer-centric ideas like this which will be great. If Adobe just made it easier for people to extend FlexBuilder, I’m sure those things would get written by the developer community.
The Flex compiler will sometimes, seemingly randomly, start throwing unknown variable errors in code completely unrelated to what we’re working on. Doing a clean build doesn’t fix it. Going in, editing the file where the “error” is found by deleting and re typing a character, and letting it rebuild seems to be the only solution. I think this has to do with the Flex compile cache, but I haven’t had time to investigate it further. It happens at least once a day to me.
Much of the development was done with Beta versions of AIR and Flex Builder. I underestimated the impact that would have on development. Beta versions are buggy, and they do suck time out of your schedule. Little things like installing new versions every few weeks, or crashing more often add up. But I do think the benefit of using those vs. using the older stuff was worth it this time around. Unfortunately, I don’t know if that would always be the case, and I don’t know how to judge that impact before a project starts. I guess I’ll just tend to opt for released versions unless the project requires something in a beta version.
The future
I’ll be moving AgileAgenda over to Parsley bit by bit. Thinking about that framework, it should be pretty easy to move smaller pieces over that I might be working on without disrupting the bigger picture. AgileAgenda will most likely be in light continuous development for years to come.
The AgileTracker will continue on as-is. I’m very happy with how it works and flushing out the rest of the features and functionality is “all” that’s left
TimeLiner will stay a Cairngorm application. Due to the way commercial educational software companies work it will probably go through cycles of being untouched for months, and then heavy development for a new release. Those months of quiet and then bursts of activity will give us further insight on how easy it is to maintain a Cairngorm app. Someday, I hope we do a web version of the software.
Conclusion
Overall, I believe Flex/AIR is the way to go for cross platform applications like these. I’ve done both Java and C++/QT cross platform apps, and neither of those was as easy to get working consistently accross platforms as AIR and Flex.
So, if I were to start a new project today I’d probably go with the Parsley MVC + IoC approach. I found it to be easy to work in and it solved more of my problems than the Cairngorm approach.
If I could find experienced Flex engineers, I’d make my team out of them, but it wouldn’t be a must-have since I’m convinced any smart software engineer can pick this stuff up.
I’ll be using the data model adapter “pattern” instead of direct binding for now on for anything except the most trivial of applications. I’ll write a full blog post really explaining this sometime.
Modules will be planned from the start. I think a lot more in all three applications could have been split into modules without any additional labor if we had just kept it in our minds from the beginning.
Disclaimer - I’m an employee of Tom Snyder Productions. Anything said in this blog post should be considered solely my own opinion, and may not be representative of my employer.
