Answer: Flex styling pwned!

So it’s leaked out on twitter that Ben Stucki, Ryan Campbell, Tyler Wright, and myself are working together on a new RIA component initiative. Taking a different approach than Open Flux, we are starting from scratch and building up fresh. We’re bringing together what we’ve learned from Open Flux and Stealth with the goal to release finished features and stable builds. We hope to provide something that we all can use in production. We haven’t announced the name yet, officially.

Ryan posted about using MXML without Flex last week. Though it isn’t for the new framework, the principle can be used for that framework. Maybe someday styling could be too. Today, I’m posting about using Flex styling without the Flex framework. I’ve taken the same example that Ryan posted and embellished. The components in there are Explanation of what is styled after the example.

Here’s the new MinimalComps.mxml source:

And the styles.css source:

The example looks very similar to Ryan’s, but notice differences including:

• the PushButton label is set from the stylesheet
• x, y, and spacing are no longer in the MXML on the VBox, they are only in the stylesheet
• Descendent selectors work
• #id can match the name property of DisplayObject
• There is no styling code built into the components. This styling is not intrusive and can work with any display objects.
• If you were to extend the IStylable interface provided, then you could also match against .stylenames and :pseudo selectors for state.

Pros and Cons

In order to accomplish this, I had to provide the mx.style.* classes that a stylesheet expects to be there when it is loaded. That means you cannot use this approach along with Flex, only in place of Flex. We could get it to work in a sub-applicationDomain, but that is more work and this is only a proof-of-concept.

This may actually be considered more of a IoC framework than styling. We do not have getStyle/setStyle on the components and anything (any public property that is) can be set from the stylesheet, not just stylable properties. That may be considered a con to styling purists, or a pro to those who have wanted to set whatever they want.

View or Download the source code.

Update: Oh, I forgot a couple pros and cons.
Pro: Using Flex styling for non-flex projects allows you to embed assets and class references into the stylesheet. Something you can’t do with traditional text-only styling. It allows a stylesheet full of skin classes to be overridden with another stylesheet full of skin classes for theming.
Con: It only supports CSS up to what Flex 4 does. That means only descendent selectors, no child selectors, sibling selectors, attribute selectors, etc. because MXMLC just ignores those rules it doesn’t understand.

I searched for a solution and found on voq.com a promising library with some algorithms that worked quite nicely and a demo. The quality was nice, but the speed was slow. It also fiddled with the color a little bit. If I put the "easyScaling" parameter down from .5 to .25 I ended up with a nicer thumbnail but was slower to make and had more color disfiguration. You could tell what the original piece was better though.

After some more searching I found that Brooks Andrus played with some algorithms using Pixel Bender. The conclusion to that was he found he could do the same thing with the "smoothing" option in the BitmapData.draw() method. And this still leaves me with yucky thumbnails at small sizes.

I began thinking I would need to take the algorithms from the first source and port them into pixel bender like Brooks did for his ThumbGenie application.

I thought I'd try one more option first. I had played around in my mind with the idea of resizing a bitmap in half, then in half again, until I reached my destination size, since resizing by half still had good results. After discussing it with Tyler I tried it out and ended up with some great results. That last resize to get to the final thumbnail size wasn't half because in an imperfect world your thumbnails aren't always a power of two times smaller than your original. So I had an odd-man-out scale at the end I was applying. Tyler suggested I put that odd-man-out scale at the first instead. So instead of:

1000x750 * .5 resize * .5 resize * .5 resize * .8 = 100x75

It worked like this:

1000x750 * .8 resize * .5 resize * .5 resize * .5 = 100x75

Doing it that way landed me with even better results! It seems that Flash does it's best work when resizing by exactly 1/2.

The above image shows my test results as follows taking a snapshot of my homepage in an HTMLLoader in AIR.

1. Regular BitmapData.draw() method without smoothing (0 miliseconds)
2. Regular BitmapData.draw() method with smoothing (1 miliseconds)
3. Using my own method that resizes by the odd scale first, then by halves (8 milliseconds)
4. Using my method but after the odd scale, only scaling down by quarters (33 miliseconds)
5. Using the voq Lanczos3 method with easyScaling at .25 and sharpening (694 miliseconds)
6. Using the voq Lanczos3 method with easyScaling at .25 and no sharping (676 miliseconds)
7. Using the voq Triangle method with easyScaling at .25 and sharpening (275 miliseconds)
8. Using the voq Triangle method with easyScaling at .25 and no sharpening (266 miliseconds)

My personal opinion is that the best looking thumb is #3. I was surprised that #4 wouldn't be as good. I knew the performance would be lower because I was doing more iterations of BitmapData.draw(), but I thought that scaling it to 75% (down a quarter) each time would end up nicer. Looks like 50% is the best scale to use.

The voq.com algos looked pretty decent, but obviously were slow. I'm quite happy with the solution I've found. I only had to write a little bit of code, it's fast enough, and looks better than any other solution I've found (even Fireworks resizing IMO).

Here is the method I wrote for this. Note, when scaling up, it seemed to look better to just use smoothing and do it in one draw() and not iterations of 2.

Enjoy!

Update: I was getting unsatisfactory images when the resize scale was more than 50%. For example, the original code posted would size an image from 100x100 to 60x60 using one BitmapData.draw() step. And it didn't look that great.

I found that if I sized the image up to a scale that allowed it to be size back down by exactly 50% that the results were much better. In the above example, the 100x100 would scale up by 120% to 120x120, then scale down 50% to 60x60. The final image looks much better this way. The code has been updated to work like this. It also had the option to turn constrain proportions off.

Update: I've posted my code library to Google Code. You can see my final implementation of bitmap resizing in the ImageUtils class.

Framerate makes great sense when doing games or timeline based animations, but in applications do we need it? We can update the screen on mouse moves, roll overs, etc. with the MouseEvent.updateAfterEvent instance method. And for transitions and tweening the class could use a Timer for the duration of the animation and again call Timer.updateAfterEvent. Then the screen would only refresh when it needs to. Performance would be greatly increased. Seems like it makes sense. Would this be something to add to Flex? Would it give us the performance we need/want for mobile applications and more responsive desktop applications?

Any foreseeable drawbacks? What do you think?

Update: I did some testing and it seems that the Timer class is directly influenced by the frameRate. With a frame rate of 0 a timer which should fire immediately (set to 0ms) doesn't fire for 20 seconds! With the frame rate a 0.1 it happens at about 2 seconds, a frame rate of 1 is about 145 ms and a frame rate of anything over 4 seems to be around the same (10ms - 30ms probably depending on what the OS is currently doing).

MouseEvent updating and such happen as they should however, so as long as you start of with a frame rate of 4 so that the app can initialize visually, you could drop it down to 0 until a tween is needed and then bump it up to 4 for the duration of the tween. The rest of the visual changes can respond to mouse events (resize, click, rollover, etc). Or leaving it at 4 frames a second probably isn't too bad on CPU, either way, you'd have to call updateAfterEvent when needed.

1. Fix for abstract classes
   The tiny static classes in the flight.error package allow you to ensure an abstract class is not instantiated and that abstract methods are overriden.
2. Registry
   A global registry to store objects or data that anything in an application can have access too.
3. Reflection
   The "Type" class handles all your reflection needs, including caching the expensive describeType calls and helping pull out needed metadata.
4. Nice base for models
   The ValueObject class is a lazy IEventDispatcher that implements an equals() and clone() method which will work with all subclasses.
5. ValueObjectEditor
   This nifty utility lets you "edit" a ValueObject and then either commit the changes or revert them. Great for dialogs that let ValueObjects be changed but can then either Cancel or Ok the change.
6. AS3 ArrayContainer
   When working in an AS3 project, it would be nice to know when an array is changed, but Flex's ArrayCollection brings in half the framework when referenced. This little guy is the little brother AS3 has been wishing for.
7. Services
   Some common services (RPC services, e.g. remoting, HTTP, etc.) that can be used in Flex or AS3. Much smaller than Flex's built in services.
8. Configuration
   Config lets you define your application configurations in the app, an XML file, SharedObjects, and even the URL. Not only that, you can have multiple sources with some overriding others, and it is all accessible to your classes through a global config property. Super neat!
9. Undo framework
   With CommandHistory and all the command interfaces available, you can build undo-redo into your application without using any of the rest of Flight. Way, way awesome.
10. Weak-referenced binding
    Using the Bind class you can create faster, smaller, and weak-referenced binds. With two-way deep binds and being able to use in AS3-only projects without importing half the Flex framework, this is my favorite nugget.

None of the above pieces references any of the others. They can all be used independently in your own frameworks or applications. That's my favorite part about Flight, is I can use it 100% if I want to, but if I can't that doesn't mean I have to give up my favorite features. I could use any/all of the above with any other framework, AS3 only, or Flex.

Instead of making different Flex and Flash components to use in place of the available components, I made one that adds undo to existing text components. It should work in Flash and in Flex, though I just have a Flex example to show you today. You can see that it can be container specific, though you would probably just put it on the root of your application or the stage. Type in the text components in the top panel. Then do the same in the bottom. You should be able to press Ctrl+Z and Ctrl+Y (or Ctrl+Shift+Z) to undo and redo. If you're on a Mac just substitute Ctrl with Cmd. I've only tested it in Safari and Firefox on a Mac. I hope the key command work on other machines without issue. But I also added a couple of menu items to the right-click context menu. Give it a whirl below, view the source, and see how easy it is to add text undo and redo to all your existing applications without any refactoring.

Update: The keyboard shortcuts don't work in the ActiveX version of Flash (Internet Explorer on Windows).

Let me know if the key-shortcuts don't work on your system. Maybe phase 2 can be some javascript magic to capture those better.

If I created a component that you put on the root of your application (or any MXML component) which added undo/redo to any/all INPUT TextFields with in Flash or Flex would that be better? If you're not doing any custom INPUT TextFields I don't see any issues. But it could cause problems if you're doing your own text components. Also, I would do it by listening to Event.ADDED events and whenever a TextField is added to the display list it would initialize it and add some right-click menu items to it. And I can even make sure when I have script access through ExternalInterface to capture the Ctrl+Z key combo.

Comment and let me know if this would be better than the Flex components. It would work in Flash apps too is the nice part and also you could add it to existing applications without any find-replace. The downsides is it could interfere with text manipulation code you may have in place for custom text components. I'll decide this week and get to work on it next!

Would be cool to create a library to hook up listeners so you can create listeners like this:

You'd use -keep-as3-metadata Listen in the libraries compiler options. Maybe if you want I could post a tutorial on doing something like this. Drop me note and let me know if there is interest.

Now, that being said, I think we're going to have a KILLER alternative to Flex. We (Tyler Wright, my twin, and I) have been wanting to do something like this for awhile. After hearing Ely Greenfield's Flex roadmap presentation at MAX we got all excited about it again. Much of what was presented there are things we've had in mind and wanting to build. I've been working on a proof-of-concept over the last few weeks, although we've worked on it off and on for a couple of years, and we are definitely headed in the right direction. I'll list here a bunch of the stuff we've got worked out so far.

Features

Model View Controller Architecture

Flight's components, code-named Stealth (because code names are cool!), are fully MVC show-off worthy. Each component (model) has a skin (view) and behaviors (controller) which are set at run-time. A component will have one skin, but could have many behaviors. User-input listeners only appear in the behaviors, databinding is used in the skin, and the component doesn't have to worry about anything but it's own logic. There is also a concept of "content" we are borrowing from (dun dun daaaaaa) Microsoft's Blend. Content is data assigned to a component that can be displayed or used by the skin and covers anything from a Button's label to a List's dataProvider.

Layout

Instead of having special components called containers that deal with laying out their children, every component has layout. That means you have a nice way to tell the icon in your button to be on the right or the left of your label. You can have somethings laid out horizontally in a panel and some things absolute positioned. Layout doesn't just work horizontally, vertically, or absolute though. It uses concepts such as anchor, dock, and tile. These will be explained in detail at a later date. AND last but not least to me, when something turns visible=false it is removed from the layout. I've always used visible and includeInLayout together with Flex and it's always bugged me that turning it invisible didn't automatically remove it from the layout. Yay!!

State

Components always have state. You could consider all the data in a component its current state, however, lots of state is dependent on the behavior of a component. If a component behaves like a Button, for example, you'll have mouseUp, mouseOver, and mouseDown states. If it is a toggle button you'll also have selected state. And if it's an application area you might give it state's such as screen = "login". So Stealth provides a state object that you can set mouse state, selected state, and any other state you might desire on it. This allows behaviors to add new types of state at run time.

Style

Stealth has full CSS selector support. This means you can parse a stylesheet at runtime and have "Application #loginScreen Form .inputs" styled just the way you need it. The styles also have state support using pseudo selectors. This would allow your application to show and hide different screens depending on their state like this "Application:login #loginScreen {visible: true;}". Skins and behaviors are assigned via stylesheets at runtime as well: "Button { skin: ButtonSkin; behaviors: ButtonBehavior ToggleBehavior; }".

Styles pull it all together like this:

MXML Skinning

And finally, we've worked it out such that even though Stealth is not Flex, you can still use Flex Builder and MXML to create and define your skins and application. This was the "make it or break it" part of the deal for Stealth. Once we knew we could still use markup to define the layout and that we still had all the autocomplete and refactoring that Flex Builder provides, we were sold.

Right now Tyler, myself and hopefully soon Rob Taylor from flashextensions.com are working on it (I hope you don't mind the mention Rob), but we hope to get the code public soon so that others can help and everyone can check in on the progress.

I really want to get a demo up that showcases the styling. That may or may not happen soon as I'm working on a project that may continue until April 15 (to pay off the government for all my contracting last year). :D I'll stop procrastinating tomorrow.

I've decided that there are two main focuses when designing a Flex application, and it results in two different kinds of frameworks. There is Flex-focused applications and server-focused applications. The difference between these two applications is the location of the majority of domain logic.

In Flex-focused applications you have a full domain model with methods and properties and relationships between the models. There is a lot of logic on the Flex side that is not presentation logic.

In server-focused applications Flex takes on a view role. This is where value objects are used the most. More calls are probably made to the server because the Flex app needs to know what to do next or to display next. The Flex app contains mostly presentation logic.

Right now I think most of the popular frameworks are server-focused. Value objects are abundantly used. A ModelLocator is used because the model on the Flex side is pretty flat.

Right now I mostly do Flex-focused development. Not because I am not as comfortable on the server, but because the applications I make are things like image editors, document creators, etc. and not dashboards into server views. Right now I need a different kind of framework. Right now I need something other than Cairngorm or PureMVC.

I know since day one Adobe has listed CSS styling as a feature of Flex. But anyone who has used CSS to style a web page knows that Flex does not support CSS. It supports, well, SS.

CSS stands for Cascading Style Sheets. Flex is missing the "Cascading" part of it. CSS is all about using a style sheet to describe the "presentation of the document" (World Wide Web Consortium CSS1). Because of the limited amount of the CSS standard that Flex supports, you really can't define that without a LOT of verbosity.

Let's take some examples of what I'd LIKE to do in Flex, sometimes I can, sometimes I can't. I'd like to set the colors in my scrollbar buttons. Well, I can do this by using the many styles defined in ScrollBar such as upArrowUpSkin, upArrowOverSkin, and upArrowDownSkin. I had to look up the styles for ScrollBar to see if I could do that. Buttons have some nice styles that let you set the background color, but I can't access that so I'll have to replace the skin entirely.

Now if I wanted to change those colors for this area of my app or that area, or for popups only etc. I'd have to go through and make sure each ScrollBar had a styleName that I could then use in the stylesheet for that. Here's what you SHOULD be able to do with CSS:

Beautiful! Flex component developers didn't need to add a style on the ScrollBar component for every conceivable style that one might want to change for its buttons. With real CSS you can access them because the selectors allow your styles to cascade down to all scrollbars under the component with an ID of certainPartOfMyApp. I could have had one definition to style ALL buttons under that ScrollBar, but decided to use the styleNames which might be in place if Flex supported this to style each button separately.

Now if you were to use CSS pseudo selectors (e.g. a:hover) and mapped them to a component's "state" then you could really get going. Say your main application has several states in which different areas of the APP are viewable.

Now when I change the state of my app a different view is presented. And when I change the state of my catalogScreen the columns change their size, perhaps throwing an effect in there for smoothness could be part of the CSS as well.

I've put together a full implementation of CSS2 as far as the format is concerned and the selectors etc. It doesn't use the box model etc. that HTML uses, but I'll post a demo of it up here soon. It will of necessity use my own components because there is no way to integrate it into the existing Flex styling framework. I've looked, I've tried. :)

Vote For CSS!

If enough of us ask for it Adobe will give it to us. It's already too late to include in Flex 3 which should be coming out soon, but now is the time to be asking for big changes like this for Flex 4. Go sign up and vote for this feature in Adobe's bug base.

UPDATE: Thanks to all those who voted this bug was fixed (or feature added) in Flex 4! Great job everybody. And thank you Adobe for listening to the community.