Behind the UI

Mac OSX MySQL installation problem

2010-03-02T09:50:00.000-08:00

I recently installed MySQL via homebrew (which I highly recommend). However, when I tried to use the MySQL or MySQLAdmin clients I got an error saying that I couldn't connect to the server through /tmp/mysql.sock. Manually creating the file and running mysqld got me a bit further, but mysqld was failing with another error related to permissions. I finally found an official MySQL bug thread with the solution. Their problem was related to the upgrade installer distributed by MySQL, not with the homebrew install, but I found that the solution worked anyway -- I just needed to run this command (assuming a homebrew installation for the path):

/usr/local/bin/mysql_install_db --rpm

Then I launched mysqld and everything was good to go.

CFUnited Materials

2009-08-13T08:55:00.000-07:00

My CFUnited powerpoint slides are here.

And the application I wrote during my session, along with the necessary helper classes, is here.

Custom Flex Binding with PropertyChangeEvent

2009-08-02T13:17:00.001-07:00

In Flex we have a very powerful tool in the [Bindable] metadata tag. However, it can also be a huge source of inefficiency. Basically, when you mark a property as [Bindable] the compiler adds code that dispatches a generic PropertyChangeEvent typed "propertyChange" when the property changes. Whenever this event is detected, the bindings on your property are evaluated. This is all good and fine until you have a bunch of properties that are all marked as [Bindable]. Now the player is watching for the same event type ("propertyChange") for all your bindings for all your properties. So any time one of them changes the player has to look through all the properties in your class to find the one that actually needs to have its bindings reevaluated. Very inefficient.

Thankfully, the people at Adobe at least gave us a way to work around this CPU deathtrap. You can mark your bindings to evaluate on a custom event type like this: [Bindable('myCustomEventType')]. If you use this wisely then the player will know exactly which property to check out when it detects the event, moving the binding evaluation time back from O(n) to constant time. Much better.

In past projects I've used this method with generic fash.events.Event objects to great success. However, on my current project Jonathan Branam, the lead architect, wanted to be more "correct" and use custom PropertyChangeEvents. Okay, makes sense, should be no problem, right? Well, it was a small problem. So, I set up my custom binding like this:


/**
* The current number of bytes loaded by the server during upload.
*/
protected var _bytesLoaded:int = 0;
[Bindable('bytesLoadedChanged')]
/** @copy #_bytesLoaded **/
public function get bytesLoaded():int{
   return _bytesLoaded;
}
public function set bytesLoaded(value:int):void{
   if(_bytesLoaded != value){ // only set the value if its different
      var oldValue:int = _bytesLoaded;
      _bytesLoaded = value;
      dispatchEvent(new PropertyChangeEvent('bytesLoadedChanged', 
                    false, false, PropertyChangeEventKind.UPDATE, 
                    _bytesLoaded, oldValue, value, this));
   }
}

Then I ran my code and the bindings didn't evaluate. It looked right to me, so what was the problem? I looked at the documentation for PropertyChangeEvent (duh, probably should have been a first step) and found this for the "property" property: "A String, QName, or int specifying the property that changed." So, the "property" property of the PropertyChangeEvent should be the NAME of the property that changed, not a reference to that property (follow that?). That amounted to changing three characters, instead of:


dispatchEvent(new PropertyChangeEvent('bytesLoadedChanged', 
    false, false, PropertyChangeEventKind.UPDATE, 
    _bytesLoaded, oldValue, value, this));

I now have:


dispatchEvent(new PropertyChangeEvent('bytesLoadedChanged', 
    false, false, PropertyChangeEventKind.UPDATE, 
    'bytesLoaded', oldValue, value, this));

And now my bindings work! For some reason having that property set incorrectly was preventing the player from identifying that I had dispatched a binding event. My guess is that it silently was causing an exception in the PropertyChangeEvent constructor, but I'm not sure. What I do know is that now my bindings work, they're efficient, and they're "correct." And I'm happy.

How to make Safari 4 open tabs at startup

2009-06-10T14:16:00.000-07:00

I decided to give Safari 4 a try and the inability to set it to open the last set of tabs at start up is driving me crazy. I found a solution that, although not ideal, works well enough to get me by until Chrome comes out for Mac. Its an easy enough solution:

1. Create a new bookmark folder
2. Add the tabs you want to be opened to this folder and order them
3. Goto preferences and set "new windows open with:" to your startup tabs folder

Now when Safari starts it will load those tabs. Unfortunately, these tabs will also load when you open a new window. And if you happen to have a tab open that you wanted to keep and you close the app its gone. You can go to "History->Reopen all windows from last session" in desperate situations. This isn't as nice as just remembering the tabs that were open (like every other modern browser), but its passable.

Caching Images to Disk with AIR

2009-06-09T15:29:00.001-07:00

In an application I'm currently working on, I create images within the application and want to store them to load later. Because I store the image data in a model object that might be used many places in the running application, I keep the data in memory as a BitmapData object. This turned out to be a problem because you can't write BitmapData objects to disk. Instead you have to write the data to a PNG or JPEG and then save the byte array from that object, and reverse the process to load the data. There may be another way but this is the only solution I could find. Here is my class:


package com.effectiveui.models.widget
{
    import flash.display.Bitmap;
    import flash.display.BitmapData;
    import flash.display.Loader;
    import flash.events.Event;
    import flash.utils.ByteArray;
    import flash.utils.IDataInput;
    import flash.utils.IDataOutput;
    import flash.utils.IExternalizable;
   
    import mx.graphics.codec.PNGEncoder;
   
    [RemoteClass(name="com.effectiveui.models.widget.WidgetCategoryDataModel")]
    public class WidgetCategoryDataModel implements IExternalizable
    {
        public var imageData:BitmapData;
       
        protected var loader:Loader;

        public function WidgetCategoryDataModel(){
            loader = new Loader();
            loader.contentLoaderInfo.addEventListener(
                   Event.COMPLETE, handleBytesLoaded);           
        }

        public function handleBytesLoaded(event:Event):void{
            imageData = Bitmap(loader.content).bitmapData;
        }

        public function writeExternal(out:IDataOutput):void{
            var encoder:PNGEncoder = new PNGEncoder();
            var bytes:ByteArray = encoder.encode(imageData);
            bytes.position = 0; // may not be necessary
            out.writeDouble(bytes.length);
            out.writeBytes(bytes);           
        }
       
        public function readExternal(input:IDataInput):void{
            var length:Number = input.readDouble();
            var pngData:ByteArray = new ByteArray();
            input.readBytes(pngData,0,length);
           
            loader.loadBytes(pngData);
        }
    }
}

You can download the class here.

Traction update

2009-06-09T15:28:00.001-07:00

I added some screen shots to the Traction website.

Stateful to Stateless Skinning Script

2009-04-08T14:55:00.000-07:00

Patrick Hansen has a cool solution for converting stateful skins to stateless.

Followup on Stateful Skinning

2009-03-25T12:07:00.000-07:00

We got in touch with Adobe about our problems with stateful skinning. Their response was that all the enter frame handlers are necessary for, "tracking size changes, states, playing transitions, and the general overhead involved with implementing IUIComponent." They gave us a special version of the UIMovieClip class that removed logic for handling size changes since that's not necessary in skins. However, even with this change the state-based skins still took up far too much CPU for us to use them in production. In the end we moved to old stateless skins and now our application idles ~10% CPU usage, as is more typical for AIR applications. The take away message: state-based skins are really cool, but they probably aren't suitable for use in applications that are expected to be left open while the user does anything else on their computer. They probably aren't ever suitable for large applications, either.

Flex Component Kit: CPU black hole

2009-03-05T10:13:00.001-08:00

On a recent AIR project we tried to use state-based skins using the Flex Component Kit, as recommended by Adobe. This route was much cleaner and faster than the old, stateless method. And everything seemed great at first. However, as the app grew we noticed that our CPU usage while idle was getting ridiculous (70-80%) and made the disturbing discovery that removing our CSS allowed our CPU usage to plunge back to standard AIR levels (5-10%).

With a little more research we determined that the stateful skins seemed to be the culprit, so we created a simple test program to test our theory. In this program we have a single MXML component that is a standard WindowedApplication component that contains 500 checkboxes. We put together a simple checkbox skin with the stateful method and another that is stateless.

To establish a baseline we ran the application without loading either CSS file. The resulting CPU usage was within the typical range for AIR applications (5-10%). The 500 boxes themselves did not seem to add any CPU usage, as expected.

Then we loaded the stateless skin's CSS file and saw identical CPU usage. Again the behavior was what we expected -- skinning does not add any extra CPU usage. Since there is no activity or animation on our check boxes, having a skin loaded should not require ongoing computation. So far so good.

Finally, we launched the application loading the stateful CSS and this time our CPU usage was a staggering 50% and it stayed there. We ran the profiler to see what was going on. A few seconds after the application started we saw 377 EnterFrameEvents, which is quite a few but not drastically more than other calls in the application. 40 seconds later the count was 5190. Clearly something in the stateful skinning was causing our application to redraw continuously.

Now that we had established that the stateful skinning was the problem we wondered whether it was something about our SWC itself or if it was something about each individual skin. To test this we ran the application with different numbers of checkboxes. Running with 100 boxes we saw a CPU usage of 19% -- twice that of a normal application, but still relatively low. 250 boxes used 30% CPU, and, as noted above, 500 boxes used 50%. This seems to indicate that there is some error in each skin. We didn't see our checkboxes animating through states, so the state separation seems to be working correctly. There is something in each state's generated skin that doesn't stop playing once its drawn.

This discovery explains why a Google search doesn't turn up a myriad of complaints about Adobe's new recommended workflow -- the average application probably doesn't have hundreds of skinned components instantiated at once. Many applications probably have 100 or fewer, meaning that their increased CPU usage may not have set off any red flags. Furthermore, many applications include running animations or additional processing which would take the blame for increased CPU usage. No matter the reason, it appears that this bug has largely gone unnoticed but can have devastating effects on large applications. Hopefully Adobe will have a fix out quickly, otherwise it will be back to stateless skinning misery for us.

Read more about stateful skinning from Patrick Hansen, one of the designers at EffectiveUI who worked on this project with me.

Traction: Version 1.0.4

2009-01-16T16:19:00.001-08:00

Version 1.0.4 of Traction was just released. This version fixes a bug where tickets created in Traction did not have the "Reported By" field filled in. Now Traction automatically sets the logged in user as the reporter when tickets are created. Here's the link to the downloads page.

I was also asked to add support for the Comments section of the Trac interface. Unfortunately, this area is currently not viewed as part of a ticket object and the XML-RPC implementation for Trac only gives access to the Ticket and Wiki areas. If support is ever added for the Comments section I will be happy to add it to Traction.

Version 1.0.4 was created as a direct response to a request by a Traction user. If you use Traction and find bugs or wish it had features it doesn't, please comment here or send me an email. I'm not actively developing Traction right now, so the only way bugs are going to be fixed or features added is if you make me aware of the need.

Mac Terminal Themes

2008-10-27T10:25:00.000-07:00

I recently upgraded the view on my terminal to be something more readable than anything that comes with OSX. However, I don't really like the red color that comes with that theme -- I feel like its more of a salmon color, and I want something really RED for my red. Anyway, I changed the color using the Terminal preferences, no problem. But every time I restarted the terminal my color scheme would reset to the colors that came with IR_Black. The problem is there is no way to edit a color theme for Terminal, so all changes are temporary unless you create a new color theme. The solution: make all the color changes you want to your theme, then use the options menu to "Duplicate Settings" and make a new color theme. Its kind of a pain to have to create a whole new color theme every time you want to tweak, but it works.

Skinning in Degrafa

2008-10-10T08:39:00.000-07:00

I know, I'm way behind the times, but I had my first experience skinning in Degrafa on a project last week. My perception of Degrafa previously was that it was a nice framework to give you markup for skinning, but doesn't really add anything over the Flex drawing API. This is partially true -- Degrafa doesn't do anything you can't do on your own with the graphics package. However, in true component programming spirit, they've abstracted the graphics package to the point that its almost stupid-easy to use. For very simple tasks it might not be worth bringing in Degrafa. For example, on this project I needed to skin a radio button to be pill shaped. I could have used Degrafa, but with the drawing API this is all the code I needed (in a skin class):


protected override function updateDisplayList(w:Number, h:Number):void{
   super.updateDisplayList(w, h);
   graphics.clear();
   if(name == "upSkin"){
      graphics.beginFill(UP_COLOR);
      graphics.lineStyle(1,UP_COLOR);
   } else {
      graphics.beginFill(DOWN_COLOR);
      graphics.lineStyle(1,DOWN_COLOR);
   }
 
   graphics.drawCircle(w - h/2, h/2, h/2);
   graphics.drawCircle(h/2, h/2, h/2);
   graphics.endFill();
   if(name == "upSkin"){
      graphics.beginFill(UP_COLOR);
      graphics.lineStyle(1,UP_COLOR);
   } else {
      graphics.beginFill(DOWN_COLOR);
      graphics.lineStyle(1,DOWN_COLOR);
   }
   graphics.drawRect(h/2, 0, w - h, h);
   graphics.endFill();
}

Not bad -- forget the repeated if statement and its only 13 lines of code. But later in the project I needed to put a gradient in the background of several components. I could have used the drawing API and a skin to accomplish this, or I could just add this inside the components MXML:


<degrafa:Surface height="100%" width="100%">
 <degrafa:fills>
  <degrafa:LinearGradientFill id="backgroundFill" angle="90">
   <degrafa:GradientStop alpha="1" color="0x555555" ratio="0"/>        
   <degrafa:GradientStop alpha="1" color="0x787878" ratio="0.2"/>
  </degrafa:LinearGradientFill>
 </degrafa:fills>
 <degrafa:GeometryGroup>
  <degrafa:RegularRectangle height="{height}" width="{width}" fill="{backgroundFill}"/>
 </degrafa:GeometryGroup>
</degrafa:Surface>

I prefer this way. Not only is it less code, but its easier to think about. And, in my opinion, that's what OO and component programming are all about: tackle a difficult task on the scale where its a simple task and create an abstraction so that the complex task becomes a series of easy tasks. Degrafa went down into the drawing API where each task is (relatively) easy and built up a framework so that we can do complex tasks as a series of completely intuitive easy tasks. Degrafa can also be used to make skin classes (as opposed to putting the Degrafa right in the component layout like I did in this case) and works great with CSS. They have tons of examples with source on their site and you can also get the SWC there.

Announcing Traction

2008-09-18T12:03:00.001-07:00

Over the last several months I've been working on an app called Traction which is now ready for the general public, although it is still in development. Traction is an Open Source (GPL) frontend to the ticket tracking service Trac. Traction is written in AIR and uses Adobe Flex. Using Traction you can interact with your Trac tickets real time — in line edting, tabbing between fields, and filtering. This makes the process of organizing and modifying tickets far easier than the HTML interface offered on the web. Also, Traction caches your tickets locally so you only have to update new tickets every time you login, which makes the experience that much faster. You can also use Traction to create new tickets and track user “scores” which are calculated based on the priority of tickets closed by each user. Visit the Traction download page for the repository URL and the latest binary.

Adding Exclusion to Flex Logging

2008-09-04T13:17:00.000-07:00

The built in Flex logging package (mx.logging.*) provides a "filters" property for logging targets that allows developers to dictate which classes' logging messages get logged by each target. However, this is an "inclusive" filter. What I mean by that is that this filter tells you what does get logged. There is no support for an "exclusive" filter which would allow developers to specify certain classes to ignore logging messages from. I can see the benefits of an inclusive filter, but for a project the size of eBay Desktop we really need an exclusive filter so we can easily see logging messages for the entire app except for areas we aren't currently interested in. Its sometimes more important to filter out than to filter in.

It turns out that adding an exclusive filter to Flex's logging package is fairly simple. All you need to do is modify the base target interface, ILoggingTarget, to have an additional array of classes to ignore. Then you modify the Log class so that anytime it wants to add a logger to a target it checks to see that the logger's category is both included in the target's filter array and not excluded by the exclusion array. If not then the logger is not added to the target. This amounts to about five lines of code between the addTarget and getLogger functions of Log.

I've subclassed the core logging classes (Log and ILoggingTarget) as well as some of the base target classes (AbstractTarget, LineFormattedTarget, TraceTarget) to include exclusion filtering. You can download a zip here.