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.
Awesome đ
Awesome !
one question is will feathers MXML can be use in flex design mode?
It’s unlikely that the Flex Builder design view will work with Feathers. I doubt that it can run Stage 3D, and even if it can, there are probably a ton of Flex-specific things in there. If there ever is to be some kind of visual layout editor for Feathers, I’ll need to build it from scratch.
We were surprised at the news.
Nice!!Nice!!Nice!!!~
Wow, that’s an amazing development, Josh! Congratulations on this deal â and a huge THANKS to YETi CGI for making this possible. I know that countless Feathers & Starling users will be excited about this! If there’s anything I can do within the Starling core to help, be sure to send me a note, I’d be happy to help.
Can’t wait to play with it. Great that you have found a sponsor!
is a great idea! MXML is the winning move!
The more you work on this, the more it seems like this is what Flex should have been like all along. Great work!!!
Wow, I love progress.
Great News! Thanks to Josh & YETiCGI.
Hey Josh,
Just an funny idea in my mind, what if the starling/feathers/as3-signals community work with Apache group to replace the UIComponent, flawed event system, data binding, and performance nightmare once and for all?
If Starling and FeathersUI is part of the core Flex SDK, wouldn’t it awesome?
By the way great thanks to YETiCGI for making this happen.
This is awesome, i’ve been waiting long time for this. Great job, you are in the right direction.
Thx Jhos & YETiCGI.
This is so nice. The creation from xml interface was the one thing I found better in coding in native environment instead of using feathers for mobile apps. This news is a game-changer for mobile apps creation imho
Great news that you still have the passion for Feathers, that you tackle such a big task.
Congratulations Josh! These are great news. I really like Flex for building RIAs and with Feathers and Starling the performance of them in mobile devices will become really better.
Are you planning to make the basic components (button, slider, numeric stepper, etc.) similar to the already existing in Flex, or more like the ones of Feathers? And how about themes and skins? Will we be able to use the new skinning architecture of Feathers 2.0?
Thank you very much, we really appreciate your work!
You will use the same Feathers components in MXML that you use today in ActionScript. I’m not wrapping them in some kind of compatibility layer or anything like that. The MXML compiler will generate ActionScript using the exact same classes that you would use if it were a pure AS3 project. Skinning and themes will be the same too.
Hi Josh, it’s really cool idea to describe layout in mxml-style, but to my mind, there’s a disadvantage in fact that mxml compiles to AS3 code, so to update it, you have to recompile the whole application, but if you use some other format (e.g. xml) you may load and translate similar logic to code at runtime, what’s very important for mobile apps (cause you cannot load any as3 code at runtime for any ios-app, and there is app review period). Yes, it’s a bit more complex (or not) approach, but I think befenits are better then with mxml. You may add autocomplete and type validation to xml by define xsd-scheme, it works fine on our project. The other mxml feature is data binding and I guess it’ll not be popupar in mobile apps, because it involves hard calculations and decreases the whole perfomance.
I wonder what do you think about it?
It’s my opinion that if you are making significant changes to your app’s layout, having to get an update reviewed isn’t a big burden. If you’re just making minor tweaks, I don’t see a problem holding on to those changes until something else that’s a little more important needs to be updated too. I understand the convenience, of course. I just prefer the compile-time nature of MXML and how MXML components are simply ActionScript classes.
Feathers supporting MXML doesn’t stop anyone from creating an XML dialect for Feathers that gets parsed at runtime, if that’s something that they prefer.
I think data binding will very popular among the developers that choose to use MXML with Feathers, including on mobile. I never had performance issues using binding in Flex on desktop, but I understand why people are worried about trying to do the same on slower mobile devices. Probably the biggest bottleneck is the garbage collection required for event objects. I’ve spent many hours optimizing Feathers to avoid allocating objects that will trigger the garbage collector, so I know the impact that it can have. Thankfully, Starling supports event object pooling, so we’ll be able to bypass that whole issue completely.
Great! Thank you Josh for your responses.
Hey Josh,
I wrote most of the base cross compiler AS – > JS in Apache Flex, so I know a huge amount of the code base and the Falcon/MXML compiler. I just happened to be getting back into some AIR mobile stuff and using Feathers for the UI, great code BTW.
If you ever need any help on this compiler, I would love to help. I am still a PMC and committer and Apache but I have contributed since about 2013 I think. But as I said I am back in this neck of the woods after a lot of Android Java.
Mike
Thanks, Mike. I’ll keep you in mind if I need a hand!
Really exciting !! Hope as3 and its platforms get back its old fame.
Thank you for your great contributions.
Hi Josh Tynjala,
Thanks a lot for Astra. I am a Phd student in statistics and new in flash. I have a question:
Q: How can I change the color of bars in Astra Column Chart by using AS3 (SimpleColumnChart.fla example)?
Thanks in advance for your help
Best,
-Bistoon
On the ColumnChart, you can set the “seriesColors” style to an Array of uint color values. It’s been a very long time since I used the Astra components, but your code should look something like this, I think:
Thanks a lot,
I worked with Astra and it is enough for me. I was able to control charts (colors, embedFonts, AxisLabelRotation, dataTip and etc), but I still can not add the numbers (similar data label in excel) to the top of the bars or inside of pie chart. I need to show zero (or small) value in Column and Pie chart.
Excuse me if I ask my questions on this page. I hope this is my last question.
Best,
-Bistoon
This is the last question. I promise.
PieSeries has a showLabels style that you can set to true. You can use labelFunction to customize the text that is displayed by the label.
It appears that ColumnSeries does not have a way to display labels on each column. You could probably subclass it, though, if you wanted to try adding labels yourself.