9 Replies Latest reply on Jun 24, 2011 10:07 AM by Shongrunden

    Addicted to Groups?

    CleanCoder Level 2

      Is it me or does every solution to a styling/layout question end in "Just add it to another Group and..."? Seriously, the PanelSkin.mxml contains 10 different Groups alone! I wouldnt exactly call Group a "lightweight" class. In addition it also requires a Spark RectangularDropShadow class just to create the drop shadow (Do we really need a class that extends UIComponent just to draw a drop shadow these days?).


      I guess I'm just wondering if it is really worth sacrificing performance and efficient design just to make people feel it is "easy" to use?


      P.S. Setting constraint values on child element from updateDisplayList causes updateDisplayList to be called twice. For example look at the first if/else blocks in the updateDisplayList function of PanelSkin.MXML. Setting the "background" and "content" constraints there causes it to be redrawn twice if you toggle to "borderVisible" property. I'm pretty sure this happens in alot of the default MXML skins and I know I mentioned this to Kevin Lin a while ago and he did file a bug, but as far as I can tell nothing has come of it. I would think having to redraw twice would be considered relatively important...

        • 1. Re: Addicted to Groups?
          UbuntuPenguin Level 4

          I guess we would have to profile the cost of Groups in a real application.  Personally, I think we substituted HBox,VBox with Group ( which is okay with me ) and we didn't have the skinning architecture in Flex 3 that we have in Flex 4 so alot more stuff that was under the hood can now be investigated and customised.  PanelSkin does have a Group heavy skin, but it is also one of the more visually appealing classes out of the box too.  Of course, nesting of components can be detrimental to an application, especially with bubbling events, but other than MouseEvents I can't think of another bubbling type of event of off the top of my head ( assuming the capture phase doesn't hurt as much as the bubbling phase );

          • 2. Re: Addicted to Groups?
            CleanCoder Level 2

            Visually appealing sure, but at the cost of using 10 groups to achieve essientially a content box surrounded by some simple chromewith a drop shadow and a gradient in the title bar? Not to mention the use of both a VerticalLayout and a HorizontalLayout, which IMO is overkill, just to position the title, content, and controlBar (Do we really need support for virtualLayout, variable row size, etc, just to vertically or horizontally stack elements?). I'm pretty sure bloated skins/layouts arent a new revalation to Adobe especially since they scrapped the Spark skinning architecture for mobile skins and went back to the basics, using pure Actionscript. Now though, it seems like people dont even bother or care to learn what is actually going on under the hood of MXML, they can just add some tags and pretend like they are programming.

            • 3. Re: Addicted to Groups?
              UbuntuPenguin Level 4

              I don't know if I would downvote them that hard. I personally like MXML citing the fact that it is quick to get UI's operational VERY quickly.  Whenever I feel performance may become an issue, I just write it in AS3.  But the hard parts or changing a UI to meet client needs are done by then or at least stable. The main advantage of MXML is that it allows the more visual type of individuals to get to work thereby sewing together the workflows.  Even though I wouldn't put Flex coding on the same level as kernel programming ( I stay away from pointers to pointers to pointers whenever I can), there is still a good aspect of programming to be found.  Architecting an application, testing, frameworks and knowing when and when not to use the aforementioned is still alive and kicking in the field.

              • 4. Re: Addicted to Groups?
                CleanCoder Level 2

                Ok, maybe I was a little harsh, but my main point was sacrificing performance for ease of use (specifically for creating skins) just doesnt seem right to me. If it's not recommended for ItemRenderers and its not at all optimized for mobile use, why keep pushing MXML skinning? What if the visual individuals dont understand that every extra Group instance they create to make their design translates to less and less efficiency (ex. "Why are my itemRenderers with nested layouts causing my app to grind to a halt?..."). I am not blaming them for anything though, because I assume they are just following Adobe's MXML skinning concept of wrapping everything in multiple Groups.  I definitely do agree with you as far as MXML for app skeletons and basic mockups goes. 

                • 5. Re: Addicted to Groups?
                  Shongrunden Adobe Employee

                  "especially since they scrapped the Spark skinning architecture for mobile skins and went back to the basics, using pure Actionscript"


                  >> The spark architecture hasn't been scrapped, it's just that the default mobile skins are written in ActionScript instead of MXML in order to eek out every inch of performance possible.  This makes the skins a lot harder for people to customize, but does lead to the best performance.  You're welcome to still use MXML skins on mobile if it makes sense for you.


                  Minimizing Groups is just one of many best practices for optimizing Flex applications.  Check out Evtim and I's presentation for some more information on how to optimize MXML item renderers and MXML skins: http://flexponential.com/2011/04/20/flex-performance-tips-tricks/

                  • 6. Re: Addicted to Groups?
                    CleanCoder Level 2

                    I meant to say "scrapped the MXML skinning architecture",  (not Spark). Nice presentation BTW. I hope some of those optimization techniques make their way into some of the default skins soon.

                    • 7. Re: Addicted to Groups?
                      Shongrunden Adobe Employee

                      There is always ongoing work to optimize performance in the framework including this area.  I think we'll also see large gains in mobile device capabilities so hopefully it won't be long until we're back into the days where we are targetting powerful multicore machines with lots of memory.

                      • 8. Re: Addicted to Groups?
                        Devtron Level 3

                        ^ That sounds like you are hoping hardware will solve Adobe's poor architecture.


                        I agree with the original poster that re-usability is not a high priortiy in FLEX

                        • 9. Re: Addicted to Groups?
                          Shongrunden Adobe Employee

                          Sorry that wasn't my intention at all.  No matter how fast devices become we will always have developers doing awesome things with Flex that constantly pushes the limits and this is why there is always optimization work going on in the SDK.