I just ran into an interesting issue with ObjectUtil and its handy Copy function.  After performing a copy, I was attempting to cast the resulting object and the overall result was null:

oldField = new Field();
newField = ObjectUtil.copy(oldField) as Field;
//newField is null 

Thankfully, a quick trip to Google helped me find the solution 

I added this to my Field class:

[RemoteClass(alias="com.eastfacesoftware.Field")]
public class Field {...}

and I was a step further.  My last hurdle was using the Copy function on subclasses of Field.  As you might guess, you need to define the RemoteClass metadata on every class that you intend to copy. After I did this, ObjectUtil was again on my list of favorite ActionScript classes.

The reason?  ObjectUtil.Copy() uses AMF to serialize and de-serialize the original object to create the copy.  If AMF doesn’t have specific knowledge of your class, it will not return an object that will cast properly.

Thanks to Darron Schall for this helpful tip.

Now that I have my little AIR application, I need to follow through to the point where it can be added to my client’s internal toolset.

Here’s a rough shot at how I’ll do that (this is really for my client only but feel free to play along):

• Enable Flex-side login into the application via SOAP (if necessary)
• Add an image browser to allow for easy selection of thumbnail and detail image
• Take the key pieces of activity data and create an activity with an exsiting web service call
• Shoot the user over to the Activity Wizard. (Interesting hurdle here… how do I send the user from my AIR app to a URL inside of a browser?)
• Reset the Scaper to allow for the creation of the next activity

Once that is in place, the following features can be added

• Selection by the user of additional activity fields to scrape off the page
• Full integration of the Activity Wizard. So the user doesn’t actually exit the AIR app, the AIR app contains the ‘Wiz
• Addition of some versioning for the AIR utility (would allow for easy software updaets). This is more as a proof-of-concept since this tool is an internal tool.

Have you ever wanted to buy something that you knew you’d have to find a use for it after you got it home?

Well, the iPod is an awesome example of that. In ‘02, I knew that I really wanted one but couldn’t really explain its value to my wife. Well, thankfully she didn’t need to hear about its value and surprised me with a 10GB iPod right before a week-long vacation.

I quickly found a use for it (albeit after the fact). Pretty much every day since I’ve had my iPod nearby to entertain/distract/focus me during work hours… Clearly millions of other people have seen the value in the technology since.

Adobe’s AIR is kind of the same way for me. I know it’s great and it’s going to be very relevant in the next 5 years, but I haven’t proved it with anything tangible. I actually am a lot further down the path of understanding its value than I was when an iPod was handed to me, but I have yet had the opportunity to prove it with an AIR project of my own.

First, the value. Flex itself brings the best way to bulid browser-based RIAs. But AIR allows Flex to see its full potential as Flex on AIR is now a way to build fully-featured, client-side applications. AIR can also allow for the deployment of HTML/Ajax based apps, but I prefer Flex.

Here’s what AIR gives you that Flex does not:

• The ability to take a Flex application offline. AIR even provides APIs to easily determine the state of connectivity.
• Access to client-side resources like storage and devices. You can upload files using a browser-based Flex app, but you can’t write files and read directory structures, etc.
• Closer integration of Flex and HTML. The browser is no longer a container, it can become a component within your Flex application. This gives you full access to the DOM. Also, not possible in a standard web browser

So, I am a huge fan of what AIR can do and an even bigger fan of where it can go. But all of my ideas for an AIR application are either super lame (like the majority of my ideas) or way too complex to bite off in an hour-long session of let’s-see-what-fun-can-be-had-with-AIR.

But then, finally, a managable idea was handed to me. I was on-site last Wednesday working with a client who wanted to use Dapper to scrape a bunch of data off of existing web pages and pump it into their inventory system. Having never seen Dapper, and having built several screen scrapers from scratch, I really liked the idea. And I still think the idea has merit, but we decided that with the low number of screens to scrape and the eventual end-users of this tool, Dapper may not be the way to go.

The guy I was working with then had a really cool idea revolving around Google Notebook’s FireFox plug-in. And we were getting even closer to our usability goal.

Finally, it hit me that an Flex/AIR application might do the trick. The UI would consist of empty fields on the left-hand side and then a large HTML container on the right. The user could highlight the content on the web page and click a button in the Flex app which would pull the selected HTML (using JavaScript) into the Flex fields.

My proof of concept (an HTML container, a button and an alert box that displayed the selected text) took 15 minutes to build. That’s from no AIR project to a distributable AIR file. It was also a pretty useless application.

But when I resumed the next day, it took only 45 more minutes to present a usable interface including a feature that pulled all of the images out of the HTML page for selection inside of the Flex app.

That illustrates the third feature of AIR, tight Flex-HTML integration that’s easy to leverage. And it also demonstrates the fourth feature of AIR… it’s really, really easy to build an AIR application. 1 Flex Application .SWF file + 1 .xml AIR descriptor file = all you need.

Now, on to taking this Scraper utility to the next level…

In building a PositiveWare Project Tree for the Time Card, I found some great articles/posts on how to keep the open nodes of a tree after a dataProvider change:

 http://lordbron.wordpress.com/2006/07/28/flex-20-reopening-a-tree-after-updating-the-dataprovider/

http://www.adobe.com/devnet/flex/quickstart/working_with_tree/

 I tried out the solution and it worked very well for me… until the Time Card was released into the wild.

 First of all, here’s the setup.  It’s a Tree, inside of a HDividiedBox which is all popped up in a TitleWindow.  The user navigates through the Project Tree, finding the right Project or Task to track time against, enters the data and clicks save.

Now, the user wants to add a second entry and pops up the Add Time Card Entry window. 

 Two issues crept up:

• A tree that initially is small enough to be completely visible, is expanded outside of the visible space,  and scroll bars appear.  The next time the tree is popped-up, the scroll bars don’t appear until a new node is opened or closed
• A tree that is, when fully collapsed, larger than the visible space, will lose portions of the tree when popped up the second time.  For example, in a tree of states and their cities,  Ohio through Wyoming may not show up the second time… until you open, shut and scroll around a bit.

I wrangled with this oddity for an hour or so and right before packing it in for the night, I had the what-the-heck-lets-try-one-more-thing idea.

 Instead of:

SampleTree.openItems = open;

 I’m iterating through the items in open and calling expand:

if (open != null) { 

     for each(var obj : Object in open) {        

          expandItem(obj, true);   

       }

 }