Programmatic Skinning in Flex Builder 3

Flex is the "HOT" technology these days. Apart from the technology, performance and other advantages behind it, for end users it is very pleasing to look at. When it comes to look and feel, pretty much everything can be done using Javascript too, but flex was developed particularly for "Rich" applications, so it makes creating rich user interfaces easy for the developer. Not to mention, its more efficient and more maintainable for the developer. Flex Builder for Flex is pretty much the Visual Studio for ASP.NET (lot of differences and lot of similarities here). Flex Builder really makes working with Flex easier. And by default, adobe provides a lot of components, which you can use to layout using Flex Builder. Using these components is fine, until you need a different component. Flex also provides support to create custom components and skin them programatically (there are also other ways).

There are a lot of articles and blogs online which talk about how to write programmatic skins, but these skins can only be seen when the Flex application actually runs. What do I need to do if I want to see the applied programmatic skin in the Flex Builder Design view, so i can play around with my layout?

There are some steps that need to be followed. And what better way there is to show the examples? I wish this blogging site supported code snippets, but it doesnt , so i will provide links to code.

The Application mxml is ProgrammaticSkinning.mxml and the skin classes are FlatColorRectangleSkin.as , FlatColorRoundedRectangleSkin.as, GradientRectangleSkin.as and NodeSkin.mxml.

The custom class is Node.as and the style sheet is styles.css. The code in these classes is straight forward, so i wont explain them all. But Node.as and NodeSkin.mxml are special.

1. Node.as should be put in a different library project, if this class exists in the same project, the skins wont be rendered in Flex Builder design view. I dont know the reason for this, if anybody knows, please let me know.

2. Node class in order to support skins, has to override updateDisplayList method, get the SkinClass, create an instance of the class, set the skin Name , set stylename on the skin to this(for the skin to inherit all style properties from the component), set the size of the skin to the component or appropriate (we want the size of skin to be grater than 0, to be able to see it), and add the skin as a child.

3. If anyone wants to use Degrafa for skinning, look at NodeSkin.mxml. This is my favourite. We can use Degrafa tags to define our tags.

That said, we can create our custom components, style them in any way we want, use them in Flex Builder, drag-n-drop in Flex Builder design view and play with the layout.

Also, here is a component you can extend form if you want your component to be skinnable.

package charts
{
import flash.display.DisplayObject;
import flash.events.MouseEvent;

import mx.core.IFlexDisplayObject;
import mx.core.UIComponent;
import mx.effects.Zoom;
import mx.effects.easing.Bounce;
import mx.styles.ISimpleStyleClient;

public class SkinnableComponent extends UIComponent
{
 private var zoomAll:Zoom = new Zoom();

 public function SkinnableComponent()
 {
  scaleX = 0.5;
  scaleY = 0.5;
  addEventListener(MouseEvent.ROLL_OVER, doZoom);
  addEventListener(MouseEvent.ROLL_OUT, doZoom);
 
  zoomAll.zoomWidthTo = 1;
  zoomAll.zoomHeightTo =1;
  zoomAll.zoomWidthFrom = 0.5;
  zoomAll.zoomHeightFrom = 0.5;
 }

 protected override function updateDisplayList(unscaledWidth:Number,
                                      unscaledHeight:Number):void
 {
        showSkin("upSkin");
  }

 protected function showSkin(skinName:String):void
    {
        var skinClass:Class = Class(getStyle(skinName));
        var skin:IFlexDisplayObject = IFlexDisplayObject(getChildByName(skinName));

        if (!skin)
        {         
            if (skinClass)
            {
                skin = IFlexDisplayObject(new skinClass());
                skin.name = skinName;
    (skin as ISimpleStyleClient).styleName = this;
                addChild(DisplayObject(skin));
                skin.setActualSize(unscaledWidth, unscaledHeight);
            }
        }

    }
  
    protected function doZoom(event:MouseEvent):void
 {
          if (zoomAll.isPlaying)
              zoomAll.reverse();
          else
              zoomAll.play([event.target], event.type == MouseEvent.ROLL_OUT ? true : false);
      }

}
}

Comments, advices and help are always welcome.

Comet Style Requests and continuations

Let me start the introduction to this post by quoting an excerpt from an article "

• GMail’s GTalk integration
• Jot Live
• Renkoo
• cgi:irc
• Meebo

So what makes these apps special? What makes them different from other things that might at first glance appear similar? Fundamentally, they all use long-lived HTTP connections to reduce the latency with which messages are passed to the server. In essence, they do not poll the server occasionally. Instead the server has an open line of communication with which it can push data to the client.

The architecture relies on a view of data which is event driven on both sides of the HTTP connection"

The above style of communication is now widely used in Flex, but it is not "long-lived Http". So is this style of communication possible in Http? Sure with Comet style requests we can have long lived requests so that ajax clients, apart form polling, can also enjoy the "server-push" data. But what about the effects of this long lived Http connections? How does the server (servlet container) handle these requests?

It is considered that "thread-per-request" is a better model than "thread-per-connection", when serving thousands of clients simulataneously (not for serving max requests per second). But with long lived connections, the "thread-per-request" model doesnt hold good. Consider a thousand ajax clients haing long lived connections toa server. With "thread-per-request" model, the server will run out of threads to process new requests. So a new approach is needed on the server side, if Comet style requests are to be supported scalably.

One of the new approaches is "Continuations". If continuations is a new term for any, whats the best site to check for its meaning other than wikipedia? This link gives an excellent introduction to continuations (atleast to me, i didnt find any page which describes the concept in such accurate simple words) .

Now the greedy question is "Can i use it in Java? Can i use it to develop web applications in Java?". Yes! Jetty supports continuations on the server side. For more information, visit their wiki site.

The basic idea is to have long lived connections, but to used threads effeciently. Continuations seem to support that, they only allocate threads to these long-lived connections when an event occurs, threads don't waste time waiting for blocking IO etc.

I also found an article on continuations in Rife and scalability with Terracota.
Also Scala, has support for continuations. But more on that in an other post.

FlexSprite

FlexSprite is defined like this "public class FlexSprite extends Sprite". As far as Sprite goes, the docs quote that

" The Sprite class is a basic display list building block: a display list node that can display graphics and can also contain children.

A Sprite object is similar to a movie clip, but does not have a timeline. Sprite is an appropriate base class for objects that do not require timelines. For example, Sprite would be a logical base class for user interface (UI) components that typically do not use the timeline.

The Sprite class is new in ActionScript 3.0. It provides an alternative to the functionality of the MovieClip class, which retains all the functionality of previous ActionScript releases to provide backward compatibility."

It would be handy to know the difference between movieclip, timelines and Sprite, but thats for an another post.

And FlexSprite adds extends Sprite to override the toString() method. It overrides the toString() method to return a string indicating the location of the object within the hierarchy of DisplayObjects in the application.

It iterates through the parent heirarchy untill it reaches the stage object and returns the object location heirarchy.