Here is part 2 of my thorough introduction to Flash Camouflage 2.2 on Flash Tuts Plus. Make sure you check it out, and here is a quick summary of what I cover:

Welcome to the part two of my introduction to the Flash Camouflage Framework. In part 1 we built the foundation for our site, components, labels, css parser, and set up our PropertySheet. In this part we’re going to focus on the design side of our site by cleaning up the layout, skins and adding interaction.

Continue Reading

Here is part 1 of a 2 part series for Flash Tuts Plus about using Flash Camo 2.2. Make sure you check it out, here is a quick summary:

Welcome to an introduction of the Flash Camouflage Framework. Flash Camo (for short) is a graphics framework that is broken down into 3 core areas: “Decals”, the “CSS Parser”, and the “CamoDisplay”. These systems can be used individually or combined to fit your needs. When used together they form a powerful set of tools to help skin and style any Flash application. With Camo’s modular approach, you can use as little or as much of the framework as you want.

In this two part tutorial we’re going to build a simple website to show how easy it is to incorporate Flash Camo into your next project.

Continue Reading

Here is a simple CSS sheet:

Example CSS

/* This is a comment in the CSS file */
baseStyle {
	x: 10px;
	y: 10px;
	width: 100px;
	height: 100px;
	padding: 5px;
	margin: 10px;
}

baseStyle .Button{
	x: 0px;
	y: 0px;
	background-color: #000000;
}

#playButton {
	background-color: #FFFFFF;
 	background-image: url('/images/full_screen_background.jpg');
}

#fullScreenButton{
	background-color: #FF0000;
	background-image: url('/images/full_screen_background.jpg');
}

#playButton:over {
	background-color: #333333;
}

interactive {
	cursor: hand;
}

Parsing CSS

Once you have CSS that is ready to be parsed, either by loading it in from a URLLoader as text or by creating it as a string in your code at run time, you will need to call the CamoPropertySheet’s parseCSS method. This method has one parameter, compressCSS. By default this is set to true. The parser requires your CSS to be properly formatted by removing all unneeded spaces, tabs, returns, px, and comments. There are two ways of doing this, you can use server side compression or let the CamoPropertySheet handle the compression for you. Here is what the compressed css would look like:

Compressed CSS

<br /> baseStyle{x:10;y:10;width:100;height:100;padding:5;margin:10;}baseStyle .Button{x:0;y:0;background-color:#000000;}#playButton{background-color:#FFFFFF;background-image:url(’/images/full_screen_background.jpg’);}#fullScreenButton{background-color:#FF0000;background-image:url(’/images/full_screen_background.jpg’);}#playButton:over{background-color:#333333;}interactive{cursor:hand;}<br />

Once the CSS is parsed, you can retrieve an Array of selector names by calling the selectedNames getter. A selector represents the name of the particular CSS style and it’s collection of values. The getSelector method will return the selector ⁴ and it’s properties as a PropertySelector ⁵. New selectors can be added to the CamoPropertySheet by calling newSelector and passing a selector name and a PropertySelector instance. Finally, you can duplicate a CamoPropertySheet by calling the clone method ⁶.

Inheritance

Selector inheritance is also supported by the CamoPropertySheet. From the previous CSS sample, lets look at the .Button style. As you can see the selector name in the CSS is "baseButton .Button". Its formatting tells the parser that .Button inherits properties from baseButton. We refer to .Button as the subject and baseButton would be an ancestor element. If you were to call getSelector for .Button the parser will automatically return a PropertySelector with merged properties from baseButton and .Button. Any conflicting properties will be overridden by the subject style. Here is what the .Button object would look like:

.BaseButton as an Object

{
	selectorName: .BaseButton,
	x: 0,
	y: 0,
	width: 100,
	height: 100,
	padding: 5,
	margin: 10,
	backgroundColor: #000000;
}

PropertySelectors created by the CSS parser have a reference to their selector name in the selctorName property. Also, it’s important to note that in this example the x and y values from .BaseButton overrode the ancestor’s values. In this case they are 0 and not 10 as defined in the baseStyle.

Class and ID Selectors

Class (.class) and ID (#id) selectors are supported by the CamoPropertySheet. There is no difference to the CSS parser between Classes, IDs, or regular selectors so when making a selector request it’s important to understand how to join them. In CSS, the inheritance rules dictate that a Base Styles is overridden by a Class Style that in turn is overridden by the ID Style. You can simulate this by passing in multiple selector names when calling the getSelector method. If we wanted to create a “play” button style that inherits the default Button class style and the base interactive style we would call getSelector and pass in "interactive",".BaseButton","#playButton" using commas to separate each style name. By combining the names of each selector by lowest priority to highest priority the getSelector method will automatically parse out each selector and merge them into a single PropertySelector. The last selector name becomes the PropertySelector’s selectorName value.

Pseudo-Selectors

When Pseudo-Selector are requested, their parent style’s properties will be added to the returned Object. Adding a colon (selector:pseudo-selector) to any style name will alert the parser that it needs to also inherit properties from the selector name to the left of the colon. In the above CSS example we request #playButton:over we will get back the following object:

#playButton:over as an Object

{
	styleName: #playButton:over,
	backgroundColor: #333333,
 	backgroundImage: url('/images/full_screen_background.jpg')
}

In this example the background-color and background-image properties are inherited from the #playButton selector but since #playButton:over has its own background-color the ancestor’s property is overridden.

It is important to keep in mind that there may be a performance hit when parsing large CSS files with lots of inherited selectors. Also, the compression used when parsing the CSS uses a complex RegEx pattern so it is better to do the compression on the server side instead of during run time. Outside of this limitation, the real power of the CSS parser comes into play when applying PropertySelectors to CamoDisplay classes.

AbstractDisplay

The AbstractDisplay handles the foundation for the BoxModel and CamoDisplay classes. Not only does it make public two methods, move and resize, but it also handles redraw and visual invalidation to optimize the graphic redraw for the display classes of the framework. The most important feature of the AbstractDisplay however is what happens when we call addChild and removeChild. The AbstractDisplay automatically creates a container called “display” that gets added as the first child to the display list. Every time another DisplayObject is added to an AbstractDisplay, it gets attached onto the class’s display instance. All the display list methods are mapped over to the internal display Sprite. Here is a chart to illustrate the inheritance of Camo’s display classes:

BoxModelDisplay

The BoxModelDisplay allows us to apply Margin, Padding, Border and a Background (Color/Image). The BoxModelDisplay manages the offset of the display sprite based on those properties. Lets take a look at how the Box Model gets rendered:

Camo’s Box Model consists of a Margin, Border and Padding wrapped around a display.

Here is a list of supported properties of BoxModel:

BoxModel Background

A BoxModelDisplay’s background-color and background-image work exactly to how it would in HTML. The background-color is the bottom most color behind the display. It is important to realize that the CSS width and height affect how the background fill will take place. If you do not define the width and height of the BoxModel, it will use the values from the display. The background-image gets composited on top of the background-color. The background-image property lets the box model know how to load in a source image ⁷. Background-images also have repeat rules: repeat (is default), no-repeat, repeat-x, repeat-y. When using no-repeat you can specify a background image’s position (x, y) to offset the image. This is helpful when you only want a background-image to be displayed at a certain location behind the display.

When the BoxModelDisplay does a refresh ⁸, all of its values are reviewed and drawn to the graphic’s layer of the BoxModelDisplay. This insures that the border, background-color, and background-image are a single Bitmap to save on memory. The display Sprite (where all children get added to) is offset by the top and left Padding, and Border ⁹. Once the refresh is complete the display will be correctly positioned. Padding is invisible unless you have set a background color or image. In that case, the background will show through in the area offset by the padding. When you request the width or height of a BoxModelDisplay the dimensions are returned taking into account the padding, border and display. The BoxModelDisplay can be used on its own but when combined with the CamoDisplay, you get additional css style support.

CamoDisplay

The CamoDisplay inherits some powerful layout logic from the BoxModelDisplay and introduces the applyProperties method. By passing a PropertySelector (obtained from a CamoStyleSheet) the CamoDisplay will attempt to apply the PropertySelector’s values ¹⁰. This takes advantage of the PropertyApplierUtil and TypeHelperUtility that is part of the Property Managment System in Camo.

Here is a list of the properties supported by the CamoDisplay:

The most important functionality added by the CamoDisplay is the rasterize method. Just like the BoxModelDisplay which draws its border, background-color, and background-image to the graphics layer, the CamoDisplay can do the same thing with its display Sprite. When you call rasterize, a Bitmap snapshot of the display is take, the old display is removed and a new one is put in its place with the previous display’s BitmapData drawn to it’s graphics layer. All the children that were attached to the display are removed (so the Garbage Collector can release them from memory) and you are left with a flattened display.

It is important to note that rasterize can only be called only once since all children in the display are removed. The speed and memory benefits can greatly increase the performance of your application. This also allows you to layer images in the display Sprite and then flatten them into a single image. Rasterize should be used on any CamoDisplay where its children will never be changed or used outside of the initial setup of the class. It is also an excellent technique to use when animating text.

TypeHelperUtil

Although the TypeHelperUtil (located in the camo.core.utils) does not belong to any one system in Flash Camo, it is key in converting string values from a PropertySelector into correctly typed data to be applied to your Class. The TypeHelperUtil contains a lookup table of functions to handle conversions of specific data types. Primitives such as Number, Array, and Object are built in. This is used as part of the applyProperties method in the CamoDisplay in conjunction with the PropertyApplierUtil. By default the TypeHelperUtil supports the following conversions:

Built in Type Support

The TypeHelperUtil also supports color shortcuts when converting colors into uints. Here is a list of supported colors and their values:

Color Support

In addition to the built in string conversion methods you can register your own. The TypeHelperUtil has two methods for extending the functionality of the utility called registerFunction and removeFunction. You can also customize and extend the built in color support through the registerColor and removeColor as well. This allows you to add your own conversion based on your projects needs.

If you want to add your conversion functions you need to use the class’s qualified name as the key. As an example to correctly convert a Point from a string, you would register your conversion function to flash.geom::point and not to a reference of the Point class itself. It is recommended that you register all custom functions in your doc class before you application gets started. If you are dynamically adding conversion functions that are specific to a particular section you should remove all unused function since they will not allow the Garbage Collector to remove your classes properly.

DecalSheetManager

The DecalSheetManager (located in the camo.core.managers package) is the manager for the decal system. It handles the xml that defines a list of DecalSheet images and coordinates for cutting out each Decal. It also stores a collection of DecalSheets to make createing complex Decal look up tables easier to manage. You can configure DecalSheets and Decals on the DecalSheetManager at run time or with XML. Once this data is set, the DecalSheetManager goes out and gets all the images it needs for the DecalSheet images. Lets look at how to configure a DecalSheetManager with XML:

Sample DecalSheet XML

<br /> <decalsheet><br /> <sheets baseURL="images/"><br /> <sheet name="buttons" preload="true" w="550" h="126" src="buttons.gif"/><br /> <sheet name="button_skin_2" preload="true" w="550" h="126" src="button_skin_1.gif"/><br /> <sheet name="button_skin_3" preload="true" w="550" h="126" src="button_skin_2.gif"/><br /> </sheets><br /> <decals><br /> <decal name="up" sheet="buttons" x="1" y="1" w="100" h="41"/><br /> <decal name="over" sheet="buttons" x="1" y="43" w="100" h="41"/><br /> <decal name="down" sheet="buttons" x="1" y = "85" w="100" h="41"/><br /> </decals><br /> </decalsheet><br />

The above DecalSheet XML is broken up into two main nodes, one for Sheets (DecalSheets) and the other for Decals. Each Sheet node contains an name (unique reference name), preload (true or false), w (width) and h (height) attributes along with the src representing the path to file. You can add as many sheets as your application requires. Remember to only flag the critical ones for preloading to cut down on load time. The decals node defines how each decal should be cut out. A decal node has an name (unique name for lookups), sheet (name of the DecalSheet where Decal will be cut out from ¹), x, y, w, and h.

To use this XML, simply call the DecalSheetManager’s parseXML method. Once xml is parsed, the DecalSheet requests a list of all the sheet nodes flagged to be preloaded and begins loading the src images. The baseURL attribute, located in the sheets node, is added to the url of each page’s src when making the load request. You can leave this empty and point each src directly to an absolute url if your images are not located in the same directory.

The DecalSheetManager makes use of a special loader class called the BitmapLoaderManager (located in the camo.core.managers package). Once the images are loaded, the DecalSheetManager is ready to be used. If a page is not flagged to be preloaded but is requested, it will be added to the load queue. Decals can still be requested before the DecalSheet images are fully loaded. The DecalSheetManager will use a Decal’s width and hight to generate a proxy graphic (a temporary black placeholder graphic) that will be replaced once the corresponding DecalSheet has been loaded. The DecalSheetManager also makes use of the LoaderManagerEvent to dispatch updates on preload and regular loading progress. You can listen for preload next (LoaderManagerEvent.PRELOAD_NEXT), preload done (LoaderManagerEvent.PRELOAD_DONE), and load complete (LoaderManagerEvent.COMPLETE). You can use this to display load status as well as monitor the progress of preloading/loading of DecalSheet source images.

DecalSheet

Loaded images get stored inside of a Dictionary within the DecalSheetManager as individual DecalSheets. Each sheet’s key come from its name. At any time you can get a Sheet by calling getSheet on the DecalSheetManager. The DecalSheet uses the sample method for cutting out BitmapData from its source. When you request a sample, you must pass it a name that refers to a Rectangle defining the x, y, width, and height of the area to cut out. DecalSheets can be configured at run time without XML since a DecalSheet extends the Bitmap Class. Simply pass it a bitmap to use as the source image and use registerDecal on the DecalSheet to configure it at run time. Using a DecalSheetManager simplifies the process but DecalSheets and Decals can be used on their own whenever needed. Here is a diagram to illustrate the process:

Decal

A Decal is a Bitmap that contains a reference to the DecalSheet it was cut out from. Now that you have seen how we get xml data into the DecalSheetManager, lets talk about how to retrieve Decal instances. When you call getDecal on the DecalSheetManager or DecalSheet, you need to supply the name of a Decal. You can check if a Decal exists by looking through a DecalSheet’s decalName Array. Once a Decal is requested, the Decal’s name gets passed to the parent DecalSheet through the sample method and the Decal’s BitmapData is returned inside of a new Decal Instance.

Since all Decals contain a reference to the DecalSheet it was cut out from, this connection allows the Decal to receive updates from its parent DecalSheet. You can change a DecalSheet’s BitmapData at any time just as you would any other Bitamp instance. Decals listen for Event.CHANGE events from their parent Sheet and once an event is received, it resamples the DecalSheet and updates its own BitmapData ². Imagine being able to reskin an entire application by changing the BitmapData in a single DecalSheet? Here is a diagram to illustrate how this works:

Changing the BitmapData of a DecalSheet will fire a CHANGE event telling all children Decals to update.

• TypeHelperUtil? now allows you to register your own custom conversion functions.

• TypeHelperUtil? now supports color shortcuts. In your css you can use a color name and the util will automatically convert it. Here are the supported colors: black, blue, green, gray, silver, lime, olive, white, yellow, maroon, navy, red, purple, teal, fuchsia, aqua, magenta and cyan. See documentation on how to add your own custom colors.

• DecalSheet? system has been restructured. Removed the use of config classes, now DecalSheets? can be created and defined completly by hand.

• Refactored the DecalSheetManager? to handle multple DecalSheets?, parse DecalSheetXML as well as organize all decals associated with DecalSheets?.

• DecalSheet? XML has been cleaned up. Removed the use of id and replaced with name. DecalsSheet? now have a default width and height of 1 if not defined in the XML. Removed the Scale9 from Decals, that will be handled by the DecalSheet? at a later date.

• Minor BoxModel?/CamoDisplay optimization for better handling of invalidation.

• The style package and all of the StyleSheet? classes have been renamed and moved into property package. This is the new engine for converting CSS into property values for the BoxModel? and CamoDisplay.

• The PropertyApplyerUtil? will now manage converting raw css text into correctly typed values based on two things. First the util will create a PropertyMap? (a new object that represents all of the public variables and setters of a class including their correct value types) of a given class then attempts to convert the string values of the css text into the type (String, Number, UINT, Object, Point, Rectangle, StyleSheet?) specified in the ProperyMap?.

• The TextFieldFactory? has been removed. Due to the new way of applying properties from CSS it was better to leave the implementation of TextField? creation up to the user.

• There is now a new CamoDisplayEvent? class. When a CamoDisplay changes it will fire an update event. This is built into the core of the framework through the AbstarctDisplay?.

• New Interfaces, IDisplay, IBoxModel, and ICamoDisplay. Each Interface maintains the chain of inheritance to the IDisplay and includes support for common DisplayObject? methods.

• Cleaned up the redraw logic in the BoxModel? to be more efficient and only redraw when needed. Also added logic to handle invalidating the display before a redraw takes place. This is to insure the BoxModel? and CamoDisplay are only rerendered when needed.

• Config class dependancy has been removed. Wherever possible, I have removed the need for using a config class to be passed into the constructor. The Decal System still requires one but that will be removed in version 2.2.

• Compressing CSS is now done in the parseCSS method found on the PropertiesSheet? or CamoPropertiesSheet? class. This feature is now automatically set to true.