Feathers MXML internals: abstracting away Starling initialization

In Starling projects, we need a startup class that extends flash.display.Sprite or flash.display.MovieClip. In this class, we create a starling.core.Starling instance, and we set up behavior for things like resizing the view port and pausing our app or game when it goes into the background. For many projects, this class looks mostly the same. When I create a new project, I usually just copy the startup class from an existing project and modify it to pass in a different Starling root class. It would be ideal if I could simply abstract this bootstrap code away instead.

Flex applications require a significant amount of bootstrapping code too. We don’t deal with any of it, though, because the Flex SDK compiler abstracts much of it away. We can simply create a simple MXML file extending spark.components.Application:

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" 

However, behind the scenes, a Flex SWF starts up with an mx.managers.SystemManager instance as the root display object. The spark.components.Application instance isn’t the root. It’s a child. Once the SWF fully loads and the Flex framework is ready, the SystemManager instantiates the Application and adds it to the display list.

You don’t need to worry about this bootstrapping code in Flex because the spark.components.Application class defines the following metadata:


As long as you subclass Application this metadata will tell the compiler that your class should be included on the second frame of the SWF, and the class defined in the factoryClass should be the root display object instantiated when the SWF starts up. Once the first frame loads, the SystemManager can display a preloader while the second frame is loading. When the second frame is ready, the SystemManager instantiates the Application and adds it to the display list.

[Frame] metadata isn’t restricted to Flex applications. An ActionScript project built with the Flex SDK compiler may use [Frame] metadata too. In fact, some developers may have already used this metadata with Starling projects to create a preloader for SWFs that run in a web browser.

While it isn’t a strict requirement for supporting MXML in Feathers, I want the new project experience to be as simple Flex’s. We shouldn’t need to manually instantiate Starling and set up code to resize the view port and things. It should be part of some hidden bootstrap code. A new Feathers MXML application should look something like this:

<?xml version="1.0" encoding="utf-8"?>
<feathers:Application xmlns:fx="http://ns.adobe.com/mxml/2009" 

The upcoming Feathers MXML SDK will include a feathers.core.Application class that takes advantage of [Frame] metadata.

package feathers.core
	import feathers.controls.LayoutGroup;


	public class Application extends LayoutGroup
		public function Application()
			this.autoSizeMode = LayoutGroup.AUTO_SIZE_MODE_STAGE;

All the bootstrapping happens behind the scenes in this feathers.core.StarlingBootstrap class, which serves a similar purpose as the Flex SystemManager. However, instead of initializing the Flex framework, it sets up Starling instead. It passes our subclass of feathers.core.Application to Starling to use as the root class. It listens for the native stage Event.RESIZE to resize the Starling view port and stage. It looks just like any normal startup class for a Starling project. Not much different than Starling’s Scaffold_Mobile sample or the Feathers ComponentsExplorer example.

The main difference between StarlingBootstrap and other startup classes is that StarlingBootstrap must have a method named info(). The compiler generates a subclass of StarlingBootstrap and overrides info() to make it return an object with a number of properties. This object stores things like the name of the Starling root class and, optionally, a Feathers theme. You can see a slightly simplified example of this generated subclass below:

public class _MyFeathersApp_feathers_core_StarlingBootstrap
	extends feathers.core.StarlingBootstrap
	public function _MyFeathersApp_feathers_core_StarlingBootstrap()

	private var _info:Object;

	override public function info():Object
		if (!_info)
			_info = {
				rootClassName: "MyFeathersApp",
				themeClassName: "feathers.themes.MetalWorksDesktopTheme"
		return _info;

You can see that our main class was named MyFeathersApp. A string representation is stored in the rootClassName property returned by the info() function. StarlingBootstrap uses getDefinitionByName() to access the Class:

var rootClassName:String = info()["rootClassName"];
var rootClass:Class = Class(getDefinitionByName(rootClassName));

Once it has the Class reference, StarlingBootstrap can pass it to Starling to instantiate when Stage 3D is ready. The compiler will automatically ensure that MyFeathersApp is compiled into the SWF, even though it is not strictly imported here.

Anyone will be able to read the ActionScript code that gets generated by the Feathers MXML SDK compiler. Similar to the Flex SDK, we will be able to add the -keep compiler argument to include a folder of generated ActionScript files in the same place as the compiled SWF.

Additionally, using the StarlingBootstrap class to bootstrap a Feathers MXML application won’t be strictly required. Custom [Frame] metadata may be added to any subclass of feathers.core.Application that will override its default metadata. This will let us provide a different startup experience, if needed. We might want to customize the stage size to support contentScaleFactor, for instance. Ideally, the bootstrapping mechanism should provide acceptable defaults for most projects, while keeping things as flexible as possible for more advanced requirements.

Twitter should natively integrate blogging

Recently, I’ve been noticing that some people on Twitter have been posting strings of multiple related tweets about a single subject. Maybe these have caught your attention too. They’re like little blog posts where the authors can go beyond the 140 character brevity enforced by Twitter. It’s an interesting hack of Twitter’s restrictions that is both clever for helping you talk to your audience a little more in-depth, but it’s also annoying because a single author can dominate your feed.


The first thing I do after publishing a new post on my own blog is post a link to it on Twitter. A lot of my blog’s traffic comes from my followers and their retweets. Similarly, for me personally, Twitter is a wonderfully valuable resource for reading material. Twitter helps me stay up-to-date on the latest news about my favorite technologies, and it helps me keep my audience up-to-date about my personal projects.

A blog requires a certain amount of maintenance. If I install WordPress or something like it on my website, I need to keep it updated. Even if someone else hosts everything for me, I still feel an obligation to post often enough to keep a formal blog. All too frequently, blogs are set aside while we focus on the other work. After a while, we feel guilty, and it becomes too easy to abandon them because we’re a little embarrassed.

Today, I don’t blog as often as I did before Twitter was introduced. It’s easy to feel satisfied from sharing an informal opinion with a quick tweet. At least I said something – even if it’s only 140 characters long. Many of those tweets deserve to be expanded, with a deeper look at the subject, but a quick tweet or two is more convenient. I think these strings of tweets are scratching the blogging itch for many authors, while keeping things a little more informal.

Twitter is about bite sized content, though, and I can’t help but feel like the author is being rude by posting many tweets in succession (even if it’s interesting content that I would otherwise enjoy). It’s a little spammy when someone takes over my feed like that. Many people on Twitter follow many different sources, and we scan through a lot of dirt to find the gems. I love that I have the choice to dig in if I’ve been hooked by a good title or summary, but I can quickly bypass something that doesn’t sound interesting. Multiple tweets in a row from the same author force me to briefly dig in when I don’t necessarily want to.

Authors can benefit from staying within the Twitter ecosystem. That’s where their audience is finding content, so make it convenient for the audience to read your content. Twitter benefits from people staying within the Twitter ecosystem because those people aren’t going elsewhere. However, the 140-character format required by Twitter doesn’t work very well with the type of content that some authors want to write. I think that Twitter can fix this missing piece, though.

Embrace and encourage common behaviors

Twitter should embrace how people are posting strings of related tweets, and how bloggers share links to their posts on Twitter. People want to say more to their audience than Twitter allows, and it seems that some prefer not to leave in order to say it. The company should be asking itself how it can serve that content directly within the Twitter app and website. The more time people spend on Twitter, the more the company benefits.

How do people share interesting articles (their own or written by others) on Twitter? They usually post the title (or a quote) along with a link. How are blog post editors usually designed? Two separate text boxes. One for a title and the other for the body of the post. Wouldn’t it be easy to limit the title to 140 characters? That’s enough to fit into a tweet. All Twitter needs to do is give a blog post some kind of special decoration to show that this tweet includes more content. Anyone who is interested can simply tap or click to read it. A simple button at the beginning and/or end of the post can bring you back to the main feed where you left off.

How these blog posts integrate with Twitter as we know it today is important. The 140 character limit is also one of Twitter’s best features. The full body of a blog post wouldn’t appear on someone’s main feed. It wouldn’t take up more space than a regular tweet. What we see in our feeds are the titles, limited to 140 characters. It will be clear that there’s more to read, but you see the full text only if you want to read it. It becomes the best of both worlds.

Comments and retweets

Commenting is available for free, of course. Anyone would be able to reply to a blog post with a regular tweet. Twitter could go a step further and allow a reply to a blog post that is another blog post. Many people complain that Twitter only allows shallow discussions because you’re limited to 140 characters, and it’s hard not to speak bluntly. With a longer blog format, discussions can be more subtle and go into more depth.

Often, someone sharing an article wants to quote part of it that is especially relevant. Retweeting a Twitter blog post doesn’t necessarily have to be limited to the title that the original author chose. What if you could pick a quote in the middle and retweet that instead of the title? A retweet with a quote would still open up the same full-length blog post, but you’d be tailoring the article to more closely match your audience’s interests.

But what about…?

In the past, companies have tried to provide products that would let you post longer tweets. Obviously, they weren’t all that successful. However, if blog posts were natively integrated into Twitter, I believe that many would embrace them. By making it easy to share and discuss (with retweets and longer replies), and by making it easier to go back and forth between blog posts and back to the feed, the smoother and more engaging experience would allow Twitter to succeed where others couldn’t, in my opinion.

The main issue that Twitter would need to address is people abusing these new blog posts for short tweets that they’re too lazy to edit down to fit within 140 characters. A Twitter feed filled with a bunch of 150 character blog posts would get annoying real fast. Maybe a blog post would require a minimum number of characters, like 500-750. Enough that 4-5 regular tweets would have been needed to fit all of the text.

For a better Twitter

While I’ve frequently talking about keeping the main feed on Twitter looking mostly the same, I think that adding blogging would still change the way that Twitter is used overall. Some people today say that they don’t “get” Twitter. More in-depth content would help reveal the hidden value of this service. Discussions are currently artificially limited. They’re shallow and lack subtlety. I think that this change would encourage people to talk to each other more instead of simply promoting themselves. It would clear up common misunderstandings caused by Twitter’s communication barriers. For those of us that like blogging, I think it would encourage us to do it more. We’d feel less guilty when we don’t blog for a while because blogging would become a part of the same service we visit daily. We’re frequently on Twitter, so we haven’t abandoned anything.

Adding support for MXML in Feathers

A couple of weeks back, you may have seen my tweets suggesting that I was interested in adding support for MXML to Feathers. I spent an afternoon digging into the source code for the Apache Flex compiler, and it became clear to me that I know where and how to modify the compiler to add support for Starling and Feathers.

Earlier that day I made some changes to the Java code for the compiler, rebuilt the binaries, and dropped a modified Apache Flex SDK into Flash Builder. The compiler errors that were normally caused by attempting to use binding with Feathers components went away, and I verified the code generated with the -keep compiler argument. It still needed work, but it looked good. I knew that I could do this.

Feathers MXML logo

I understand that some developers have no interest in using MXML with Feathers. Others find it essential for the types of enterprise apps that they want to build. It’s important for me to find the right balance helping both types of developers. Not only at the technical level (keeping performance and backwards compatibility in mind), but also by managing my time fairly. With that in mind, I felt that working on MXML support needed to be a separate effort from my day to day work with the ActionScript UI components. I have some free time that normally goes to various side projects or consulting, but I’d love to spend extra hours making Feathers better. Those other projects help pay the bills, though, so some extra funding is important. That’s why I was looking for a sponsor, and I knew that many developers working on enterprise apps would see increase productivity with MXML support, so it seemed like the right approach.

A number of eager developers suggested Kickstarter. I’m totally open to crowdfunding advanced Feathers components and tools (I have more ideas for the future), but I wanted to see if a company would step forward — similar to Adobe — to become an official sponsor of Feathers. Not long after I posted those tweets, the folks at YETi CGI contacted me, and we set up a call. We quickly discovered that our shared desires to improve and promote the Flash and AIR ecosystem align very well.


Today, I’m happy to announce that it’s official: MXML support for Feathers is going to happen. I have lot of work ahead of me, and I’ll be sharing my progress in the coming months. Keep watching this blog, and follow me on Twitter for details. If you have any questions, check out the FAQ that I put together below. Thanks!

Frequently Asked Questions

What features of MXML will be supported?
You will be able to add components as children of containers, set properties, listen for events, add [Bindable] metadata, and use curly braces to bind data to properties.
What features of MXML will not be supported?
Currently, I have no plans to support adding custom states to components in MXML. However, I am always open to community feedback, and if adding custom states is something that a lot of people ask for, that’s something that I can work on after the first release is finished.
Modifying the compiler? This project sounds like a lot of work. As a lone developer, can you do this on your own?
This project is certainly not trivial. However, I have studied the relevant compiler source code in detail (and the ActionScript classes that are used for binding), and I know which parts need modifications. I already built some simple prototypes. I successfully modified the generated ActionScript to remove some compiler errors, and I switched some of the code to use Starling or Feathers APIs instead of Flex APIs. There’s still a lot that needs to be done. I won’t deny that. I expect to spend at least three months (part-time) getting it to a feature-complete beta stage. However, I’m very confident that the conversion from Flex to Feathers will go smoothly and at a steady pace.
Will you spend all of your time adding MXML support while the rest of Feathers gets ignored?
Adding MXML support to Feathers will not take time away from any other aspect of Feathers. I normally have free hours every month where I work on side projects that have nothing to do with Feathers. I wanted sponsorship for this project so that I can allocate some of those extra hours to Feathers instead. In other words, I will continue working on the Feathers ActionScript components just as much as I have in the past.
What if I don’t need MXML support? I just want to keep using Feathers the way that I do today with pure ActionScript.
Using MXML with Feathers will be completely optional. Your existing ActionScript code will not need to be changed at all.
Will using MXML have a performance impact? Will there be any kind of performance impact on projects that don’t need MXML?

First, let me be clear that if your project doesn’t require MXML, Feathers will behave and perform the same as it does today. If I couldn’t make that promise, I wouldn’t be interested in going forward with this project.

Most features of MXML are simply a convenient abstraction to avoid writing a lot of ActionScript. The ActionScript code generated behind the scenes by MXML for things like creating components, adding children to containers, setting properties, and listening for events will look very similar to what you would write when doing those things yourself. I don’t expect any performance impact from using these basic features.

Data binding can involve a lot of event listeners, and it may require some extra garbage collection when it gets used. This may have a small impact on performance, if you’re not careful, at least on mobile. However, data binding in Feathers may end up performing better than it does in Flex because we can take advantage of Starling’s event pooling.

Will there be any preview builds?
Yes. I expect to release one or more preview builds as progress is made. They will be available to anyone who wants to try them. These builds may be unstable, and some features may still be missing. However, anyone will have a chance to give them a try and offer feedback. Once MXML support is feature complete, I expect to release a beta build that a larger audience will be interested in. After all the major bugs are worked out, I’ll release the final stable version.
Who is sponsoring this project?
I’d like to thank YETi CGI for their generous support.

Have any other questions or concerns? Please feel free to ask in the comments.