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.

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,

<tabPages>
   {PAGE1}
   {PAGE2}
   {PAGE3}
</tabPages>

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.

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:

<navigation>
   {PAGE1}
   {PAGE2}
   {PAGE3}
</navigation>

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:

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

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:

<data>
     <item label="page 1"
        ldpi={getQualifiedClassName(ICON_LD)}
        mdpi={getQualifiedClassName(ICON_MD)}
        hdpi={getQualifiedClassName(ICON_HD)}
    />
 …etc… etc….
 </data>

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">
    <firstname>label</firstname>
    <lastname>label</lastname>
    <photofile>image</photofile>
    <title/>
    <id/>
</model>

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"/>
</vertical>;

Conclusions

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.

links

Feathers:  http://feathersui.com MadComponents: https://www.facebook.com/groups/madcomponents github: https://github.com/danfreeman/MadComponents video: https://www.youtube.com/watch?v=CMf2XGRhkOk