Eclipse Galileo 3.5 to Helios 3.6

I did Windows for a long time. And I'm still ok with it (though I stopped upgrading at XP SP2). Just the same, I'm all in with Mac for the past couple of years. The wherefore comes down to OS X, and more specifically, Unix. Can't beat having an underlying layer of open source OS!

I'm upgrading Eclipse today. I had announced with great fanfare the coming of Eclipse Galileo, but Helios found me focused on other things, so I'm stepping up the SDK to 3.6 now. On the Windows/Mac front, I prefer the small install and configuration footprint of unix apps vs the windows registry. Power Windows users may opine otherwise, but I find the modularity of apps on the mac to be quite painless.

That said, I'm opting not for a clean install of Eclipse 3.6, but rather an upgrade from 3.5 using the software updates dialog. A little background, I use both Flash Builder and Eclipse on my MacBook, the former for AS3 and Eclipse for JS, PHP, Python, basically 'everything else'. I have added Subversive SVN to FB and it works great, and with the possible exception of mylyn in the future, I plan to keep FB in quarantine. (update: broke my own rule there, I added eGit to FB and it is flawless.)

This is just a safety, as I have had issues with other FB installs going off the rails when too many open-source libraries are added to the SDK. It can be a real train wreck when this happens, especially if you're facing a killer deadline. For the record, any deficiencies with Eclipse as a platform are simply the small and acceptable dark side to a robust and maverick developer community. So I keep FB static and use Eclipse as my test lab.

As for the SDK upgrade, it worked great. Here is a simple FAQ from Eclipse to follow. When the dialog presents you with a list of available upgrades, choose only those listed as 3.6. Better not to upgrade too many things all at once.

This is part of a larger operation which I will also post about. Namely, getting a JS/PHP/Git environment up and running within the Eclipse SDK. I've worked with TextMate thus far and will sing its charms, however, I've used Eclipse long enough to love what it does, so developing in a fully Integrated DE is my goal.

A Morsel on Flash Professional Projects in Flash Builder

Flash Builder is so very great to use. Such a time saver for the stuff I work on, especially in conjunction with subversion. Having a repository view of a remote SVN server, being able to update and commit, not to mention the ease of 'diffing' in the Eclipse SDK. Best thing ever.

Lock down FB and SVN and you will find varying project types to choose from: Flex Project, Flex Library Project, or Flash Professional Project. Please join me in considering the good and bad of the Flash Professional Project.

Here are the things I like and don't like about managing a Flash Professional Project from FB.

The Likes:

• The .project configuration file
• can be saved to SVN, so you can open all your resources quickly at later date
• allows you to select .as files from within Flash Pro and have them open in FB for a better coding experience ( still better even thoughh Flash Pro now completes code)
  

The Dislikes:

• The .project configuration file
• because collaborators with whom you share the Flash Professional Project, since the .project file is generally only usable in one particular configuration, will find it distracting
  
• Two environments (FB and Flash Pro) means 2x the path configuration. Yes, you have to path to libraries and swcs twice. Once in FB, and once in Flash Pro.
• Frequent quickly appearing and then disappearing phantom publishing panels, due to the need for FB to remain synchronized with Flash Builder. I'm on Mac and this is one of the more disturbing issues.
• The fact that you must create and save a .FLA as a precursor to starting a new Flash Professional Project, then associate the .FLA with the new Project, and then add the new document class back to the .FLA. Far better to have the .FLA generated through FB and configured according to initial project values.

Seems like the nays have it this time. I find it works better to use subclipse to manage FLAs without converting them into Flash Professional Projects. The only tiny caveat to this approach is that you must open the associated .as files directly from FB rather than via Flash Pro.

It remains to be seen what Flash Builder "Burrito" adds to this mix.

Flash Catalyst and Flash Builder workflow

More workflow explorations incorporating Adobe Flash Catalyst. Among the hopeful tests and discoveries, a stark word of caution is a rare gem. Here is one from an article authored by Adobe's Andrew Shorten (italics mine):

It is not possible to re-open a Flex project in Flash Catalyst once you've imported it into Flash Builder. (The product teams will investigate this option for a future release, but it will not be available in the first release of Flash Catalyst.) To overcome this limitation, consider the other workflows in this article, in particular workflow 3, which extends the approach used here to support iterative development.

Workflow 3 incidentally outlines the use of 'Compare Project With Version' > [previous version] as a means of reconciling different code versions. This represents great hardship in a round-trip and, in light of just how different the versions would be, is IMO not a viable solution.

Further on this, a detailed blog entry regarding 'catalyst jailbreak for flex developers' is exploratory and non-committal in tone as it explores Catalyst integration. Here is a further obstacle to a Catalyst workflow that extends from a different angle on the quote above:

An important note: There isn't a place to set the ID on Flash Catalyst components. When a designer converts artwork to a component and then exports a custom component with multiple text inputs, say a registration form, none of those text inputs contain ID's.

And further:

...when the design changes and it does, the one way Flash Catalyst generated code has no knowledge of your so called ID's. The design has changed and all or nearly all the components are anonymous again. So the developer has to manually find and add the ID to each text input, radio button, button, each time the design is updated etc.

While there are workarounds, there is not yet a clean workflow to utilize.

Flash Catalyst Panini, you are up next.

Flash Builder 4 Workflow from Catalyst to Flex

Skin vs SparkSkin Classes in the Flash Builder 4.1 SDK

Seems the difference between the two is that SparkSkin adds some extensions that would likely not be used in the creation of a custom Spark Skin. Therefore, you can pretty much just use the Skin class if you are developing a custom implementation.

Here are a couple of resources with limited info on the topic:
http://forums.adobe.com/thread/465734?tstart=0
http://unitedmindset.com/jonbcampos/2010/06/02/the-difference-between-skin-and-sparkskin/