Just had a couple hours of frustration trying to determine the reason Flash Builder 4 beta 2 suddenly refused to launch. The splash screen would just sit there for, well, beyond my patience. That accounts for a few minutes, incidentally. Eventually, I discovered the issue. Seems my SwcCache folder had grown to… get this… 138GB. Ouch. It was also 65% fragmented. Perhaps you should check yours to see if it’s grown like kudzu. You can usually find it here:
C:\Users\whoEverYouAre\Adobe Flash Builder Beta 2\.metadata\.plugins\com.adobe.flexbuilder.codemodel

The above path may be different, depending on your workspace. At any rate, I’m back up and running by removing the contents of this file. Flash Builder launched without a hiccup and I ran a clean on all my projects. Perhaps posting this will save someone out there some hair pulling.

Workload has been pretty heavy over at SuperNova, where I play the role of Sr. Programmer. Looking ahead, it just gets heavier. While that’s excellent news, it does also mean that we are looking for another developer. Perhaps you, dear reader, fit the bill. Here’s what we’re looking for:

Contract to hire position. Must be able to work on site at Bridgewater, NJ office.
Candidate must be a rock-star actionscript developer with gobs of Adobe Flex framework and Adobe AIR experience. This obviously insists expert knowledge of OOP practices, experience with popular design patterns such as MVC, keen knowledge of component lifecycle, and the like.
As you’d expect, we typically work in Flex Builder 3 and will be making the move to Flash Builder 4 upon its release. It is assumed all candidates are intimate with Flex Builder.
Familiarity with Janus and/or Zinc is a plus.
Because of the nature of our workflow, any design experience is also a plus.

The people are great, the projects are interesting, and good work is very much noticed and respected. Developers are often involved from concept to delivery. You’re not gonna be just another code monkey.

If this seems a fit for you, dear reader, then shoot me an email with yer resume and any sample work at dhamiter(at)supernovainc(dot)com.

This post, the 2nd of many, is about how to run more than one instance of an AIR app at the same time. Here is the only relevant adobe bug I could find on the matter, and it’s been closed saying the request has been forwarded to the AIR team. That was over a year and a half ago. When the user tries opening an AIR app that is already open, it sends an invoke event to the one already running and blocks additional ones from opening. Because of how this appears to work, it stands to reason that Adobe intends this behavior. Luckily, you can still run multiple instances with a bit of effort… sort of. I say sort of, because you actually have to make a small change to any additional instance to run it… so, technically, you might say it’s not really another instance.

In the installation directory of the AIR app is a file called “application.xml”. Yep, it’s essentially a copy of the file automatically created when starting a new AIR app. On windows, it’s at:
“…yourInstallDirectory/META-INF/AIR/application.xml”
On Mac, you can open the .app package and find it at:
“…yourInstallDirectory/Contents/Resources/META-INF/AIR/application.xml”

One of the nodes in this file is the id node. This appears to be how AIR recognizes if an AIR app is unique or if the same one is already running. Change the id then save the file, and you can launch another one. For my purposes, the user exports a new app which runs a presentation they’ve built. In reality, the player app they export is the same app they used to build the presentation but in a different state. To export, I am copying the air app, it’s dependent files, and some additional resources to where ever the user wishes to export. Once copied, I modify application.xml as described above, so as to allow the user to launch the export without first closing the builder application (which, again, are the same app).

I hope, as with all these workarounds, that you 1st go through why Adobe decided to lock this down in the first place and determine if you really should be working around it. The last thing I want is for these techniques to be abused, both tainting AIR and forcing Adobe to implement more restrictions. I consider my need to have been a corner case, but don’t intend to use this workaround very often, if at all, in future projects.

Disclaimer over. I hope this both made sense and helps someone out there. Feel free to drop a comment if something is unclear, wrong, or if you feel code samples or anything are needed in addition.

This post, the 1st of many, concerns differences in drag and drop functionality in AIR versus just Flex (in a browser or other wrapper). One of a few bug reports associated with these differences can be found here. If this has affected you, please vote on it.

The core issue from my perspective was that components which already support drag and drop end up using the operating systems native drag and drop behavior. So say you built 2 tile lists and wanted to drag tiles from one to the other. In Flex, you get a preview of the tile while it’s being dragged and indicator icons without having to write much code at all. Once that same bit is run in AIR, you lose the Flex indicator icons in favor of the native system’s indicators and lose the tile preview unless you create your own drag proxy. If you want to specify the alpha for a drag proxy, you’re now out of luck. Also, if you have written your own methods for dragOver and/or dragEnter, you’ll find some inconsistancies with the behavior here too. I was most annoyed to find that the DragManager.showFeedback method wasn’t working correctly. By my estimate, in AIR this call only works the first time and subsequent calls are ignored. That’s clearly bad news if you have complicated business rules attempting to control regions which allow for drag-drop and others which do not. I consider this a pretty big bug.

So what we really need is a way to tell AIR that we’d like to use DragManager or that we’d like to use NativeDragManager as opposed to being stuck with native drag functionality. I’m sure if we all hold our breath long enough, this will all be addressed in a future sdk release. However, waiting sucks and is often not an option. Ok then, so maybe we can subclass or monkeypatch something, but what… where does the logic that should make the distinction go? Take a look at mx.managers.SystemManager. There’s a mx_internal method in there called docFrameHandler. It’s basically forcing NativeDragManager down your throat when you make an AIR app. See this line:

dragManagerClass = Class(getDefinitionByName("mx.managers::NativeDragManagerImpl"));

Change it to read the following:

dragManagerClass = Class(getDefinitionByName("mx.managers::NativeDragManagerImpl"));

This will force it to stop using the native drag and drop, thus problem solved… sort of. What if you have a need to use both drag and drop and natvie drag and drop. Well, that’s a tad more complicated.

Rather than going into what all needs to be changed, I’ll instead make a very happy announcement. Andrew Westberg of Flex Junk has been all over this one for a while. I was digging through the latest Flex sdk pulling my hair out when I found this post of his. Without it, I’d probably still be digging. As his post mentions, he has everything you need on google code. Good man, Andrew! Just checkout everything from the svn, grab his src/mx folder containing the patched classes, and toss it in your source folder. Now you’re patched. He’s commented the changes so you can see what all was needed. I’d recommend at least seeing what he’s done to SystemManager’s docFrameHandler method, allowing for drag/drop versus native drag/drop behaviors conditionally.

Once again, I’d like to thank Andrew for being on top of this one. I also would like to again encourage anyone affected by this vote for the bug.

I’m as impressed with AIR as I am, now and again, depressed by it. To be fair, AIR is great and things just work more often than not. However, when things occasionally don’t work (or at least not how one might expect), one tends to mark these failings with more weight than they do things that just work. This is especially true when you’re under the gun to get the job done.

I’m still new to AIR, but my current AIR project has taught me some harsh lessons. From these, I’ve arrived at a number of workarounds that I’d like to share with the community… perhaps preserving for some of you that full head of hair for a while longer. Below you’ll find a few of the topics I’ll be covering in my next few posts.

1) Drag And Drop in AIR versus Flex/browser

2) Writing to the application directory

3) Running multiple instances of the same AIR app

4) Single installer for AIR runtime and your AIR app without a browser (CD distribution, for instance)

Please stay tune over the next few days as I collect my thoughts on the above. In the intervening time, drop me a comment if there are other topics you’d like me to consider. Even better if you have other complete workarounds on existing issues and would like to have them posted here. I should have my 1st post up over the weekend. Kinda slammed with the aforementioned project at the moment.

UPDATE:
Fam was in town this weekend and it’s back to a busy work week. Sorry for the delay.

So it appears there haven’t been any Flex 3.x SDK nightly builds since April 8th. I would have thought the momentum gained by the bug quash in May would have continued a bit longer with so many new contributors. That and nightly builds before the event were much more regular. I know Flex 4 SDK developement is rightfully going strong, but still seems unusually slow on the 3.x nightly’s. Wonder if this suggests a pending 3.4 milestone release. Any insiders or speculators care to comment?

A friend of mine was working with RichTextEditor and discovered an annoying htmlText issue. It seems that copying htmlText from the RichTextEditor to a text area produced an additional line break. Dig the code below:

< ?xml version="1.0" encoding="utf-8"?>
<mx :Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical">
 <mx :String id="savedHtmlText" />
 
 <mx :RichTextEditor id="rte" change="savedHtmlText = rte.htmlText"/>
 
 <mx :TextArea htmlText="{savedHtmlText}"/>
 
</mx>

It seems that yanking the closing paragraph tag patches the issue, like so.

< ?xml version="1.0" encoding="utf-8"?>
<mx :Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical">
 
	</mx><mx :Script>
		< ![CDATA[
			private function stripEndParagraphTag():void {
				var startString:String = rte.htmlText.slice(0, rte.htmlText.lastIndexOf("</P>")+3);
				var endString:String = rte.htmlText.slice(rte.htmlText.lastIndexOf("")+4);
				savedHtmlText = startString + endString;
			}
		]]>
	</mx>
 
	 <mx :String id="savedHtmlText" />
 
	 <mx :RichTextEditor id="rte" change="doChange()"/>
 
	 <mx :TextArea htmlText="{savedHtmlText}"/>

Like many others these days, I’ve been let go from my job. Happened on New Year’s Eve. While I’ve decided to take it easy for a week or so, I am looking. Just updated my resume and tossed a copy on this blog. I can also be found on LinkedIn here. Just figured, for completeness, that I’d post that I’m looking in case anyone out there has an opportunity they’d like to share.

When really concerned with performance, should you explicitly cast an object or should you use the “as” operator? Outside of circumstances where the “as” operator must be used because of constructor arguments or the potential for them down the road, the answer is that it depends. Different classes have different costs. If performance is crucial, test first. The code samples below should illustrate my point. First up is casting to DisplayObject.

private function onClick(e:MouseEvent):void {
        var n:int;
	var t:int;
	var c:DisplayObject;
 
	n = 5000000;
	t = getTimer();
	while (n--) {
	    c = e.target as DisplayObject;
	}
	trace("DisplayObject as:", getTimer() - t); // avg = 1367
 
	n = 5000000;
	t = getTimer();
	while (n--) {
	    c = DisplayObject(e.target);
	}
	trace("DisplayObject explicit:", getTimer() - t); // avg = 1809
}

Now lets look at casting to a Container.

private function onClick(e:MouseEvent):void {
        var n:int;
	var t:int;
	var c:Container;
 
	n = 5000000;
	t = getTimer();
	while (n--) {
	    c = e.target as Container;
	}
	trace("Container as:", getTimer() - t); // avg = 1625
 
	n = 5000000;
	t = getTimer();
	while (n--) {
	    c = Container(e.target);
	}
	trace("Container explicit:", getTimer() - t); // avg = 1346
}

I may feel I’m too busy to post much these days, but a collection of undomesticated equids couldn’t drag me from the voting booth tomorrow. Hope to see demonstrated by the numbers that everyone able to vote feels the same.

Not shying away from exposing preference (by leaps and bounds), I submit an unfunny but nearly clever poem. Best I could do this election year.

Because McCain will Palin comparison, I’m a Biden Obama.