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.

Would MXML (and binding) support for Feathers improve your team's productivity? Enough that your company would sponsor its development?

— Josh Tynjala (@joshtynjala) January 23, 2015

Jumped into the code for the Apache Flex MXML compiler yesterday. Figured out some of the things I could modify to support Feathers binding.

— Josh Tynjala (@joshtynjala) January 23, 2015

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.

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.

The first version of Feathers isn’t without its architectural headscratchers. Some extra boilerplate here, a little manual hand-holding there to make the components do what you want. You can usually get the job done, but sometimes, it takes a little more work than you’d prefer.

Image Credit: Blueprint by Will Scullin

Over the last year or so, I’ve been listening carefully to all of the feedback posted to the forums and in the issue tracker. I frequently ask myself a number of questions. Where are the common pain points? What features do people seem to ask for help with the most? What can I address right now, and what needs to wait until later?

In many cases, I can improve documentation, fix bugs, and add minor features that won’t break the existing apps that you’ve developed. Other things need to wait until a new major version of Feathers because they’ll end up breaking too many things for too many people. Sometimes, I simply need time to understand the problem better, or I need to get more feedback. I hate telling people that something can’t be done, and I wish I could always fix issues sooner instead of falling back on technical explanations for why Feathers works a certain way. However, a better architecture can’t be built overnight.

Several months back, I decided that instead of working on Feathers 1.4, it was time to make the leap to Feathers 2.0. I felt like I’d put enough thought into a number of common requests, and I felt confident with my plans for addressing them architecturally. In some cases, if I waited much longer, I’d probably never bite the bullet and get it done. It was finally time to break stuff, but (hopefully) in a good way.

The beta of Feathers 2.0 is coming in the near future, after I wrap up some final details (including writing preliminary documentation for some of these bigger changes). Until then, here’s a little preview of just a few things that you can expect to improve in the next version of Feathers.

Less updateItemAt()

When you change a property on an item in a list’s data provider, you either need to have the item dispatch an event to notify the item renderer of the change, or you need to call updateItemAt() on the ListCollection to force the item renderer to update. Most people opt for calling updateItemAt(), since it is more convenient.

One place where things get a little hairy is when you want a list to display a new ListCollection, but some of the collection’s items are duplicated from the list’s previous ListCollection. In Feathers 1.x, if you changed some properties on those duplicate items, the item renderers wouldn’t detect those changes. You would need to call updateItemAt() on the new ListCollection for each of the duplicate items, which usually involved looping through the entire collection because it was too annoying to figure out the exact index of each duplicate item:

var collectionLength:int = collection.length;
for(var i:int = 0; i < collectionLength; i++)
{
	collection.updateItemAt(i);
}

In Feathers 2.0, that won't be required. When you pass in a different ListCollection, the list will automatically force all item renderers to update, even if they're asked to display the same item. This change shouldn't affect performance either. If the duplicate items haven't actually changed, the item renderers can update more quickly than they would if they were asked to render completely different items.

To be clear, if you don't change the dataProvider property, and you change a property on an item, you still need to call updateItemAt(). ActionScript doesn't have any way to observe a property to see if its value changes. This simply helps those cases when you want to pass in a completely new ListCollection, and the list can automatically assume that it should forcibly update its item renderers.

Validate components off the display list

Previously, a Feathers component needed to have access the stage before it could initialize and validate. Sometimes, though, you want to use a component in some way without adding it to a parent. For instance, you might want to get its dimensions, or maybe you want to draw it to a render texture.

In one odd case, the order that Starling dispatches Event.ADDED_TO_STAGE events made it so that components that were added to their parent in the parent's constructor couldn't validate right away, even though they were technically added to the stage already. Most people didn't run into this issue, but it was frustrating for those that were used to a workflow where they added children in the constructor.

In Feathers 2.0, you can call validate() on a component at any time. Even if it isn't on the stage yet. If it hasn't initialized, it will do so immediately, before it validates.

var button:Button = new Button();
button.label = "Click Me";
button.validate();
trace( button.width, button.height ); // output: 130 58

A new theme architecture

Feathers 1.x had a couple of pain points when working with themes. Themes can be a little burdonsome for some developers because once you opt into the theme architecture, you need to do all skinning inside the theme to avoid having it override your properties. On the other hand, avoiding themes entirely can be painful too because you need to do all of the skinning manually with very few helpful defaults.

With Feathers 2.0, themes are more tightly integrated into the framework, allowing more flexibility in important areas. However, themes remain completely optional. If you want to skin the components by setting properties directly, I will always support your ability to handle it your way. Requiring themes would make Feathers less modular, and more rigid, and that's the opposite of my goals for the project.

Skinning subclasses with themes

Over time, I discovered that a number of ActionScript developers prefer to subclass components to create specialized versions of these components with common property values. For an overly-simplified example, you might create a SubmitButton class, and in the constructor, you might set the label property to "Submit".

public class SubmitButton extends Button
{
	public function SubmitButton()
	{
		super();
		this.label = "Submit";
		// you'd probably set more properties too
	}
}

If you were using a theme in Feathers 1.x, you'd need to inform the theme that the SubmitButton class should use the same skins as the Button class. If you make subclasses like this often, updating the theme every time becomes annoying very quickly.

On the other hand, some subclasses need to have very different skins from their superclass. For instance, the Check component is a subclass of the Button component because it behaves the same. It doesn't look like a regular button, though. If you created a custom component in this way, you'd definitely need to tell the theme how to skin it.

Another workflow usually involves calling a function to set common properties on a component. A submit button might be created by calling a static function like CommonComponents.createSubmitButton() that just creates a regular Button and sets some properties before returning:

public static function createSubmitButton():Button
{
	var button:Button = new Button();
	button.label = "Submit";
	return button;
}

With this workflow, subclasses are basically only used for significant changes that result in a component that needs different skins. In other words, the theme needs to be informed about every subclass, but subclassing doesn't happen very often.

The original theme architecture was designed with the second workflow (the one that doesn't subclass much) in mind. This architecture places a high burden on the first workflow because I figured most developers tried to avoid inheritance, like I usually do. As Feathers reached a wider audience, I eventually determined that I needed to support the first workflow better. Not everybody follows or agrees on the same best practices.

With themes being more tightly integrated into the components, I made it so that theming is inherited by subclasses by default. If needed, subclasses can opt into requiring separate skins. Now, the SubmitButton subclass workflow rarely needs to worry about the theme while the CommonComponents.createSubmitButton() function workflow needs to add a couple lines of code inside subclasses as a hook for the theme, but it's an uncommon situation. A nearly insignificant burden on the second workflow eases a very large burden on the first.

Excluding a component from the theme

In an ideal world, all of the styles for an HTML page will go into a single, well-structured, external CSS file. In practice, that doesn't always work out perfectly. Styles seem to slip into the HTML or JavaScript much too commonly. Similarly, in that ideal world, a Feathers theme would contain all skinning code required for an app. However, sometimes, you just want to tell Feathers, "Hey, don't give the theme access to this component. I want to skin it myself."

In Feathers 1.x, you couldn't easily set skins on a component without the theme replacing them later. It forced people to immediately learn how themes worked internally instead of allowing them to ease into it.

All components in Feathers 2.0 will have something called a style provider. Think of a style provider as a component's link to the theme. When the component initializes, it asks the style provider to set the skins.

A component isn't required to have a style provider, though. The chosen theme provides one by default, but you can get rid of it before the component initializes. Telling a theme not to skin a button is as easy as setting the style provider to null:

var button:Button = new Button();

// no theme, please!
button.styleProvider = null;

// now set some skins!
button.defaultSkin = new Image( texture );

this.addChild( button );

Once you've done that, you can set any property that you want, and you'll be confident that the theme won't interfere.

Beyond Feathers 2.0

These changes should ease some of the biggest pain points people have with Feathers. That said, as you all get comfortable with the new changes, I don't doubt that different architectural issues will be uncovered now that I've cleaned up the bigger ones. I want to fix those issues too! Please, never hesitate to start a thread in the forums or to open an issue on Github. I may not be able to address every issue right away, but your feedback will not be forgotten. I want to make Feathers better for all Starling projects, including both games and apps.

A beta build of Feathers 2.0 will be available in the coming weeks. I'm looking forward to your feedback — both positive and negative. If you'd like an extra early peek at the new 2.0 source code, you can download the Feathers master branch on Github. Remember, this isn't a stable build that everyone should try. It's pre-beta code that may contain bugs. Use at your own risk, and have some fun!