Jacob Wright - Flex, AIR, PHP, etc.

Flex Styling without the Flex (example and source)

2009-08-31T17:14:32Z

Question: What’s 2.8KB, can style any DisplayObject on the stage, and enjoys long walks on the beach?

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.

Using AMF as a file format

2009-08-26T21:04:10Z

Flash is a great platform. You can build applications for the browser, the desktop, and… well, what else is there?

When building applications, especially those with a document-based model such as the Aviary apps, Odosketch, My Canvas, ZenStudio, the apps on acrobat.com, and many others, you need a file format for the document or project. Or some way to save it.

What Not To Do

You don’t want to save each item into a table in the database. I know a guy…who had a dream…that his friend did this. This guy’s friend in his dream had a table for each item that needed to be stored with foreign keys etc. When a project needed to be loaded, the server-side script did a ton of queries and created a sometimes-quite-large XML structure that it then sent to the Flash app. When saving, this XML was sent back and parsed back into the database with INSERTS and UPDATES.

That does not scale, and none of that data was needed to be pulled up in reports or anything that you might consider useful and require a database for. It was complex, hard to add features, and slow. That is, it would have been had that guy’s dream friend been real.

Warmer, warmer

Saving document/project files to disk is the way to go. You can store metadata about each project or document in a database if you are storing them server-side. If it is an AIR app, give it a unique extension and the user can double-click on the file to open it. If you are AIR only, you can save your file as a SQLite database file. Pretty sweet option, but doesn’t work for the browser ’cause Flash can’t do that. The format could be XML like OpenOffice documents and the new MS Office formats. You would need to parse the files in and out and they could get very large, so you’d want to compress them anyway.

Hot, burning, you’re on fire!

So, XML might be the most portable format, but hey, that’s what Import/Export dialogs are for, right? We’re talking about Save/Save As… :) Enter our new contender, AMF! AMF isn’t really new, however I haven’t heard of many people using it as their file format. The cool thing about using AMF is that after you’ve prepared your objects for it, you could store (in player 10) pieces of your document on the clipboard for copy/paste from one place to another (even after a page refresh or from AIR to browser!). You can do an auto-save of a document or page to the user’s SharedObject store.

Preparation and implementation

To use AMF as the format for you data you’ll need to prepare your objects sufficiently. Here are a few rules:

No required parameters in your constructors. When AMF unserializes it has to create those objects and assign the public properties to it. You’ll get errors otherwise.
Register your classes using flash.net.registerClassAlias or [RemoteClass(alias="...")]. This will store the registered alias name to map a class to a string for serializing and unserializing.
Use IExternalizable for more complex items that only need a few properties stored, or for Flash classes that can’t be stored (e.g. BitmapData). This allows you to get around the constructor parameter issue, but it is more work. :)
Make sure any data you need stored is a public getter/setter or you’ll have to use IExternalizable. AMF serialization will only store data that is public and read/write. If you think about it, it makes sense.

The way to store your document object or project object (or page, or widget, or whatever) to AMF depends on where you are storing it. There are a lot of Flash APIs that use AMF already. If you are storing it to SharedObject, just assign the item to the data property or one of its properties.

SharedObject.getLocal("_myProject").data.project1 = myProject;

To send it from one app to another over LocalConection is just as easy.

var conn:LocalConnection = new LocalConnection();
conn.send("_connName", "passProject", myProject);

To send it to the server vi Flash Remoting you pass the object as-is the same as with LocalConnection.

If you want to save the project to disk or pass it to the server in a RESTful manner or as a file upload, you’ll need to serialize it to AMF first. But that is pretty easy. Just remember to compress after you write it and uncompress before you read. This will save a lot of room.

var byteArray:ByteArray = new ByteArray();
byteArray.writeObject(myProject);
byteArray.compress();
// write the bytearray to file or send to server
// or we can pull it back out making a clone! (save as...)
byteArray.position = 0;
myProject = byteArray.readObject();

Easy cheesy. I will leave it as an exercise to the reader to figure out how to store it to the clipboard for copy/paste.

XML might be an easier format, though more verbose and prone to errors in the creation and parsing. Though it could allow for greater flexibility and accessibility to other programs to read the file.

Let me know if you use AMF for your document/project file storage. I’d be interested to hear how many people use this method and how well it has worked out for you.

Component Architecture, Two Approaches

2009-08-25T23:10:24Z

Been thinking about component architecture. Ok, so it’s a regular topic of discussion with Tyler. There’s a lot that goes into it, but at a high-level there seems to be two trains of thought, at least for me, that I’m trying to decide between: building for the component creator, or building for the component user. I’d like to discuss these two and round it up with the pros and cons. Maybe I’ll settle on one by that point.

Component Creator

The component creator wants legos. He wants the pieces he can build components with easily (when I say “he” I mean me). He is frustrated with extending, building, and wrestling with components in Flex.

So, we’re looking at splitting out the component into a skin (view), one or more behaviors (controller), and then perhaps some reusable model objects (um…model). The component creator wants an interface that describes the relationship between the component and the behaviors. Between the behaviors and the skin. It would be easy to assemble these into a component. Just drag-n-drop, right? You could create new and inventive and creative components all day! Beautiful.

Component User

The component user wants a shiny gadget. He wants to have a finished product that will do what he needs, out-of-the-box. He was very happy with Flex (until he needed a custom component, but that gets back to the creator). He is happy with solid components that are easy to use. He doesn’t want to know what the guts look like, and he doesn’t care, as long as it works well.

This guy (me too by the way) would have an interface for each type of component: IButton, ICombo, IList. And though he might not even know those interfaces exist, he would know what each component could do and would be pleased with it. The component might be made up of reusable models, behaviors, etc. behind the shiny API, but he wouldn’t know or care.

Which way is best?

So, is one better than the other? Or are we just hitting two different types of users?

The pro for the first model is that it would be easy to create new components. The con would be the steeper learning curve for people using the components. If you’re a component creator you’re probably thinking “yeah whatever, that’s not a learning curve, not more than anything else,” but it really is. You have to understand how the components work. It’s so easy to just drop a component down and read that it supports a “label” property. Learning a front-facing API is easier than learning interactions.

The pro for the second model would then be that it is easier to learn and use. The con, it could be implemented poorly underneath that nice interface, and would thus be hard to extend, modify, reuse. Here we have Flex (no offense Flex team). It’s getting better, especially with Flex 4, but backwards compatibility always has costs, and there is still a lot of cobwebs in there.

So, I suppose we could have reusable pieces in the implementation, but have the interfaces stay out of that and simply give us good API. If we made it easy for component users with shiny front-facing interfaces, and used behaviors and all that complex stuff under-the-hood so to speak, we could end up with easy components that were still extendable and reusable.

Response Pattern in ActionScript 3

2009-08-24T19:19:36Z

Earlier I posted about the Response Pattern. Today I wanted to show an ActionScript implementation and how it would be used.

The API I decided to go with for this pattern uses method chaining. This is one of those things where people love it or they despise it. I'm sorry if you are one of the latter. Method chaining is where an object returns a reference to itself as the result of its methods. This allows you to call many methods on the object in one line. jQuery uses this and it is used a lot in the Zend Framework. As example you might have a drawing API helper that does this:

PLAIN TEXT

Actionscript:

shape.fill(0x660000).rect(0, 0, 100, 100).fill(0x990000).rect(1, 1, 98, 98);

This would draw a red box with a darker red border around it, all in one line. If the above code gives you tingles in your stomach, you'll like response. If it upsets you, you can still use response with one method per line of code.

You can see in the interface IResponse that it has method chaining and supports a bindable progress property as well. The Response implementation has a few more methods that are useful when first creating a response. It allows events to trigger the complete cycle (which runs through the result handlers and calls them) or the error cycle. It also will create a flash.net.Responder object that can be used in NetConnection calls or other situations that take a native responder object. There are also some more advanced uses of Response which we might talk about another time. But let's see it in action!

I've posted my library of code I reuse on Google Code under the MIT license. Here you'll find a class called ImageLibrary. Here is how it works.

PLAIN TEXT

Actionscript:

// MySprite which extends Sprite
public function addImage(url:String):void {
var bitmap:Bitmap = new Bitmap();
addChild(bitmap);
ImageLibrary.getInstance().getImage(url).handle(addDataToBitmap, bitmap);
}
private function addDataToBitmap(data:Object, bitmap:Bitmap):void {
if (data is BitmapData) {
bitmap.bitmapData = data as BitmapData;
}
}

In this example, we have a result handler that sets the BitmapData object to the bitmap object. We could have created and added the bitmap to the Sprite in the handler, but I wanted to show how you can pass extra parameters to the handlers in the handle(resultHandler:Function, ...rest) method. Another thing to note, is that if we were to add the same image to our MySprite class again, addDataToBitmap would be called instantly because ImageLibrary caches the results of previous calls so that the player won't have to load them from the server again. This results in virtualized lists having the images instantaneously showing up after the first load.

The RemoteProxy class is a Flash remoting service which is extremely small. It uses Response.

PLAIN TEXT

Actionscript:

public function loadContacts():IResponse {
var service:RemoteProxy = new RemoteProxy(gateway);
// call the list operation and then handle the results with setContacts
// and handle errors with errorLoading
return service.contacts.list().handle(setContacts).handleError(errorLoading);
}
public function setContacts(contacts:Array):void {
_contacts = contacts;
}
protected function errorLoading(error:Error):void {
Logging.log("Error loading contacts: " + error.toString());
}

In this example we pass the Response object along so that whoever is calling loadContacts can know when the result is ready or if there was an error.

Here is a list of some of the classes I've made which use Response:

This is just a little taste of using the Response Pattern. I have found it much nicer to use when you are waiting for the results of a particular call. Event listeners are still useful for user input and for socket-based libraries such as XMPP or FMS, but I like Response for most other async operations.

The Response Pattern

2009-08-31T18:26:10Z

I don't presume to place myself at the status of GoF or Martin Fowler, but I came up with a concept that was then improved upon by my twin brother, Tyler, which I feel could stand to be called a pattern. I may not be the first one to do this, but if I am, then it really shouldn't be called a pattern since design patterns are observable patterns found in a lot of code that can be documented and generalized. I apologize in advance if it should not hold "pattern" status, but I think it is worth discussing, so please be kind. It's pretty simple in concept, and has turned out to be quite useful in practice. I call it the Response pattern.

This pattern was developed for ActionScript 3, but might be applied to JavaScript or other languages where functions or methods can be passed by reference.

The Problem

Services (being used in the sense of web services being consumed) or other asynchronous operations must be responded to and handled correctly. Often the data returned will be formatted before it is passed on to the caller for consumption. Sometimes the data has been retrieved previously and cached by the system, requiring a check to the cache before calling the service.

Two existing solutions exist, the Callback and the Subscribe solution. Both of these have their drawbacks.

The Callback is a simple solution in which a method is passed in as a parameter of the service call. This method will then be called and passed in the results of the service call once the asynchronous operation is complete. While this is easy and simple, it only allows one method to respond to the call and additional complexity must be added to handle errors which might occur.

The Subscribe solution allows objects to subscribe to messages (or events) which may be broadcast by an object. This solution is the Flash player and Javascript's event model with addEventListener etc. Some good things about this solution it it allows many methods to handle the results of a service call. It also allows you to "listen" to errors as well as results. While this solution works great for user interface events which may happen at any time, it has significant drawbacks for asynchronous service calls. The primary drawback is that when a service call is made the method handling the result cannot be sure which call it is handling. For example, you wouldn't want a QUERY_RESULT event to be dispatched to handle queries because what if several objects in your system called a query? You'd have one method expecting a list of users but it might get a list of addresses first. In order to funnel results you have to become very specific in your events such as USER_QUERY_RESULT, and then you have a host of events you need to support. Though this solution does not promote formatting of data, it doesn't prohibit it. If you add your listener first, you can modify the result data on the event object before other listeners get to it. This can be tricky however since you can't always guarantee the order of the listeners.

There needs to be a way to handle the results of a service call that:

allows you to deal with the results of a specific call (not any that match some event name)
handles errors
allows more than one method to respond to an operation
allows methods to format the data in set order
allows synchronous operations with the same method (e.g. a cached item in memory can be returned)

The Solution

Participants

Service: An object or objects which facilitate calling remote system asynchronously. This may be a webservice API but may also include loading resources such as images.
Handlers: A "handler" is a method or function which handles the results or errors of a call from the service.
Formatters: A handler which formats the data or converts it into a different data type for other methods handling the results or errors.
Response: An object that stores the handlers and formatters and calls them when the service results (or errors) are returned.

Interaction

When a call is made on a service, the service returns a Response object. The caller of the service may then add handlers to the response object. When the call is completed or receives an error, the response object is told to call the result handlers or the error handlers. Each result handler will have at least one parameter which the data from the result (if any) will be passed into. Each error handler will have at least one parameter which the error will be passed into. If a handler method returns a value, that value will become the new data/error. Thus a handler becomes a formatter taking the data it receives and converting it or changing it to a new type of value.

This solution allows for layers of services which abstract the lower level from the higher. The following is an example of how the response might be used.

Example

A system depends on a RESTful XML web service. A low-level service class has been created which loads HTTP data, we'll call it WebLoader. This class uses the response pattern and is used to load images, documents, etc. from the web. Another service class called XMLLoader is layered on top of WebLoader, that is, it uses a WebLoader object to handle the low-level loading of an XML document from the web, but then converts that document into an XML object the system can use. Finally, a system specific service is layered on top of these other two utility services, called MyLoader. MyLoader takes XML objects and converts them into domain-specific objects, such as User, Product, or Contact.

The system needs to load all the contacts for the logged-in user and display them on-screen. It calls MyLoader.loadContacts(), which in turn, calls XMLLoader.load("http://example.com/contacts.xml") which in turn calls WebLoader.load("http://example.com/contacts.xml"). The WebLoader.load call creates a new response object and stores it for when the result is loaded or an error occurs. Once created it returns the response object from the load method. The XMLLoader.load method receives the response object, adds a handler to it called stringToXML which takes a string, parses it, and returns and XML object, and then returns that response object from its load method. The MyLoader class receives the response object, adds its own handler, xmlToContacts, to format the XML into a list of Contact objects and returns the response. The system receives the response object and adds its own handler, displayContacts, to display the list of contacts on the screen.

When the load is completed, WebLoader calls complete(data) on the stored response object. The response object then loops through the handlers added to it, calling stringToXML first, receiving a value back from it, passing that value into xmlToContacts, receiving a value back from that, and passing a list of contacts into the displayContacts handler which doesn't return anything, but displays the contacts.

Let's add a cache to our MyLoader class. When the contact list is loaded, it stores the array of contacts in memory. Next time loadContacts is called, the MyLoader class creates a response object, calls complete(cachedContacts) on it, and returns it. Then, as soon as the caller adds displayContacts handler to the response, the response calls displayContacts and passes in the array of contacts which was cached. Thus, the caller doesn't need to know whether the call has been cached or not, whether it is asynchronous or not.

While this may sound like a lot is going on, it is actually quite simple and allows service classes to be created and added to libraries for use in other systems. In the XMLLoader example, you don't have to know or worry about how it gets the XML, the calling class can just know that it will receive XML in the response. The same goes for the MyLoader class. These services can be layered on top of each other like TCP and HTTP do, abstracting the higher levels from the lower levels.

Conclusion

The Response Pattern is something I made up. I created a Response class and as I've been using it more and more, it has turned out to be extremely useful and fun to use. I have found it much more preferable to using event listeners, Responder objects, and callbacks in Flash. I have wrapped the SQL classes in Adobe AIR with a service class that uses Reponse to make asynchronous database operations palatable. I have wrapped the File class for AIR. I have created a teeny tiny version of RemoteObject called RemoteService that uses Response. And I have created an ImageLibrary class which stores loaded images for me and resizes them to the size I need. Because it stores the images, sometimes calls are asynchronous and sometimes synchronous, but it is handled the same either way.

I plan to put together a library of often used services that are built around this concept for everyone to use. But until then, you can find a version of the Response class in the flight.net package of the Flight framework.

Update: I posted about the ActionScript implementation of the Response pattern. You can see how it is used and why it is different. It looks similar to other type of implementations, but if you ever use it you'll see how different it is. It's the littlest things in life that make the biggest differences.

Best Show I’ve Seen

2009-08-01T03:32:57Z

Just wanted to let you know about a show I've fallen in love with. I've seen the commercials and thought it might be interesting to watch, but never got around to it. Once I saw a few episodes I was totally hooked.

A couple of weeks ago I watched two seasons of NBC's Chuck within 48 hours. I has become my favorite TV series followed by The Office and Lost, and I can't wait for season 3 to air next March. You can watch all 13 episodes from season 1 starting with the pilot on Warner Bros website. The second season has only about half of its 22 episodes online at nbc.com or hulu.com. You'll have to rent the DVD or buy episodes on iTunes. You can buy both seasons on iTunes and xbox live I believe.

Be sure to catch up on the first two seasons so you can be up on season 3!

High quality, high performance thumbnails in Flash

2009-09-03T17:03:20Z

Ever need a thumbnail of an image in Flash? I do, and honestly speaking, the resampling that Flash does is less than ideal. Unless you only need to resize by half or bigger. But my thumbnails usually need to be smaller.

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.

Regular BitmapData.draw() method without smoothing (0 miliseconds)
Regular BitmapData.draw() method with smoothing (1 miliseconds)
Using my own method that resizes by the odd scale first, then by halves (8 milliseconds)
Using my method but after the odd scale, only scaling down by quarters (33 miliseconds)
Using the voq Lanczos3 method with easyScaling at .25 and sharpening (694 miliseconds)
Using the voq Lanczos3 method with easyScaling at .25 and no sharping (676 miliseconds)
Using the voq Triangle method with easyScaling at .25 and sharpening (275 miliseconds)
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.

PLAIN TEXT

Actionscript:

private static const IDEAL_RESIZE_PERCENT:Number = .5;
public static function resizeImage(source:BitmapData, width:uint, height:uint, constrainProportions:Boolean = true):BitmapData
{
var scaleX:Number = width/source.width;
var scaleY:Number = height/source.height;
if (constrainProportions) {
if (scaleX> scaleY) scaleX = scaleY;
else scaleY = scaleX;
}
var bitmapData:BitmapData = source;
if (scaleX>= 1 && scaleY>= 1) {
bitmapData = new BitmapData(Math.ceil(source.width*scaleX), Math.ceil(source.height*scaleY), true, 0);
bitmapData.draw(source, new Matrix(scaleX, 0, 0, scaleY), null, null, null, true);
return bitmapData;
}
// scale it by the IDEAL for best quality
var nextScaleX:Number = scaleX;
var nextScaleY:Number = scaleY;
while (nextScaleX <1) nextScaleX /= IDEAL_RESIZE_PERCENT;
while (nextScaleY <1) nextScaleY /= IDEAL_RESIZE_PERCENT;
if (scaleX <IDEAL_RESIZE_PERCENT) nextScaleX *= IDEAL_RESIZE_PERCENT;
if (scaleY <IDEAL_RESIZE_PERCENT) nextScaleY *= IDEAL_RESIZE_PERCENT;
var temp:BitmapData = new BitmapData(bitmapData.width*nextScaleX, bitmapData.height*nextScaleY, true, 0);
temp.draw(bitmapData, new Matrix(nextScaleX, 0, 0, nextScaleY), null, null, null, true);
bitmapData = temp;
nextScaleX *= IDEAL_RESIZE_PERCENT;
nextScaleY *= IDEAL_RESIZE_PERCENT;
while (nextScaleX>= scaleX || nextScaleY>= scaleY) {
var actualScaleX:Number = nextScaleX>= scaleX ? IDEAL_RESIZE_PERCENT : 1;
var actualScaleY:Number = nextScaleY>= scaleY ? IDEAL_RESIZE_PERCENT : 1;
temp = new BitmapData(bitmapData.width*actualScaleX, bitmapData.height*actualScaleY, true, 0);
temp.draw(bitmapData, new Matrix(actualScaleX, 0, 0, actualScaleY), null, null, null, true);
bitmapData.dispose();
nextScaleX *= IDEAL_RESIZE_PERCENT;
nextScaleY *= IDEAL_RESIZE_PERCENT;
bitmapData = temp;
}
return bitmapData;
}

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.

Flight Framework at 360|Flex!

2009-05-15T18:29:20Z

Another reason to attend 360|Flex is the Flight Framework will be there. We'll be doing a workshop-style presentation Tuesday on getting started with Flight. Hope to see you there!

Would it be bad to leave behind our Flash roots?

2009-05-14T18:50:33Z

I am working with Tyler on Stealth, our high-performance component framework. After reading this article on performance by Arno Gourdol of Adobe I began wondering if we should leave behind our Flash roots of motion and timeline design by defaulting framerate to 0 in our Stealth-based applications.

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.

Sweet Gumbo/Spark interfaces

2009-05-01T18:32:39Z

Hooray for the Flex team! They're coding to interfaces. I've been looking through the source of recent Flex 4 code and I have to say, I'm getting excited to use this stuff. Here are a few of the things I've found with just a few minutes of going through their code:

IDeferredContentOwner - The current version of Flex has something like this, but much more complex. This interface makes sense, and simply allows the deferred creation of its children when they are needed (such as a ViewStack in the current Flex). Just a couple of properties and it allows the component to figure out how to do it.

IViewport - This allows any component to have scrolling. What a step forward from the current monster called Container which we probably use more than any other component for layouts (e.g. Canvas, HBox, VBox).

IGraphicElement - This interface is pretty sweet. It allows 1) objects to be drawn on the same DisplayObject (e.g. several Rects could all be drawn on one Shape) and 2) it allows non-DisplayObjects to be used as children of Group by providing their own DisplayObject. I can think of some pretty fun things to do with that as far as custom components/functionality is concerned. :) Maybe I'll join the OpenFlux initiative and talk more with Ryan Campbell and Ben Stucki about this one.

There's some good things cooking in the Adobe kitchen. I'll write about more as I discover it.