Last year in the thick of web2project development, we realized something obvious: The vast majority of people don’t need the full system, they just need a way to see their information – and just their information – in a useful way. Towards that goal, we started shopping around for options to simplify and an Adobe AIR app quickly became a leading candidate. Fast forward a few months and I finally had the time to try out Flash Builder 4.

For context: Prior to starting this exercise, I had zero experience in Flash, Flex, and everything similar. I’ve caught a few of Ed Finkler’s presentations on RIA but I’m definitely not a desktop developer.

First, getting setup was ridiculously easy. I downloaded the 60 day trial of Flash Builder 4 and registered to get a full license as a user group member. After a quick activation, I was setup on Windows 7 in a matter of minutes. Of course, that’s where the first oddity creeps in. I’ve used Eclipse for 7 years on both Windows XP and Ubuntu but Flash Builder 4 only works on Windows. It seems like they’re missing one of the best parts of Eclipse as a platform. Regardless, getting started on my first project was identical to starting any Eclipse project.

Next, I had to choose where to start. Since we use iCal for broadcasting Task/Todo information, it was the obvious and easiest place to start. I envisioned a simple list of tasks, a textarea to add a comment, and finally a timer to create a complete tasklog. To do this one, I switched into Design Mode and browsed the components. If you’ve ever worked in a visual editor – such as Dreamweaver or with Visual Basic – the options and configuration is pretty much what you’d expect. You get standard components such as TextArea and DateChooser that you’d expect, but you also get a ProgressBar, ColorPicker, and RichEditableText box. While I won’t use them this time around, it opens some options for later.

Of course, this is where I learned a useful little trick. Unlike PHP where you might echo (or print_r) your value, Flex doesn’t work the same way. You can’t just tell it to echo things without errors and other things appearing. Therefore, I added a TextArea named txtJunk and added this:

txtJunk.text += “my debug message \n”;

where I wanted to know what was happening. There are certainly more advanced and efficient ways of debugging but we’ll cover that another time.

Next, before I can log any time against a Task, I need to get the list of Tasks. The Data Connection Wizard – covered in depth by Cal – seemed like the best place to start. I started up the Wizard, selected HTTPService, configured the URL, and everything worked beautifully and everyone lived happily ever after.

No wait, it didn’t.

If you look closely at the HTTPService in the Wizard, you’ll see that it’s specifically for XML or JSON. Since iCal is a glorified text file, it doesn’t fit into either of these and it failed spectacularly. On the positive side, since the Wizard immediately attempts to validate the data returned, I found out pretty quickly. After a few failed trials to do some form of useful validation, I realized the solution was much simpler than I thought. By setting String as the return type, the DCW allows for literally anything to come back. While this worked, I should obviously look into some JSON or XML structure to take advantage of the validation.

Next, I had to do something with this long iCal string. For this, I dropped out of Design Mode and went directly to the source. At first glance the source looked a little odd compared to PHP. The syntax itself is OO and the naming is consistent and mostly predictable, but it’s the little things that make all the difference. ActionScript is strongly typed so at initialization you have to declare a variable’s datatype. At first pass, this seemed excessive and a little annoying to have to match return types, but there is a huge benefit gained as a result: code completion. And this is one of the places Flex Builder shines. Not only does it have the functions themselves but it includes some basic documentation, the return types, and related details that you’d expect. I had forgotten how helpful code completion is when you’re not familiar with the language.

From here, it became a simple matter of parsing the big string into a series of smaller strings. First, I split it into individual event listings, then into the individual lines of information for each event. Coming from a PHP background, it was ridiculously simple. Granted, some of the syntax and specific method names were a little obtuse at first, but code completion got me 95% of the way with almost no effort.

Finally, I had to wire the whole thing together and this is another place where Flex development is completely different than PHP development. Flex doesn’t use the request/response model unless it’s interacting with external sites or services. Instead, Flex – like all desktop development – is event-driven.

It’s a shift to wrap your mind around writing code triggered from and waiting for events as opposed to responding to requests. Even more odd was the sense that I had lost control over the flow of the application. In PHP development, the code executes from top to bottom, so it’s easy to know what has executed previously and what will happen next. In Event-driven Programming, the Events can happen independent of one another. For example, you can type (an event) in your browser’s address bar even while a site is loading (another event). These events come from all over the place, whether its from a user (typing or selecting an element), a Response from a previous Request, a notification from another Event, or a variety of other things. Therefore, your components have to execute (or fire) independent of one another.

That said, the visual editor handles the basics for you. In Design Mode, right-click on any element and you can interact with the relevant handlers for things like creationComplete, click, change, and a select. If you’re familiar with Javascript development, you’ll notice there parallel with onLoad, onClick, onChange, and similar events.

At present, this code doesn’t do much of value but the next phases will be more interesting and complex. I have to work through what to cache locally and since assigned tasks change frequently, it has to be checked frequently. More importantly, for this client to be useful, it should be able to work offline and not require connectivity immediately at startup. Therefore, we’ll need persistent storage like SQLite and a way to synchronize with the central server.

If you’d like to follow the continuing adventures, the entire source will be available here: http://github.com/caseysoftware/web2project-air and I’ll continue documenting the progress in this space.

Disclosure: Through Blue Parabola, LLC, I’m working with Adobe and a number of their tools and technologies to see what I might be able to use where. I’m under no obligation to be positive or negative with respect to any particular product or person.