Skip to content
January 25, 2015 / Daniel Freeman

Eight MadComponents XML Layout features that I’d like to see in Feathers.

For every Adobe-endorsed AS3 Framework, there tends to be at least one non-endorsed AS3 Framework that is much better in some ways.  Diversity is a good thing.  So, Adobe endorsement is a mixed blessing.  On the one hand, it’s great that Adobe takes frameworks that have been incubated by the community – and injects money, publicity, and surrogate credibility.  On the other hand – exclusivity is bad for the AS3 community, and it stifles innovation and advancement.  Adobe only shines its spotlight on ONE framework in each category.  Everything else is cast into the shadows.  Developers naively assume that Adobe-endorsement means that the Adobe-endorsed framework will do everything better than the non-endorsed framework.  So when the Adobe-endorsed framework fails to deliver – that developer will look elsewhere.  They’ll jump the fence to HTML5, Unity3D, Corona, etc, rather than consider fantastic non-endosed AS3 Frameworks.  I know that this has happened, and that the Flash Platform has needlessly lost credibility and developers to the competition.

Adobe supports three significant AS3 frameworks, for three significant use-cases.  Away3D for 3D animation.  Starling for 2D animation.  And Feathers for UI Form-based apps.  For each of these use-cases, there are amazing non-endorsed frameworks.  Zest3D, and Flare3D for 3D animation.  Genome2D, and ND2Dx for 2D animation.  MadComponents for UI Form-based apps.

There is no silver bullet.  The best framework for one project, may not be the best for another.  In some respects, Adobe-endorsed frameworks are better.  In other ways, non-endorsed framework are better. It will all depend on the requirements of the application.  For example, Away3D is well-known and mature.  But Zest3D performs better on devices.  Adobe endorsement of Starling has created tremendous interest.  But Genome2D performs better.  Feathers allows for smoother page transitions, and list scrolling.  Also Feathers mixes well with Starling.  But MadComponents is better with pixel-snapped images, embedded fonts, ease of adding customised components, a faster start-up time, and it has many more components, including the most performant mobile-optimised datagrids of any AS3 UI Framework. I’m not trying to discredit the Adobe-endorsed frameworks, or their developers.  But I have a lot more respect for the developers of non-endorsed frameworks, for their tenacity, ingenuity, and dedication, despite being cast into the shadows.  I just wish there was more discussion about the relative merits of both Adobe-endorsed and non-endorsed frameworks.  I wish the authors of the Adobe-endorsed frameworks would shed more light on the alternatives, rather than silently reinforcing a misconception of theirs is the only AS3 way to do the job.

Actually, there is just one previously Adobe-endorsed framework that I would remove from the face of the planet if I had the chance.  The inadequacy of Adobe Flex for Mobile (now Apache Flex) has done a lot of damage to the credibility of Adobe AIR on devices.

I was interested to read that Josh Tynjala plans to incorporate MXML layouts to Feathers.  He is looking for corporate sponsorship.  Or he may consider Kickstarter funding.

tweet I was interested that some of the respondents to Josh’s tweet were worried that an XML layout might introduce performance problems.  Some developers assume this, because Flex on Mobile is slow and bloated.  But the problems of Flex on Mobile are not caused by the MXML.  They are caused because the Flex framework was not originally designed for mobile devices, and Flex is optimised for (slow) CPU rendermode. MadComponents is built around a powerful XML layout language that was designed for mobile layouts, and loosely based on native Android development.  And MadComponents is agile, lightweight, and easy to develop for.  So XML layouts are obviously a good idea. The main benefit of a layout XML language is that it makes UI development much much faster and easier.  Also easier to maintain and modify.  I hope that Josh manages to do this, because it opens up some powerful possibilities.  To illustrate my point, here are eight MadComponents layout features that I’d like to see brought to Feathers. (The following list will also be of interest to developers learning MadComponents)

1. Easy Page Navigation Without Code

We want our layout XML language to save us coding and effort.  Let’s look at the way that MadComponents layout deals with navigating pages. Suppose we have defined the XML layout of several pages.  PAGE0, PAGE1, PAGE2, etc…  If want to make navigation for those pages, we don’t want to mess around with glue code AS3.  We don’t want to mess around with listeners, and handlers, that call the API to change the page.  We want just want to write the layout XML, and let the framework handle the nitty-gritty.  For example,


The above layout would generate tab buttons at the bottom of the page.  And those buttons are wired-up to work, without  any additional code.  Later, we will see how we can even define labels and icons as XML data.

Image from MyAstrolabeSky app on App Store

from MyAstrolabeSky app on App Store

Or suppose you want a standard list-based navigation that leads to a detail page.  We want the framework to deal with the nitty gritty of responding to list clicks, sliding-in the detail page, the detail page, and the back-button operation.  So this is all we need:



Even pressing a button to change page shouldn’t require the developer to bother with additional glue code:

<button goTo="home_page" transition={UIPages.SLIDE_LEFT}>GO</button>
2. Custom Renderers

If Josh bases his UI layout language on MXML, then he will likely incorporate itemRenderers.  Here is the MadComponents way to do it:

      <image id="picture">40</image>
      <label id="name" alignV="centre"/>

3. Lazy Rendering

Stage3D apps don’t tend to start up as fast as GPU rendermode apps.  That’s because uploading textures, and vectors to the GPU is an overhead.  Lazy Rendering ensures that render pages as they’re displayed, rather than rendering all the pages when the app starts up.  In MadComponents we might say something like:

<pages lazyRender="true"/>
4. Pixel Density Matched Images

For the sharpest and best quality images, we will want to snap pixels, and match the unscaled image size to the screen pixel density.   So we might specify the image data for icons or tab pages like this:

     <item label="page 1"
 …etc… etc….
5. Different Layouts for Different Screens

If we want to build universal apps.  Or if we want to cater for devices with very small screens (240×320).  Or even if we want different layouts for portrait and landscape orientation – then our XML layout language should deal with alternative layouts for different size dimensions.

<screens id="screens" lazyRender="true" recycle="true">
 <vertical size="320x240">......
 <vertical size="640x480">.....

For more information about the screens tag, see here.

6. Better Labels

Recently, a developer told me that his Hebrew text list was taking about ten seconds to initialise in Feathers.  This bottleneck was due to rendering the text on the display-list, then uploading each row label as a texture.  In MadComponents, there is no noticeable start-up delay.  So, it would be great if there was any optimisation that could be done in Feathers to initialise embedded font text faster.  In MadComponents, an embedded font label looks like this:

[Embed(source="/fonts/SomeHebrewFont.ttf", fontFamily="Hebrew", embedAsCFF="false")]
protected const Hebrew:Class;
<label id="label" alignH="fill" embedFonts="true" antiAliasType="advanced"/>
7. The Model Tag

The model tag enables communication with a server.  It handles retrieval of JSON, XML, or AMF data, parsing, and deriving the data for a form or list.

<model url="http://localhost/MobileTestDrive/gateway.php" service="EmployeeService.getEmployeesSummary" action="loadAMF">

The entire example that this code snippet comes from can be found here.

8. Make It Extensible

MadComponents was designed to be easily extensible, with both pre-existing display-list libraries, and new components.  This extensibility philosophy even applies to the XML layout language.  Here’s an example of using a MinimalComps component inside a MadComponents layout:-

<vertical xmlns:minimal="com.bit101.components">
    <minimal:PushButton label="push me" alignH="fill" height="32" skinClass="com.dgrigg.skins::ButtonImageSkin"/>

An XML UI layout saves you a lot of time, effort, and coding when developing an application.  This is because a powerful XML UI layout language will replace a lot of code.  Not only does the layout replace the code to render a UI to the target device screen size.  It also handles orientation change.  And we’ve seen how aspects of the layout language can also replace the code to navigate an app, custom renderers, managing resources to match screen pixel density, layouts for different screen sizes and orientations, server communication, and many more capabilities.  So XML Layouts for Feathers are definitely a good idea.


Feathers: MadComponents: github: video:



Leave a Comment
  1. Adnan / Jan 26 2015 3:17 pm

    I totally agree with: ” So XML Layouts for Feathers are definitely a good idea.”
    I have one application on google play developed with MadComponents and now try to build the second one with Starling+Feathers. During development I always thinking: why this is not like MadComponents…

  2. Josh Tynjala (@joshtynjala) / Jan 26 2015 7:03 pm

    Thanks for the great suggestions. A comparison to real XML used by MadComponents is a great way to highlight the importance each feature. Some kind of XML layout system is something that I’ve wanted to add to Feathers since the beginning. I always hoped it could be MXML because I enjoyed working with MXML in Flex for many years. I’m happy that I finally found a path to adding MXML support to Feathers. If you don’t mind, I’d like to take a moment to comment on each of your proposed features.

    1. Easy Page Navigation Without Code

    Feathers currently requires you to manually wire up a TabBar to a ScreenNavigator by listening to events. It’s not ideal, I’ll admit, and I’d like to create some kind of TabNavigator component that sets it all up automatically.

    I tend to prioritize development based on community feedback, and this is not something that many developers have asked for. I expect that it will have a higher priority once MXML support is there, since MXML will make Feathers more appealing for form-based apps.

    2. Custom Renderers

    Feathers currently supports custom list item renderers in pure AS3. I fully intend to let developers create a custom item renderer in MXML. In the first release, it’s likely that a custom item renderer in MXML will need to be declared in a separate file, just to make this available to developers faster. Inline item renderers are definitely something that I’d like to add in a later update.

    3. Lazy Rendering

    The Feathers ScreenNavigator currently supports the option to create screens/pages either immediately or as they are needed. I wouldn’t want to take features away, so it will be supported in MXML too.

    There may be other components where lazy instantiation becomes more desirable once MXML support is added. If I find a component like this, I will highly prioritize this feature to maximize performance.

    4. Pixel Density Matched Images

    Starling can be set up to use a scale factor similar to how native iOS apps do it with 2x assets for Retina displays. Starling developers have a lot of control over how the stage scales, so these scale factors can be used to create any number of buckets. When skinning Feathers components, developers can easily check Starling’s scale factor to choose which set of assets to use.

    This can still be improved, though. Setting the stage and view port dimensions in Starling can be a little tricky if you don’t want letterboxing. It’s possible to avoid letterboxing, but it requires some math that could be encapsulated, I think. I’d love to make this easier for both Starling and Feathers developers.

    5. Different Layouts for Different Screens

    The screens tag in MadComponents looks very cool. It’s something that I will keep in mind for Feathers. I’d definitely like a simple declarative way to define different layouts for different device categories. I’m not sure what “the Feathers way” of doing this will be yet, but given some time to see how people start using MXML with Feathers, I hope to get a better idea.

    6. Better Labels

    Ten seconds to render a label is very out of the ordinary. Usually, only one texture is required per label, and individual words are never split up as separate textures. For long passages of text, Feathers may use multiple textures, but only if the text is larger than the maximum texture size allowed by Stage 3D.

    It’s likely that this developer needed two or more very large textures for a long passage of text. Probably many more than two because ten seconds is abnormally long. Feathers provides a component called ScrollText for this situation. ScrollText will render text on the classic display list above Starling instead of drawing a snapshot to a texture.

    Text on the GPU is hard because there are so many tradeoffs. This is a place where MadComponents will always be a little easier to use, I think.

    7. The Model Tag

    I certainly want to make it easy to declare a way to communicate with a server in MXML. This has a high priority for me because I remember it being very frequently used in Flex. It may come in a later update just to get the layout stuff out to developers first, but I’m going to try to make sure it doesn’t stay missing for long.

    8. Make It Extensible

    Feathers layout containers will allow any type of Starling display object to be added as a child. Much like how MadComponents lets you use MinimalComps, Feathers would work with another UI component framework built on Starling. That’s been very important for me from the beginning. I never liked how Flex forced all children of a container to be Flex components. Any display object should be allowed.

    Obviously, though, anything outside of Starling couldn’t be added to a Feathers container. I think we both had the same philosophy when building our separate container architectures here, but MadComponents has the advantage of history on its side.


    Thank you again for the feedback. I appreciate that there’s a competitor to Feathers out there. It keeps me focused on what developers actually need and less on things that are simply fun to implement. I’m always impressed when I see your simple XML layouts and your advanced components like data grids and charts. It’s no easy task to build those components.

    I would also like to add that I have suggested MadComponents more than once to developers who were clearly unhappy with Feathers. Everybody has their own coding style, and not all frameworks will be a good fit. I always try to reach out to anyone who says that they dislike Feathers. Not to convince them to come back, but to simply ask for an honest account of what didn’t feel right to them. I try hard to understand workflows that are different than mine. It’s always my goal to balance certain opinionated defaults in Feathers with easy ways to break out and do your own thing. There’s always more work to do, of course, but I feel that Feathers is moving in a good direction. I don’t expect to make everyone happy, though, and if someone can use MadComponents and thrive, that’s awesome.

    I hope that MadComponents and Feathers can both continue growing for more years to come. Choice is important, and I fully agree Adobe should try to find more ways to highlight alternatives to the libraries that they support. I’ll try my best not to stay silent about MadComponents when it feels appropriate to give praise or to admit that Feathers needs improvement. Honest communication with the community breeds credibility, and greater openness will help steer the Feathers roadmap in the right direction. The best competition is when we can both challenge each other to do better. I took a moment to review each of my answers above to be sure that I was giving MadComponents the recognition it deserves.

    • Daniel Freeman / Jan 27 2015 2:55 am

      To clarify: The ten second embedded font delay was for a list of labels. I should have said “each row label”… I’ll go and edit what I wrote.

      • Josh Tynjala (@joshtynjala) / Jan 27 2015 4:18 pm

        It’s likely that the developer incorrectly disabled layout virtualization in the list. As you know, that’s a good way to hurt performance with any UI framework. However, he may have failed to set a height or maxHeight on the list instead, causing the list to grow large enough to show every item in the data provider. Regardless, it would take hundreds of item renderers created at the same time to cause a delay like that. A list kept within the bounds of the stage isn’t going to show more than 10-20. A one second delay is out of the ordinary. A ten second delay is so extreme that something was clearly misconfigured. You have been given an incorrect impression of the typical performance impact that Feathers deals with when drawing embedded fonts to a texture.

      • Daniel Freeman / Jan 28 2015 2:25 am

        I’ll pass that on. I believe it was a long list. Of course, it is situations like this where you can expose such design decisions in a simple way, in the XML layout language.

        My own experiments with a Stage3D Framework were also hampered by the display-list -> texture upload speed. But I was attempting to deal with images the size of pages (though, comprised of small tiles), and effects that swiped though multiple pages.

  3. Alhadef / Jan 30 2015 8:06 am

    I have carefully read your conversation with Josh. He said 10 sec for display was too much. That bothered me. I spent a good part of the night to redo my tests. In fact latency comes from my Hebrew sorting procedure. I did not think to do sorting on character strings could take as much time. This time, I precompiled data after the sorting in json files to best match with feather hierarchical collection. And the result is stunning.

    Sorry Josh, sorry Daniel

    But.. In my case. I develop multi plateforme of education applications. The traditional display list is sufficient and much easier to integrate many elements. It’s easy to work with illustrator and flash CC. It’s easy to scale.

    I’m so happy that Daniel thinks to introduce FTE labels (arabic,hebrew,chinese…). So next time I think i will use Mad for my app. A light and fast UI for regular display List for mobile and desktop is essential (flex is lot too havy and he did’nt work with FTE on mobile) .

    Sometimes I need to include in the application of small, fast games and there starling feather and are very convenient.

    Sometimes when i need to display a lot of text. I use the WebView to display the html. I dream about an HTML/JS UI that can sends AS3 events.

    Flash is not dead at all.

    I love Flash and AS3 because it allows you to work with the best in each case:
    Multimedia -> AS3,display List, flash CC, illustrator….
    Games -> AS3,Starling/Feather/Stage 3D
    rich text -> HTML,CSS,JS

    I wish that Daniel and Josh have a similar way to design flash UI. This makes it easy to swap display List and Stage 3D as required. .

To discuss MadComponents/MC3D, join the Facebook group!

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: