Frequently asked questions about Feathers.

Feathers was created by Josh Tynjala, a veteran Flash developer who has been working in the Flash eco-system for nearly a decade. He has years of experience creating custom UI components for other developers to use, and he has also built a number of full applications using frameworks like Flex. Josh went indie a few year back, and he tried his hand at creating casual games for both web and mobile. Feathers originated from the need for UI components that both perform well on mobile and can be easily skinned in many different ways.

A bird's feathers provide functional and aesthetic benefits that I think closely match how user interface components can enhance a graphics library like Starling Framework.

Visit the Feathers website for the most recent stable version of Feathers.

Visit the Feathers project on Github for the newest Feathers code that will eventually become a part of the next stable version. Watch out for bugs!

Though Feathers is an independent open source project, development of Feathers is supported by Adobe. As a first step in this partnership, Feathers is included with the Adobe Gaming SDK, along with Starling Framework and other tools for developing games with Adobe technologies. Looking forward, Adobe plans to integrate Starling Framework and Feathers more tightly into its upcoming design and development tools.

Please visit the Feathers forum. Be sure to try a couple of searches to see if someone else has had the same issue. Maybe your questions have been answered already. If not, then feel free to start a new thread.

Feel free to report bugs and request features on Github at any time.

Pull requests are welcome for bug fixes. Before submitting a pull request, be sure to take a look at the Feathers Coding Conventions for Contributors. All code in Feathers is expected to match the coding style described in that document. Contributions that don't follow the coding conventions may be given a lower priority due to the extra effort required to reformat your code.

For new components and other major contributions, I encourage you to create your own project on Github as an extension to Feathers or as a fork. Send me a link, and I'll be happy to share it with the community. If enough developers show interest in your project, and there's demand for including it in the core Feathers library, we can discuss the details further.

Feathers uses Adobe AIR, which can create completely standalone, native apps on iOS, Android (including Barnes & Noble's NOOK devices and Amazon's Kindle Fire), Windows, and Mac OS X. It also works with Adobe Flash Player in the browser.

Not anymore. Adobe AIR's captive runtime feature lets you bundle everything you need into one package. It makes your app's install size a little bit bigger, but this isn't any different than linking in third party frameworks for graphics, audio, and scripting that you might need to build any kind of native app.

If you prefer to use the separate runtime that Adobe provides, that's remains an option too. iOS support always requires the captive runtime, due to Apple's rules for distributing apps in their App Store.

Typically, the most recent version of Adobe AIR or Adobe Flash Player is supported. Feathers may still work with older versions, but it's not guaranteed. Be sure to check the README file for the current requirements.

Generally, the version of Feathers that is available from the Feathers website will work with the most recent version of Starling Framework that is available from the official Starling download page. Older versions of Starling may remain compatible with the latest version of Feathers, but they are not officially supported.

Use the latest, bleeding edge code from the Feathers Github project at your own risk. This code is in development, and it may be unstable at times. The newest code from the Starling Github project may be required to use it if Feathers has begun using new features or if anything in the Starling APIs has changed. Check the Feathers README file to see which version of Starling is currently required by the unstable version of Feathers.

In other words, why themes? Well, ideally, I'd love to provide a basic set of skins for all components that get applied automatically. These skins would have configurable styles, like colors, gradients, corner radiuses, padding, and all that useful stuff. The sort of thing a lot of developers love about the styleable skins provided in Flex 2-3. Decent for anything that doesn't need a skin created by a professional designer, but easy enough to customize that a developer can differentiate the look of his or her app a little bit, if needed.

However, that sort of flexibility provided by the classic Flash software-based vector renderer is not really available on a GPU. The GPU is heavily optimized for drawing triangles with textures. A textured quad like starling.display.Image is an ideal Starling display object to use as a skin. However, it's rather static in nature and modifying bitmaps at runtime to customize individual controls is a rather expensive task. It would involve creating separate textures (which can hurt performance), but a texture atlas is always recommended. You can draw vectors to bitmaps and generate texture atlases at runtime, but setting up an easy system that everyone will want to use (and can pick up easily) is something that I, personally, don't know how to do right now.

If we're sticking to bitmaps, a “default” skin on every component will offer little to no customization. Most likely, it would bulk up every Feathers application with extra code and embedded assets because it would be difficult to separate this default skin from the rest of Feathers. Not necessarily impossible, but more effort than simply copying some classes into your project (like you probably already do with many libraries) and adding a single line of code to instantiate a theme.

Nothing says that you need to use one of the example themes included with Feathers, though. In fact, I encourage you to create your own themes. Those examples are just what I called them, examples. When I was a game developer, I created a custom skin for every game I ever made. A game with the default iOS or Android skin can still be fun, I guess, but I know I'd be less likely to even consider trying that game than a similar one that has a more unique look and feel. Similarly, even though I created the “Metal Works” theme for Feathers, I don't think I'd ever use it for a game. Most players expect a game to be more immersive than a regular app and to provide a unique atmosphere. Metal Works and other example themes are there to show you one way to can skin your application.

Even with a “regular app”, there are always skinning details that need to be customized in ways that can be unique to your specific app. All example themes can be extended for this reason. If you're working on an app, rather than a game, a few custom skins added to the defaults might be the right way to go. Feel free to use the example theme PSDs files to add your own custom skins in the same style. Then, rebuild the texture atlases and use those new sub-textures in a subclass of the original theme.

Of course, if you don't like the idea of themes at all, feel free to skin your components directly. I really love themes because it puts all of the skinning code in one place and separates it from the “business logic” of the rest of the app. For a game, you could say that you're separating it from the game mechanics or rules, if “business logic” sounds to stuffy for you. This separation helps keep me organized and it prevents confusion because each “unit” of code has a more focused purpose.

A few tips for common issues you may encounter as a new Feathers user.

Have you instantiated a theme? If not, have you provided your own skins? The Feathers components don't have default skins. Default skins would add unneeded extra filesize to your projects. On mobile, every byte counts, especially since Adobe AIR's captive runtime is rather large. Take a look at Getting Started with Feathers to see how to instantiate a theme. It's only one line of code.

Have you instantiated a theme? If not, have you provided your own skins? The Feathers components don't have default skins. Default skins would add unneeded extra filesize to your projects. On mobile, every byte counts, especially since Adobe AIR's captive runtime is rather large. Take a look at Getting Started with Feathers to see how to instantiate a theme. It's only one line of code.

The Feathers themes that are included as examples scale the skins, fonts, and other assets based on the device's screen DPI (also known as PPI) to ensure that the components and text display at the same physical size (as in inches or centimeters) on different devices. This value is reported by the Flash runtimes as Capabilities.screenDPI. Some IDEs don't seem to inform ADL (AIR Debug Launcher) that a specific device needs a custom DPI value to be simulated properly. The instructions below should help you fix this issue in many IDEs.

Ensure that the project type is an ActionScript Mobile Project. You can choose the simulated device in the Run Configurations and Debug Configurations dialogs.

Unfortunately, Flash Professional does not provide a way to customize the DPI of the testing environment to properly simulate a mobile device. Moreover, Flash Professional has no capability to test multiple screen resolutions without adjusting the stage width and height of your FLA file manually.

To properly simulate mobile devices with Feathers projects created in Flash Professional, it is recommended that you run ADL from the command line. Please follow the instructions for Command Line specified below.

Ensure that the module type is an ActionScript application for AIR mobile platform. You can choose the simulated device in the Run/Debug Configurations dialog. For IntelliJ IDEA 11, follow the instructions below for Other Environments.

Add -XscreenDPI [dpi] to ADL's command line arguments. Your IDE should expose a field for this somewhere. Replace [dpi] with the appropriate DPI value for the device that you want to simulate. For example, to simulate the DPI of an iPhone with a Retina display, you would use -XscreenDPI 326. The Wikipedia article List of displays by pixel density provides a useful list of DPI values (and screen resolutions) for many different devices that you might want to simulate.

You can run AIR Debug Launcher from the command line to simulate various mobile devices. A couple of important command line arguments will allow you to specify any device's screen resolution and screen DPI.

• The -screensize argument will specify the device's screen resolution. A number of predefined strings are available to simulate popular devices. For instance, you can use iPhone5Retina to simulate an iPhone 5 with Retina display. The full list of predefined device strings is available in the ADL documentation. If you want to simulate any device that doesn't have a predefined string, you can also pass in numeric values for the screen dimensions, in pixels. For example, the same iPhone device can be simulated by passing in 640×1096:640×1136 instead. The first set of dimensions is when the app is displayed with the OS chrome (status bars and things), and the second set of dimensions is when the app is displayed full screen.
• The -XscreenDPI argument will specify the device's screen DPI. For example, the DPI of an iPhone 5 with Retina display is 326. This is the value that is used to scale the skins in the Feathers example themes.

You will also need to pass the path to your AIR project's application XML file. Here are two examples of running ADL. The first uses a predefined device name and the second uses numeric values for the screen resolution.

adl -screensize iPhone5Retina -XscreenDPI 326 YourProject-app.xml
adl -screensize 640x1096:640x1136 -XscreenDPI 326 YourProject-app.xml

The Wikipedia article List of displays by pixel density provides a useful list of DPI values (and screen resolutions) for many different devices that you might want to simulate.

Feathers components use a system of invalidation to delay expensive redraws for a short time so that you can change multiple properties all at once. If you haven't set the width and height explicitly, they will automatically resize themselves to a set of “ideal” dimensions. However, this doesn't happen until they validate/redraw. You can short-circuit the delay on validation, and make it happen immediately, by calling the validate() function yourself.

label.text = "hello";
trace( label.width );	// 0
label.validate();		//draw yourself, now!
trace( label.width );	// 150 (or an appropriate value for the font you chose)

Please note that the component must be on the display list for validate() to work. A call to validate() does nothing if the component doesn't have access to the stage.

Please see the explanation of Draw Calls in the article on text renderers.

Starling filters aren't compatible with the clipping rectangle. You need to turn off clipping.

list.scrollerProperties.clipContent = false;

To more information about Feathers, return to the Feathers Documentation.