7 Replies Latest reply on Sep 30, 2011 5:00 PM by rexdtripod

    Spark and MX no man's land

    rexdtripod Level 1

      I see people asking the question, "what's the deal with spark?  Should I go there?"  Sometimes the answer is "if you're starting a new app, use the new framework".


      I'm not.  I have an existing 3.5 MX app. that's kind of complex.  I've tried to upgrade to 4.5, Spark but no luck.  The app needs things that Spark doesn't appear to have covered yet.


      So what's the deal?  Will MX be hanging around a while?  Every time plop a Canvas in my app my FlashBuilder IDE tactfully recommends I use the Spark counterpart.  Why?  Where are we really going with this?  How much time to we have?  When will the gaps in capabilities be closed so I can do the conversion and move on?



        • 1. Re: Spark and MX no man's land
          drkstr_1 Level 4

          I suspect we won't see Halo (mx) go away completely until Spark is fully implemented and has a replacement for every MX component.


          Flashbuilder suggests using the Spark components instead (when there is a viable replacement) because it's a superior architecture to the halo components. Of course there will be a few hold outs that disagree with that statement, but they are far and few between.

          • 2. Re: Spark and MX no man's land
            John Hall Level 4

            While I have no doubt that the architectural design is better thought out (I know I cringe when I see my old code) what is your definition of superior architecture?  It certainly seems like spark can be a little 'heavy' which, I assume, is the resin many of the mobile skins favor ActionScript solutions. Interested in finding out more about what makes Spark components superior.

            • 3. Re: Spark and MX no man's land
              drkstr_1 Level 4

              The Spark architecture is extremely light weight and agile when compared to the Halo architecture. That is my definition of superior.


              The main value of Spark is the separation of component logic and display logic. This keeps components very light weight, and allows display implementation to be changed independently. It also allows for greater control and customization for the developer, instead of having to rely on a one-size-fits-all solution which is very hard to modify.


              You mentioned the mobile skin, which is a perfect example of spark at it's finest. I can completely change the way components interact with the user simply by changing the view implementation (see list scrolling in mobile app for example). Creating a light weight skin for mobile apps using optimized Actionscript is the very definition of Spark. Unlike the bulky MX components, how to implement the view is up to the developer.

              • 4. Re: Spark and MX no man's land
                rexdtripod Level 1

                It all sounds great.  I get the upside.  All of the development world is heading toward MVC.  Makes sense.


                My problem is the no man's land in the middle.  Where are the guidelines on what to do with existing apps?  They are MX.  And some are large and complex.


                With the rearchitecting of the framework, there are gaps in capabilities.  I'm not just talking about missing components that will be added later.  There are just things you could do in the old realm that the new framework does not seem to support.  Maybe some of this will be addressed in future releases or maybe not.  Not sure.  How would one know?  Are there forums that address these issues specifically?


                Are the migration guidelines?  Meager scattered migration docs available currently seem mostly preoccupied with "if you used this component before, use this one now" type stuff.  Are there higher level migration resources?  Maybe AdobeTV recordings specifically devoted to migration?


                Complex apps are in no man's land.  If you want to build in additional functionality into them, you kind of have to stick with MX.  Mixing the components isn't working for me because there are conflicts between the two realms.

                • 5. Re: Spark and MX no man's land
                  rthricov Adobe Employee



                  We at Adobe are fully committed to the Spark architecture and are in the process of creating an equivalent Spark component set vis-à-vis MX. Our aim is for Spark to let you do much more with your component in terms of customization and skinning without taking a hit on performance.


                  I also wanted to take this time to get some more clarification on one of the comments on the thread:


                  rexdtripod said “With the re-architecting of the framework, there are gaps in capabilities.  I'm not just talking about missing components that will be added later.  There are just things you could do in the old realm that the new framework does not seem to support”.


                  Could you elaborate on the above comment? I would definitely like to know the features that you think will be lost if we replace all mx components with Spark equivalents.


                  Thank you,

                  Raghu Thricovil

                  Product Manager, Flex SDK

                  1 person found this helpful
                  • 6. Re: Spark and MX no man's land
                    rexdtripod Level 1

                    Absolutely, and thanks much for your interest and response to this.


                    Feature one: Can't horizontally or vertically center on ColumnConstraints in Spark.




                    The answer in the end of the post  above was "we haven't implemented it yet".  That's a gap in capability.


                    Another is state transitions.  You'll find numerous posts on this.  In my case my app has objects that appear, disappear, move, and resize in various states - and I ease in transition between the states to make the movements look smooth and elegant.  My old MX app works beautifully in this regard.  Really slick.  In my Spark version the transitions between the states just don't work properly.  In some cases they don't fire and in others they just aren't smooth.  Seems like this functionality isn't fully implemented yet either.  Capability gap.


                    Hence - "no man's land".


                    The term is meant to reflect a deeper problem - a broader strategic problem faced by developers with existing MX applications:


                    1.  We have existing MX apps with complex designs.

                    2.  Spark has been released, but is not complete

                    3.  We don't know what's not complete nor when it will be completed (e.g., horizontalCenter and verticalCenter still compile fine.  They're still in the language.  They just don't do anything).

                    4.  We're building on our old apps - still adding features and such

                    5.  We don't want to add new functionality to the old architecture if we can avoid it.  We'd rather build with the new

                    6.  Can't build it in the new because we can't make the switch yet

                    7.  Don't know when we should make the switch


                    And round and round she goes.


                    I personally want to take advantage of the Spark MVC approach.  It will help me develop parallel skins for browser and mobile interfaces.  I just don't know when I'll be able to do it.


                    Currently it's trial and error for me.  I rework my old MX code, compile and run.  Compiles fine.  Some things like above just don't work though.  When I post them people just say "try using these other components" or "go back to MX" components.


                    Some sort of broader, higher level conversion strategy is needed.  Something more organized.

                    • 7. Re: Spark and MX no man's land
                      rexdtripod Level 1

                      Feature two:  Alert control.  Just disappeared in Spark.  If doing Flex Mobile development, can't use MX controls.  Just a gap in capability.