3 posts tagged “adobe”
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 "&" which is the XML representation of an & character. So then your code looks like this:
<mx:Canvas visible="{bool1 && 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.
