PhilterBlog

Hey you with the camera...yeah, you...

If you're interested in learning from 3 of the best photographers in the world (yes, I said world), you may be interested in attending YinYang Workshop. I recently developed the site for Dave & Quin Cheung of DQ Studios and Huy Nguyen of F8 Studio, and not only are they photographic rock stars, they are amazing people who are truly gifted and passionate about what they do. They are putting on a 3 day workshop in San Francisco in September of this year, and the seating is limited, so if you're interested, contact them right away!

If you need proof of the quality of their work, check out DQ Studios' and F8 Studio's websites. They truly do AMAZING work and have won tons of international awards!

On a related note, I also built a site promoting DQ Studios' new DQ QuiKeys, a workflow empowerment tool for use with Photoshop. See examples of what you can do with QuiKeys as well as tutorial videos by Dave & Quin themselves.

As I mentioned in a previous post, it really is an exciting time to be a Flash (Flex/Apollo) developer. This was reiterated to me as I spent parts of the past 2 weeks building an Apollo widget I call mxnaQUBE currently in beta version 0.5. I have to say I haven't had this much fun developing something in quite some time. Even though the API isn't nearly complete being that this is an alpha, there was enough there to build a widget (maybe it's an 'app', I don't know...) and one that I think I'll be using regularly. Here is the rundown:

What does it do?

mxnaQUBE is a way to view posts aggregated by mxna (Macromedia XML News Aggregator). It currently provides access to the newest posts, most popular posts and the ability to search posts. On top of that, it auto-archives all posts that are consumed by the widget. The best way to explain is to show it to you, so here are some screenshots:

New posts are displayed and updated every 3 minutes (version 1.0 will include a preferences panel that allows you to customize this, among other things). Also, it prevents display of duplicate posts that are often found on mxna.

You can search mxna based on keywords

You can view the most popular posts from the last day, week, month, year or of all time.

The mxnaQUBE automatically archives all posts that are downloaded to it, so you'll have a history of posts grouped by category and feed that they are associated with.

There is a "mini" view that displays and cycles through only unread new postings. This provides a concise way to view new posts.

As the name suggests, the widget is essentially a cube which can be rotated to see any of the views mentioned above. You can rotate the cube by "nudging" the arrows in the bottom corners :)

Globally, the mxnaQUBE also implements tooltips as well as a connection status monitor indicating when you are online or offline.

What will version 1.0 do?

Version 1.0 will add functionality such as the following:

• Right click menu (Apollo 1.0 WILL implement full control over the right click menu - Woohoo!)
• Preferences panel to provide the ability to control global settings as well as customize which feeds you want to auto-archive.
• Possibly additional cube views with the ability to choose the 4 views that are most beneficial to you.
• Possible auto update functionality to fix bugs, add features, etc.

Other things I discovered while building it.

• Building an apollo app in Flex Builder is really as easy as people have said it is. Adobe has done a good job of integration. Doing things like transparencies, window dragging, minimizing, closing, and working with files are super simple.
• Alex Uhlmann's distortion effects are super cool :)
• Data binding is sooooo simple and works so well it's amazing.
• For the most part, skinning is pretty straightforward, however, I did run into a couple of issues. The scrollbar skins in the AeonGraphical skin fla don't seem to match the width of the default scrollbars. Also, i ended up scrapping my scrollbar skins altogether because for some reason when you use a custom skin for the scroll track, the ability to click the track to scroll gets killed altogether. Anyone have a workaround for this?
• I love mxml more and more every day. To be able to extend mxml components is awesome. However, there is an issue with adding children via mxml to both the superclass and the child class as you get a compilation error. A workaround is shown by Peter Ent, but to be honest, I couldn't get it to work properly.
• The Flex Style Explorer is a God-send.
• To manage all of my embedded assets, I wrote a simple AssetManager that pulls in all embedded assets and provides a static class through which to access your asset (handy if you are using your asset in multiple classes).
• Does anybody have a simple way to swap out HTML number codes for proper characters? For example, ’ represents the right quotation mark.

Where can I get it?

Download it here

NOTE A: This is a beta version and so I make no promises that it won't self destruct at some point. I have left it running for extended periods of time and it seems to function properly, however, if you do notice any bugs, please email me at phil@philterdesign.com.

NOTE B: The data coming back from the mxna webservice can be slow at times (particularly the data for new posts) so be patient :).

Please email me your feedback as it is appreciated. If you have any suggestions on things you would like to see, please feel free to email me those as well (not saying they'll get implemented, but it never hurts to ask).

[Update] Apparently the fonts on the ComboBox and "GO" Button are not embedded properly. Not sure why since they work properly in all other components. Anyone run into these font embedding issues before? Also, it appears that the bitmap font appears to be blurred. Not really sure why. Any comments would be welcome. [/Update]

[Update 2]Fixed the font embedding issue with ComboBox and Button. It was due to the fact that those components use bold versions of the fonts (which doesn't work with pixel fonts). Thanks to Kyle for pointing out that they weren't embedded properly. Just updated the fontWeight to "normal" and all is good. Also, the fonts are now sharp (they weren't previously because for some reason I set fontAntiAliasType to "advanced". The download link above has been updated with the new .air file.[/Update 2]

Previously, i discussed observations on UIComponent drawing. Before I follow with a simple example of how to apply that knowledge into extending a component, let's look at some of the other bits in UIComponent that might help you as you extend or build your own components (and that are used in the example I'll give):

• If your component contains other components or displayable classes that only need to get added once, you should set them up in the createChildren() method. This method gets run once, when the component is initializing.
• One of the things I love about Flex 2 is that it allows the creation of custom component styles with minimal effort. Basically, all you need to know is this:

  To create a new style, you use the "Style" metadata tag as follows in your component:
  

  [Style(name="myCustomStyle", type="uint", format="Color", inherit="no")]

  
  I won't go into details regarding all of the values for each of these tag attributes, but essentially, inserting this tag into your component automatically generates the style for you as well as events associated with style changes. The only thing left for you to do is capture the event and draw your component based on the value of the style. In order to do that, you use the styleChanged() method which looks as follows:
  

  UIComponent.styleChanged(styleProp:String):void

  
  When a style changes, this method is fired and gets passed the name of the style that has been changed (as you set in your metadata tag). Within this method you can use the new style value to draw the component. To access the value of your style, use:
  

  UIComponent.getStyle(styleProp:String):*

  
  This returns the value for your style.


• Unlike AS2, AS3 allows you to override internal player methods and getter/setters. UIComponent does this on many occasions (for example, x, y, width, height, addChild, removeChild, ...) so that it can capture changes in value and dispatch events or add additional functionality where needed. This is cool, but there are times when extending UIComponent or any Flex component that you want to directly access those overridden methods/properties. The Flex framework exposes those within UIComponent in the mx_internal namespace using the "$" prefix. If you extend a component, you can access those by doing something like:
  

  mx_internal::$height = value;

  
  For example, your component might draw a simple box that you just want to size using width and height rather than redrawing the graphics every time. In that case you can use $width and $height. Not often used, but still handy to know.

After seeing myFeedz and looking through the API, I figured I'd build something visual out of it, and this Tag Viewer is what came out of it. Some of the features include:

• Tag cloud and related post visualization
• Favorite tag list
• Tag search function that continually updates with tags
• Drag scroll UI

For me, the most interesting aspect was the drag scrolling and experimenting with different ways to scroll things horizontally and vertically. I've started to port it over to Flex, however, the one big obstacle I ran across was trying to get drag scrolling to work with existing containers (unfortunately, when you turn off the scrollbars, you also lose the ability to set V and H scrollPosition).

I noticed that the api urls tend to be quite slow in returning data (not sure exactly of the reason), so it's not as zippy as it could be. Also, the api really is currently limited to fetching tag clouds and posts, so it doesn't do everything that you can do through the myFeedz site.

Give it a try!

Since everything in the Flex framework essentially must be a UIComponent, we'll start with examining some of the inner workings of this class. In this Flexcerpt, we discuss how invalidation is implemented in UIComponent and why it is important when extending existing components or creating your own.

Invalidation is based on the premise that all displayable objects (anything that is a DisplayObject) are only drawn to the stage once every frame (since Flash is timeline based). In a nutshell, invalidation refers to delaying the drawing of a component until the next frame, so that we save processor cycles by only running that draw code once. "Drawing" can refer to things such as sizing (including measuring), displaying text, updating a skin, or changing any visible property of a component.

For example, what if the height value of a component was set 3 times during the same frame? If the component were to "redraw" itself immediately every time the height value was changed, it would be drawing 3 times, when it really only needs to draw itself once based on the last value that was set in that code block. This is a simple example, but when you consider that within the framework, there may be hundreds of lines of code executing when components are drawn (depending upon the complexity of your app), obviously, we want to prevent unnecessary redraws whenever we can. Enter invalidation...

There are 3 invalidation methods implemented in the framework:

• invalidateProperties (commits properties)
• invalidateSize (does measuring)
• invalidateDisplayList (does layout)

These methods are called interally within Flex components when the component has something done to it that requires it to be redrawn. Often, more than one of these will be called within the same method. Here is an overview of the code execution that occurs with each of the invalidation methods (not all called methods are shown here to simplify things a bit):

> UIComponent.invalidateProperties() > LayoutManager.invalidateProperties() > enterFrame/render > LayoutManager.validateProperties() > UIComponent.validateProperties() > UIComponent.commitProperties()

>UIComponent.invalidateSize() > LayoutManager.invalidateSize() > enterFrame/render > LayoutManager.validateSize() > UIComponent.validateSize() > UIComponent.measureSizes() > UIComponent.measure()

>UIComponent.invalidateDisplayList() > LayoutManager.invalidateDisplayList() > enterFrame/render > LayoutManager.validateDisplayList() > UIComponent.validateDisplayList() > UIComponent.updateDisplayList()

As you can see, the flow is very similar among these methods. So why does this really matter? Well, here are a few things I took from this:

• When extending components, the methods that you want to override if you want to draw things to your custom components are the ones at the END of the execution order, so specifically, "measure", "updateDisplayList" and "commitProperties". You can be assured that these methods will be called when needed to redraw the component. Don't forget to call the super's overriden method.
• When creating methods/properties in your component that will result in needing to redraw the component, make sure you call one of the invalidation methods. If the size is changing, call invalidateSize. If you want to update a text label, call invalidateProperties (and possibly invalidateSize and invalidateDisplayList if your label could have an impact on how your component is sized).
• Its important to note that if more than 1 of these invalidation methods gets called before the next frame, they will execute in the order above (ie., commit properties, then measure, then layout).
• Layout management plays a big role in all of this and is definitely worthy of a set of posts on its own. However, gist of it appears to be that measurement occurs "inside-out" and layout occurs "outside-in". So when measuring components for resize, the framework starts with the deepest nested child component and works up the parent chain, and once that's complete, it starts with the topmost parent and lays out its children, who then lay out their children, etc.
• Container based components also call Container.layoutChrome() from within updateDisplayList(). This is the method that draws any appropriate chrome around the container. Override this method when creating a container with custom graphics.
• Skins are generally drawn in the updateDisplayList method.
• Delaying drawing until the next frame is fine, but delaying properties (for example, TextInput.maxChars) could pose a problem because there will often be times when you need to set the value of a property then access that property's value before the next frame. So the solution is to store the value as a private variable that the getter will return, so if you need to retrieve the value, you're getting the correct value back. Once the next frame rolls around, then the value is actually set on the component (for example, maxChars gets set on the TextField contained within the TextInput).
• Related to the previous, when commitProperties is run, we need to know WHICH properties have been updated so that we don't do a wholesale property update on the component, and again use unnecessary cycles. The solution used in the framework is to set a flag within the component telling it which property has been updated (in the above example, "maxCharsChanged" is the flag), and then put your property commit code inside of an "if" statement that only runs if the flag is set to true. Could result in some longwinded code if you have a lot of properties, but it works.

To follow are more tidbits on UIComponent and examples of how to utilize these bits.

Please feel free to add your thoughts in the comments.

Not really an official Flexcerpt, but something that might be useful when embedding assets...

One thing that's been discussed a lot is the hassle of embedding assets in Flex and then adding them to the stage. At the core of the issue is that everything in the Flex world IS a UIComponent. This is necessary so that the framework can "talk" to components within it through a known API (particularly with respect to Containers). So if you try to create a custom class that extends, say flash.display.Sprite, and try to add it to the stage, you get a runtime error called something like "Type Coercion Failed". This is due to line 3301 in mx.core.Container (in the addingChild method):

// Throw an RTE if child is not an IUIComponent
var uiChild:IUIComponent = IUIComponent(child);

As you can see, a check is made to see if the child being added implements IUIComponent, and if it fails that check, then the error occurs. The sole purpose of that line of code is to throw a runtime error (uiChild isn't actually used elsewhere in that method). Grant has a very simple and effective solution to this called DisplayObjectWrapper. Head on over there and grab it, but basically, the premise is that since ALL Container based components in the framework require children to implement IUIComponent (ie., extend UIComponent), you can first wrap the asset in a UIComponent before adding it to the stage. Note that NON-Container based components don't have that same requirement for its children, which is why this works.

In Grant's example, he uses a DisplayObjectWrapper mxml tag to draw the asset to the stage. Works great. Then I tought, ok, let's use ActionScript instead of mxml to add it to the stage. Problem is that for some reason which I couldn't figure out, I couldn't access my asset's class from AS (to be honest, I haven't really done this as I generally use mxml to add assets). Then I stumbled upon this...

It appears that when the asset is embedded into the swf, it gets assigned a classname that looks like "ProjectName_AssetClass". So for example, let's say you have a project called "PhilterBlog", and you embed the following asset:

[Embed(source="assets.swf#Logo")]
public var Logo:Class;

Then you would do something like this:

import com.gskinner.ui.DisplayObjectWrapper;
var wrapper:DisplayObjectWrapper = new DisplayObjectWrapper(PhilterBlog_Logo);
addChild(wrapper);

Note the class name of the asset I used (PhilterBlog_Logo). Also note that you don't need to create an instance of your asset because DisplayObjectWrapper does it for you :)

Anyway, this is as much for my own reference as it is for others as I hadn't seen this elsewhere, but feel free to point me to other urls if this is widely known about embedding assets.

In Flex 2, it's pretty safe to say that we are presented with the largest framework ever developed for the Flash platform. What that means for us as developers is that we have more power at our fingertips than ever before to build larger, more robust applications. At the same time, it means that in order to use the framework at more than a surface level, we need to learn a lot about the framework API, as well as how to use the framework to build the custom bits and pieces that every project requires (i.e., components). If you've looked at the number of components and classes in the Flex framework, this appears to be a daunting task.

Adobe has done a great job of documenting the framework (my new best friend is the Flex Language Reference), but sometimes you need to muck around a bit to make the framework do what you need it to do in any given situation.

[Flexcerpts 201] is a series of posts that aims to break down the framework into bits (excerpts) and try to understand these bits better. If we can understand enough of these bits, hopefully we'll have gained a stronger understanding of the framework as a whole and how we can do things like extend components or maximize the use of existing ones.

Watch this space for posts in the coming days and weeks...

After taking a year away from the Flash world entirely (to reno and flip houses...that's a story for another day), I've returned to experience a sense of excitement and energy that I haven't felt personally since the days of Flash 3. Sure, there were other periods in Flash history that produced moments of near euphoria:

• ActionScript introduced in Flash 5
• Flash Video introduced in Flash MX
• AS2 in Flash MX2004
• Bitmap effects in Flash 8

However, the era that I look back on with the most warm fuzzies was back in the day when nrg.be and matinee.co.uk made heads spin with their sheer slickness and everyone hung on the edge of their chairs for the new version of Gabocorp. You know...the days when motion tweens were in, and TellTarget was for "real" coders. That was what birthed in me a REAL passion for Flash, and I knew back then it was what I wanted to do. Now it's 10 years later and things have changed substantially in a way that few of us would have predicted. A lot of Flash designers have moved into the role of "developer" and learned a thing or two about programming through this thing called ActionScript. And now we even have our own "developer" IDE in FlexBuilder. Who would've thunk it?

Yet, as I read the blog posts and see the excitement over Flash/Flex/Apollo/etc. I can't help but feel somewhat the same as I did 10 years ago. A sense of buzz over what the future holds for Flash, centred largely around this framework called Flex. A lot of people talk about how Flex has changed the Flash ecosystem (some wonder where designers are left in all of this). I can't help but think of the possibilities the future holds for us. At what point in the past have we had:

• Flash player being adopted as quickly as it is now.
• A framework and component set as rich and robust as that of Flex (having worked extensively on Flash frameworks before, I know that to build something that everyone - or at least a majority of developers - will find useful isn't an easy task)
• Flash being taken more and more as a serious platform
• A Flash based runtime that allows cross platform development of desktop apps!
• The explosion of new Flash/Flex jobs
• The financial backing of a company like Adobe to further move this thing in the right direction.
• A "real" developer IDE that Adobe has committed to improving upon (remember that the next version of Flex will target Flash player 9 - so this next version will be entirely IDE and framework improvements and not new player features)
• A build of the Flash IDE that will tightly integrate with Photoshop and Illustrator (though details on this are still unknown)
• The capability of even approaching realtime 3-D rendering in a practical way(rock on guys \m/ ;).

I think it's a great time to be a Flash/Flex developer. Even though we're far removed from the days of Flash 3, I anticipate looking back on these days 10 years from now with the same fondness as I do those days 10 years ago, knowing that we were on the verge of going somewhere bigger than we were (at least if I'm not off flipping houses... :)

I look forward to posting useful tidbits on anything Flash related in the coming days and weeks...

Testing the new blog setup...