Posted by: mhughes 3 years, 11 months ago
I've been an advocate of compiling from Catalyst to a swc in a two previous blog posts. (A Flash Catalyst / Builder workflow method , Compiling FXP->SWC, a Catalyst workflow) I'm hoping to explain why I prefer that workflow here. With big pretty pictures!
First, let us look at the catalyst workflow that's been all the rage in the demos online that introduce catalyst (like this one). Refer to the diagram below.
Pros:
- Super simple
- Limited to one designer and one developer
- Limited to a single catalyst project
- Developer can't start until designer is finished
- Once the designer has handed off the file, they can't make edits.
Something that hasn't been as widely discussed, but that is still part of the official offering from Adobe goes something like this diagram:
In this scenario, the developer creates a plain old Flash Builder project. While he's doing that, the designer creates a .FXPL file. The developer takes that .FXPL and imports it as a Flex Library project, which he then references from his main project. (Just import the .fxpl like a .fxp, the correct type of project is auto-created) Later, the designer can make changes in Catalyst. Then the designer exports a new .FXPL file and the developer can re-import it (re-import steps below).
Optionally, the developer can move the classes into a package structure inside Flash Builder. If there will be more than a single .fxpl imported, this is required since there will be name conflicts. Currently, the refactor in Flash Builder doesn't work 100% for this as the skin references aren't updated, hopefully that's just a beta-bug and will be fixed.
This is a huge improvement over the previous workflow and will probably work out great for most people.
Pros:
- Developer and Designer time can overlap
- You can have multiple designers and developers (by repeating that middle bit in the diagram
- Can use a package structure
- An "official" Adobe method
- Developer is not allowed to edit the Flex Library project that is imported, he can only use classes/assets from it in his main project.
- Every time a new .FXPL comes out, the developer must (I bet some of this could be automated!):
- Delete the current Flex Library project
- Import the new .FXPL
- Modify the main project to reference this newly imported project
- Move the classes in the Flex Library project into a new package structure
- Rebuild the swc
- Rebuild the app
- Does not retain the Main class from catalyst, so all work must be done in sub-components
What if we could automate some of the process of turning a .FXPL into a .swc? Or even better, what if we could turn a .FXP into a .swc? Then we'd have something that looks very similar to the previous workflow, but with one important difference:
Pros:
- Developer and Designer time can overlap
- You can have multiple designers and developers
- The script automatically converts the Main catalyst component from an Application object to a Group object so you can use it in your project. (Coming Soon! The next version of my script will)
- Automatically uses a package structure
- Developer is not allowed to edit the Flex Library project that is imported, he can only use classes/assets from it in his main project. (But he only ever sees a swc now, so no worries)
- Every time a new .FXP comes out, the developer must somehow get the new .swc (more on this below)
- Requires a script to run (requiring whatever environment that script was written in)
Instead of a single developer and a single designer, picture a whole team of them. If every developer needs to go modify their workspace every time any designer makes a new .FXPL, they'll end up spending too much of their time just managing their build environment. The more people you add, the worse it gets.
If that script can be run through a command line script, it can be automated.
Most teams that consisting of more than a couple people use a version control system. That system can be used to distribute .swcs that are generated from the catalyst projects. Many version control systems have hooks integrated into them so they run a script whenever a certain file or directory is modified. If yours doesn't have than a simple scheduled job could do it. This can simplify the process even further to:
- Designer checks .FXP into version control
- Script runs, automatically generating the .swc
- Developers sync up, getting the new .swc
If you don't use a version control system, scheduled jobs and a shared network folder could do the same thing.
This solves the scalability problem.
All that is good-and-well, but that script to generate the .swcs must be awfully hard to do, right? Wrong. It was easy. It's done. Go give it a try.
Blog post describing the script. Download: fxp2swc.rb
Any windows based Ruby developers want to take a crack at updating the script to work correctly on windows?
Share on Twitter Share on Facebook
Comments
How about FLV implementation in FC? whether through embedding or preferable SOURCE LINKAGE
Link / ReplyHow about FLV implementation in FC? whether through embedding or preferable SOURCE LINKAGE
Link / ReplyHow about FLV implementation in FC? whether through embedding or preferable SOURCE LINKAGE
Link / ReplyHow about FLV implementation in FC? whether through embedding or preferable SOURCE LINKAGE
Link / ReplyHow about FLV implementation in FC? whether through embedding or preferable SOURCE LINKAGE
Link / ReplyOnce your working in Flash Builder, you can use FLV just like you normally would.
Link / ReplyOnce your working in Flash Builder, you can use FLV just like you normally would.
Link / ReplyOnce your working in Flash Builder, you can use FLV just like you normally would.
Link / ReplyOnce your working in Flash Builder, you can use FLV just like you normally would.
Link / Replygreat article, always interested in more efficient work flow.
Link / Replygreat article, always interested in more efficient work flow.
Link / Replygreat article, always interested in more efficient work flow.
Link / Replygreat article, always interested in more efficient work flow.
Link / Replygreat article, always interested in more efficient work flow.
Link / ReplyGreat stuff... I strongly agree that it should be targeted to keep the output of FC "readonly" from the perspective of the developer working in FB. Your proposed workflow somewhat resembles the workflow we have with the Flex Toolkit for Creative Suite when exporting Flex skins, so its not that farfetched... all we have to understand is that the "skin" now includes the entire IxD as well... or am I jumping to conclusions here ?
Link / ReplyGreat stuff... I strongly agree that it should be targeted to keep the output of FC "readonly" from the perspective of the developer working in FB. Your proposed workflow somewhat resembles the workflow we have with the Flex Toolkit for Creative Suite when exporting Flex skins, so its not that farfetched... all we have to understand is that the "skin" now includes the entire IxD as well... or am I jumping to conclusions here ?
Link / ReplyGreat stuff... I strongly agree that it should be targeted to keep the output of FC "readonly" from the perspective of the developer working in FB. Your proposed workflow somewhat resembles the workflow we have with the Flex Toolkit for Creative Suite when exporting Flex skins, so its not that farfetched... all we have to understand is that the "skin" now includes the entire IxD as well... or am I jumping to conclusions here ?
Link / ReplyGreat stuff... I strongly agree that it should be targeted to keep the output of FC "readonly" from the perspective of the developer working in FB. Your proposed workflow somewhat resembles the workflow we have with the Flex Toolkit for Creative Suite when exporting Flex skins, so its not that farfetched... all we have to understand is that the "skin" now includes the entire IxD as well... or am I jumping to conclusions here ?
Link / ReplyGreat stuff... I strongly agree that it should be targeted to keep the output of FC "readonly" from the perspective of the developer working in FB. Your proposed workflow somewhat resembles the workflow we have with the Flex Toolkit for Creative Suite when exporting Flex skins, so its not that farfetched... all we have to understand is that the "skin" now includes the entire IxD as well... or am I jumping to conclusions here ?
Link / Reply@Peter That's pretty much what I was thinking. There will be probably be some interesting conversations between design and development to make sure to structure those interactions in a way that the code can correctly invoke them.
Link / Reply@Peter That's pretty much what I was thinking. There will be probably be some interesting conversations between design and development to make sure to structure those interactions in a way that the code can correctly invoke them.
Link / Reply@Peter That's pretty much what I was thinking. There will be probably be some interesting conversations between design and development to make sure to structure those interactions in a way that the code can correctly invoke them.
Link / Reply@Peter That's pretty much what I was thinking. There will be probably be some interesting conversations between design and development to make sure to structure those interactions in a way that the code can correctly invoke them.
Link / ReplyIt took me some times but now I've got my challenger workflow ready: http://www.flexstuff.co.uk/applications/catalystbuildersync/ Ok, ok, I can hardly see mine being able to compete with your approach when it's about working with large teams, but still :)
Link / ReplyIt took me some times but now I've got my challenger workflow ready: http://www.flexstuff.co.uk/applications/catalystbuildersync/ Ok, ok, I can hardly see mine being able to compete with your approach when it's about working with large teams, but still :)
Link / ReplyNew Comment