Ionut Grosu

Styles provide a good additional layer of customization in Flex. If the available styles for a component do not meet your needs, then you re-skin the component using your own graphical or programmatic skins.

Styles and skins complement each other and more than that, you can’t have one without the other. The skins do the actual drawing, while the styles specify parameters on how to do the drawing.Here’s where we need to make the decision (programmatic vs graphical).

Using graphical skins is pretty simple, you set the skin styles to the graphic object ( a JPEG/GIF image, an SVG vector graphic, or an asset/symbol from a SWF file ). This can be done with css, mxml-inline or in actionscript.

The big downfall is that graphical skins do not support any customizations. Which is a big minus comparing to programmatic skinning.

For the programmatic skins you should take a look at the mx.skins.* package and the default halo skin package in flex sdk (mx.skins.halo.*). Here you will find how a component is drawn based on the style you set on it. The base class for a skin is mx.skins.ProgrammaticSkin which extends FlexShape. It provides the measuring, positioning, invalidation along with various graphic utilities.

Any skin extending this class should consist of a constructor (for an ActionScript class), an updateDisplayList() method, and a set of getters and setters for the skin’s properties. Extending ProgrammaticSkin is not a requirement, you can easily extend UIComponent and you can create both actionscript and mxml skins.

Here’s a short demo on using programmatic skins:
[Demo](right-click for source)

If you look at the code you’ll see that it’s very simple. It adds a rectangle, 2 borders and some custom styles to the button skin. You can step in deeper and create advanced skins, combine effects,filters,s.o.

All in one I encourage people to use programmatic skin, because it gives you great control over the looks of your application. And when you combine this with runtime css then sky is the limit.

Many people say that runtime css is not that useful since you need to compile it to a swf, but that is not a really a problem when you have the compiler available on many platforms. It’s not that hard to create a script that executes a simple command like “mxmlc myCss.css”. Or you can create your own css parser which also is not that difficult ( … wouldn’t be surprised if an open-source project for this is already out there ).

In any case, I’ll let you think about the possibilities when using programmatic skins.

Happy skinning !

I was actually surprised that something like this hasn’t come in the sdk with AIR 1.0 release. I built this during the AIR beta and adjusted it now to run on 1.0. It acts as a global window manager and manages all your window instances in an Air application.

It uses SimpleWindow class which extends mx.core.Window and adds some needed functionalities.

For the ones interested in the ways things work here’s an image which speaks better english.

A short example of how it should be used.
First, create a window component extending SimpleWindow. Let’s say MyWindow.mxml:

<?xml version="1.0" encoding="utf-8"?>
<core:Simplewindow>
      xmlns:core="com.flexwizz.core.*"
      xmlns:mx="http://www.adobe.com/2006/mxml"
      width="400" height="300"
      title="My Window">
      <mx:Text width="100%" text="I am MyWindow">
      </mx:Text>
</core:Simplewindow>

Then you can simply use WindowManager.openWindow(MyWindow) . Simple enough…

I often needed to restrict more then 1 windows of a specific type to be opened at once. And you can achieve that pretty simple here by specifying the windowUID on that component above. The property windowUID should always be set on component declaration, must be a const (binding isn’t made here) and before opening it with WindowManager. Example (MyWindow.mxml):

MXML:

<?xml version="1.0" encoding="utf-8"?>
<core:Simplewindow>
      xmlns:core="com.flexwizz.core.*"
      xmlns:mx="http://www.adobe.com/2006/mxml"
      width="400" height="300"
      title="My Window"
      windowUID="com.wins::MyWindow">
      <mx:Text width="100%" text="I am MyWindow">
      </mx:Text>
</core:Simplewindow>

And open it:

WindowManager.openWindow(MyWindow)

When you try to open a 2nd window with the same windowUID, WindowManager will activate the window that is already opened with that windowUID. Or you can specify it to notify that the window is already opened which can be done using the 3rd argument of the openWindow methods.

You can use any string on windowUID property and the WindowManager will never open 2 instances with the same windowUID. But actually, the way I thought it, if you want to easily keep track of your windows in the application you can set this property to package+”::”+ClassName string as I did above in the MyWindow component. This way you can easily use getQualifiedClassName(ClassName) to get the windowUID of that. For example for MyWindow.mxml:

WindowManager.getOpenedWindow(getQualifiedClassName(MyWindow); // returns the window's instance

Anyways, there is a example application + source-code which explains all the functionalities better.

You can get the recommended Example Application - Air file included, the Lib SWC, Lib Source and AsDocs.

Btw, you should also check the code license page.

Hope this helps! and let me know if it’s useful or if you run into trouble, find bugs, etc.

Personally, I’m a big fan on design patterns, so don’t judge by the title. The thing is that you can easily step on to the other side…when you’ve got a new project and you’re thinking right away which pattern should you use. I don’t see this as the correct coding attitude.

For the mvc in short :

The MVC(model-view-controller) paradigm is a way of breaking an application, or more commonly, just a piece of an application’s interface, into three parts: the model, the view, and the controller.

Model

The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating if today is the user’s birthday, or the totals, taxes, and shipping charges for shopping cart items).

Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.

View

Renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.

Controller

Processes and responds to events, typically user actions, and may invoke changes on the model.

You might want to look into this link if you want to know more about mvc.

In as3 there are many different MVC implementation already made and some of these that step up: Cairngorm and PureMVC. The reason why I don’t like to choose using mvc in my projects is that it takes the beauty away from coding. It is important to keep in mind that there are many different interpretations of how to implement the MVC pattern. But no matter if you choose creating your own or use one of the above, in MVC you will always be walking this line:

This architectural pattern will always guide you that way. Cairgorm for example (being the one that I’ve used in as3), not only that it guides you on a straight line it also fixes many problems before you encounter them. Thus with no problems will come no experience and especially no fun. This will easily transform you from a programmer into a programming user. And yes, I know that using mvc has some great benefits also, the most important ones being:

1. Lower complexity

2. Interface Flexibility

But there are many-many ways to get there…and you can think your “way” there.