Two-Point-Oh 2.0

I've moved to Behind the UI

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.

When using the profiler in Flex Builder 3 on the eBay Desktop project today I discovered something shocking: the application was giving memory back to my system!

Forrester has written an assessment of desktop RIAs written in AIR using eBay's project San Dimas as a case study. Here's the "teaser" paragraph:

The much-anticipated beta version of eBay San Dimas has arrived, ushering in a new era in rich Internet applications (RIAs). Adobe Integrated Runtime (AIR, formerly known as Apollo) applications like eBay San Dimas take RIAs out of the browser and put them on the desktop. These desktop applications enable occasionally connected use, customized content views, and a branded experience that can act as a platform for closer relationships with customers. But desktop RIAs aren't for everyone. Companies must assess whether their power users will benefit from the capabilities of AIR applications in a world in which the desktop will likely become very crowded

The marketing director at EffectiveUI cautioned me with this, "Keep in mind this Forrester report is written for a business audience instead of a technical one...This Forrester report would normally cost $400.00, but we are offering it free to executives who are interested in learning how to leverage desktop RIAs to improve their customer/user experience (via the eBay case study)."

If you're interested you can request the report here.

For most UIComponents if you set buttonMode="true" and useHandCursor="true" then when the user moves the mouse over the component the pointer will turn into the traditional hand pointer. However, with mx:Label components the hand cursor doesn't show up. It turns out that the fix for this is simple: if you set mouseChildren="false" on the label along with buttonMode="true" and useHandCursor="true" then the hand pointer appears.

Want to get a free ticket to the MAX conference? Our User Group is giving away one free ticket, see details of how you can win it here.

At work we recently had an email discussion about the best way to approach compound boolean statements in MXML. The problem is that MXML is a subset of XML, which means that you cannot have certain characters anywhere in your MXML, including &. So if you want to write something like this:

<mx:Canvas visible="{bool1 && bool2}"/>

The MXML parser chokes. There are a few ways around this, however. One approach championed by many here in office is to replace the & with "&amp;" which is the XML representation of an & character. So then your code looks like this:

<mx:Canvas visible="{bool1 &amp;&amp; bool2/>

Personally, I don't like this choice. If I read code from someone I didn't know and saw this I would think that they were not a great programmer. Basically it feels like a hack to me -- it seems clumsy and messy. Although
it takes a little more time to write, and perhaps a few seconds longer to read, I think that when compound boolean statements are needed in MXML a better solution is to bind the property to a function that performs the
boolean operation. In any other programming situation this would be an inappropriate use of a function -- merely executing a single boolean statement. But I think that given Adobe's decision to not give us any normal means to include "and" in our conditionals it is a better choice. The code then becomes:

<mx:Canvas visible="{checkMyCanvasVisible(bool1, bool2)}"/>
...
<mx:Script>
...
private function checkMyCanvasVisible(condition1:Boolean, condition2:Boolean):Boolean{
    return condition1 && condition2;
}
...

Notice that I pass the relevant variables (bool1 and bool2) as parameters to the function. This causes data binding on those two to function correctly. So my code will execute exactly the same as the other method. If either variable is bindable then the function will be reevaluated for the canvas's "visible" attribute when they are changed. If the function does not take the values as parameters then the function will only be evaluated once and will not update on changes to either variable.

In my opinion this leads to code that is easier to read and maintain. It takes a little longer to write and maybe a little more work to read through since you have to move between MXML and AS code to see everything. But I think that in the end it is easier to understand and maintain than a statement rife with unusual syntax and hard-to-identify operators, especially when dealing with statements that compound several operations. The best solution would be for Adobe to provide us with some alternative keyword (like AND, maybe), but unless that happens I think that moving to functions is the best solution.

The EffectiveUI project San Dimas team is at the eBay Developers Conference this week (June 11-13). We're having a great time here, but what we're really excited about is the unveiling of our desktop application for eBay, named project San Dimas. San Dimas is now in an invite-only beta. Luckily, requesting an invite is open to anyone (but limited numbers), so if you haven't already you should definitely sign up for an invite today. This is a true beta in the sense that the official launch of this project and its final features are dependent on the feedback we get from users during this beta period. So please, sign up for the beta, check it out, and tell us (through the feedback form on the San Dimas "Home" tab) about anything you'd like to see added or any bugs you find.

Project San Dimas is written in Flex on the Adobe AIR (formerly Apollo) platform (both Flex 3 and AIR are now in beta and can be downloaded from Adobe labs). This is one of our first major excursions -- and one of the first significant commercial projects -- into desktop development with Flex and AIR. One of the best things about AIR is that we can write apps for it in Flex almost identically to the way we write our web-based RIAs. So development is fast and we didn't have to learn almost anything new to do it. One of the coolest features in AIR is access to the local filesystem. The AIR API includes file access that is incredibly simple -- you can create a file object and read and write other objects to disk with a single call and AIR does all the work of reading/writing the data correctly, so its just like accessing any other data in Flex.

There are many instances where there is not a significant benefit in moving from the browser to the desktop. But there are several applications for which running on the desktop is highly beneficial. Discretion is necessary, but where applicable, moving an RIA to the desktop can have very exciting results.

Alex Uhlmann has created a great set of 3D animation classes for use in Flex. However, when using the Flip effect sometimes the front frame does not flip the whole way and a thin line is left along the axis of rotation until the entire animation is complete. The fix for this is quite easy: the Flip animation is actually two separate animations -- one to flip the front from facing the user to perpendicular to the screen and another to flip the back from perpendicular to the screen to facing the user. Alex does this with two separate tweens. As the tween progresses in FlipInstance he distorts the image the appropriate percentage to simulate rotation. However, when the first tween ends he does not make sure the front is distorted to 100% before beginning the back animation. So if your app doesn't get the tween progress callback very close to 100% then you get the gohst line. To fix this add the following line to the endFront function in FlipInstance.as (line 51):

That causes the front to rotate 100% -- which is perpendicular -- before the back animation begins. Add this line and you should never see that pesky artifact again.

Also, if you're using a ViewStack with Uhlmann's animation classes you may notice that the image 'blinks' before animation begins the first time. This is because the default behavior of a ViewStack is not to render a child until that child becomes visible. So when the animation begins the ViewStack has to render the back image, causing the entire thing to disappear for a second. To avoid this set add 'creationPolicy="all"' to your ViewStack. This tells the ViewStack to render all of its children when it is created. This will slow down initial display of the ViewStack, but the animations will be smooth.