2 Replies Latest reply on Nov 3, 2010 2:29 PM by drkstr_1

    Plans for Native Flex Integration?

    drkstr_1 Level 4



      I missed the Catalyst session at Max this week, which was disappointing since there appears to be a lot of potential with FC.


      Anyways, I was wondering what plans the FC team had on moving towards native integration with Flex (and Flash Builder). It would be nice if FC could just read and write directly to the same project files as Flash Builder does. If it could at least do everything you can do in the FB design view, that would be a major step in the right direction (imho).


      Are your plans for FC moving towards a feature rich replacement for the Flash Builder design mode (albeit at some inherent reduction in usability), or do you plan on moving in a direction aimed towards an easy to use prototyping tool for designers?



      Many thanks for your time!

        • 1. Re: Plans for Native Flex Integration?
          Peter Flynn (Adobe) Adobe Employee

          Hi drkstr,


          Glad you asked!  The next version of Flash Catalyst ("Panini") will support a full bi-directional workflow with Flash Builder.  A Flash Builder project in your workspace can be packaged up into an FXP file which you can then open and edit in Catalyst.  All of the code you wrote in Builder is preserved, and runs when you launch the project from Catalyst just as it does when you launch from Builder.


          In this release, Catalyst won't support everything you can do in Builder -- there will be some compatibiity restrictions that may limit your ability to edit some parts of a project, or in a few cases prevent a project from being opened altogether.  But the flip side is that supported content can be richly, visually edited in Catalyst without breaking the stuff you added in Builder.


          You mentioned Builder's design view...  Can you tell us more about what design view features you'd like to see in Catalyst?


          Catalyst's current road map is not to replace design view in Builder -- we intend Catalyst to remain a separate tool, able to be used by designers who have no experience with Flex programming.  However, we do plan to continue tightening the workflow integration between the two tools.  Also, in the future you will probably see some "cross-pollination" between design view and Catalyst, with features migrating from one to the other or being added to both at the same time.


          Hope that answers your questions.  We'd love to hear more about what sort of workflows you have in mind, if you have time to write more!


          - Peter

          • 2. Re: Plans for Native Flex Integration?
            drkstr_1 Level 4

            Sorry for the late reply. I've been on the grind for the past few days. I'm sure you know how it goes.



            It's not really about what the design view has that FC doesn't, but more about the potential FC has for satisfying the needs of UX Developers/Designers.


            To give you an example case study, we have Framework Developers, UX Designers ("content writers"), and Graphic Designers. Our UX creatives have very little programming experience, and work primarily in MXML, with the occasional event handler and such. Their needs are not being met very well with a tool targeted for engineers (Flash Builder).


            I would be tickled pink if our UX Designers could use a tool that's targeted for creatives, but still gives them the ability to fully realize their vision. It seems like FC could satisfy those needs if it supported some additional functionality.


            To name a few things...


            • Utilize the full spark component library
            • Support package structures
            • Edit inspectable properties
            • Specify data bindings to/from inspectable properties
            • Select an interaction from a list of events (specified in the component metadata)
            • Add interactions that change inspectable property values (IE. On [select event] -> set property -> [select target] -> [select a property] -> [enter a raw value or binding] -> if [select an optional condition]
            • Select/edit a custom function for an interaction (specify parameters, input values, and lines of code that preform an action)
            • Select/edit a custom function as a condition for an interaction (specify parameters, input values, and lines of code that return a boolean)


            Off the top of my head these are the features that would make it a valuable tool for both our UX and Graphic Designers.


            I realize that a lot of this functionality would not be targeted for "pure" designers, but I feel like it would greatly increase the value add of FC, while still remaining a simple to use tool for those who do not need the extra functionality. And a larger target market isn't always a bad thing.