I was recently asked to troubleshoot some legacy code where an HTTPService call was (sometimes) failing on the server side due to malformed XML payload in a String parameter.  On the client side, the XML was being created as a String from user input, which opened the door for invalid characters to be injected directly into the markup.

Rather than refactor the process that generates the XML altogether, I set out to see if there was a simple approach to simply escape the special characters and keep the rest of the String intact. I started to explore functions like HTMLEncode, thinking I could find functionality similar to what I needed.

Ultimately, the solution was far simpler.

It turns out that casting an XML-formatted String to an instance of the XML class handles special characters and performs all of the necessary logic to escape any offenders. So by simply constructing an XML object from the source String, then calling toString() on the XML object, we can effectively sanitize the original String into valid markup that can be parsed as expected.

Nifty.

When working in Eclipse/Flash Builder, occasionally something wacky will happen in a project or the workspace itself that causes the following message to appear: "An internal build error has occurred. See the error log for more information." In some cases, a refresh and/or clean of the project in question is enough to straighten things out. But if that were always the case, this would be a very short blog entry, and that's not really my style.

I recently encountered the "internal build error" monster when working with a Flex module I hadn't touched in months. I simply opened it up and tried to build it, and I was instantly on my way to bang-my-head-against-my-desk-in-frustration territory. Nothing about the project had changed, so all signs pointed to something in the development environment. But what?

[More]

You heard it here first: My as-talented-as-she-is-beautiful wife just rolled out her brand spankin' new graphic design portfolio website, and she is accepting freelance clients! Head on over to designery26.com and check it out, particularly if you're in the market for print layout, online design, brand development, marketing, etc. You'll find that designery26 is a cut above!

"You should know that my recommendation is essentially a guarantee." -Ron Swanson

This has been a source of frustration for such a long time, I had to share the solution. Credit for this one goes to Martin McBrearty, and there are a few other blogs out there that support this method.

Important Disclaimer: This method does not appear to be officially supported, and is not guaranteed by me or anyone else to work. Use at your own risk!

[More]

First things first: Aldiko is not the only app to offer free e-books to Android users. Amazon's Kindle app has been available for a while now, offering access to a wide range of free and paid literature. Overdrive serves up content through a partnership with many public libraries, allowing patrons to virtually borrow books. There are also a number of other e-book readers easily found by searching the Android Market. But many are restricted by proprietary delivery systems and digitally copyrighted content. Aldiko is a different breed.

[More]

Have you ever left the house in a hurry, only to realize you need an important document from your desktop PC? If only there was an elf standing by, able to email it to you... TeamViewer is that elf.

[More]

Today I spent hours tracking down a bug related to inserting and/or deleting data from a Tree control. In certain circumstances, an update to the underlying dataProvider would cause the following to be reported:

After a bit of Googling, I found that I am not alone. Other folks have the same issue with Tree. Even more common, it looks like people are getting the same error when manipulating data in an AdvancedDataGrid, in which case it is reported as:

After drilling down into the Flex Framework source and exploring the makeRowsAndColumnsWithExtraRows function, I added some watch expressions in the Flash Builder Debug pane. (The debug features are really, really useful for this kind of thing.) The culprit? The value for verticalScrollPosition was being reported as -1, causing a line of code to look for an array element at index -1. This array element was in turn undefined, so the error message suddenly makes perfect sense.

The real puzzler here is that verticalScrollPosition could ever be less than zero. This is the logical equivalent of scrolling to the top of the list, then scrolling up one more spot, which is of course impossible. In any case, I have decided to assume that -1 is invalid at all times, and that -1 really means 0. I hope that is a safe assumption!

So, the solution is simple. In my case I had already subclassed the Tree control. If you're using the stock control from the framework, you'll need to subclass it and simply add the following:

All it does is intercept any request for verticalScrollPosition and guarantee that it is greater than or equal to zero. In brief testing, the error has disappeared and I have seen no side effects.

Like anything else on this blog, use this fix at your own risk, since I can't guarantee it won't have any negative impact.

Happy coding!

I recently took on the task of a major refactor of an AIR project. The application had grown into a monolithic beast with lots of conceptually related but logically disparate functionality. Management of the code was becoming a challenge. Packages were poorly structured. It was a mess.

The real catalyst for change, though, was the compile time. It had gradually crept up from a few seconds to 30+ seconds. In an effort to return to acceptable levels, I broke out chunks of UI into modules within the main project. I pulled graphics and sounds assets into a separate library SWC. But there was no appreciable effect.

The plan of attack was to break out at least two sections of the application, which are essentially mini-applications on their own. They share only a few common aspects of the main application, such as a common model and server connection manager, and are otherwise self-sufficient. Luckily, the project is built on Cairngorm principles, meaning that these items are already more or less detached from the view components.

What follows is a set of principles for successfully breaking down a large Flex application into separate, manageable module-based projects. These techniques seemed to have worked for me, although of course it is still a work in progress and there is much optimizing left to do. Really, this post is probably more for me as a future reference than anything else, but if it can help someone else, that would be terrific. Your mileage may vary, and if it does, leave me a comment to let me know what you've done differently!

[More]

If you're looking for a solution to the Flex 4.0 compiler warning "The style 'dropShadowVisible' is only supported by type 'mx.controls.List' with the theme(s) 'spark'.", here it is (see the comment from Carlos Bonilla): http://bugs.adobe.com/jira/browse/SDK-25720

The fix is a one-liner, and just requires going into the SDK and commenting out a line in a CSS file.

I ran into this issue months ago with a Flex 4.0 project and applied a workaround, which basically consisted of ignoring all CSS-related warnings in the Flash Builder compiler. This didn't feel quite right, but I didn't have time to keep screwing with it.

Fast-forward to last week, and a separate project, and here it was again. I like to have a clean "Problems" view when I'm working in a project, so I found this menacing. I needed a proper fix once and for all.

The solution is posted in the Adobe Forums for the world to see, but it took me a while to find it. The only reason for this post is the hope I can spare some poor soul out there the frustration of tracking it down.

Happy Coding!

As I wandered around an electronics store the other day on my lunch break, I was reminded of a disturbing price-gouging scam that seems to be so widely accepted that it has become status quo. I'm talking about cables; specifically, digital A/V cables like HDMI, DVI, optical TOSLINK, etc.

Big-box stores are expoliting confusion about the differences between analog and digital signals, and the effect that small changes in the signal quality might have on the picture you see on your TV or the sound from your audio receiver. See, in the dark ages (up until a few years ago), A/V signals were commonly transmitted in an analog format, which turns out to be remarkably inefficient in comparison to digital. Another downfall of analog signals, more pertinent to this discussion, is that they are susceptible to a number of adverse distorting effects caused by loss of signal strength.

You've seen the effects that moderate to severe interference or attenuation can have on an analog TV signal - snowy, ghost-like or rolling images, rendering your favorite shows unwatchable. You've also seen the effects of minor signal interference, which can typically be ignored but are annoying nonetheless. Cable manufacturers have a rich history of fighting against common causes for analog signal weakening. Many household devices produce some level of electromagnetic interference, so manufacturers introduced magnetic shielding. These higher-end cables made a real, perceivable difference in picture clarity.

The time of battling the shortcomings of analog signals has passed. Today, digital video and audio devices are the standard, Digital signals are based on a simple protocol that consists of 1s and 0s. There is very little room in a digital signal for errors. Either the picture appears on your TV, or it doesn't.

Expensive brands like Monster Cable want you to believe there is a difference in the signal carried by their product. This just isn't true. So please, if you're looking for an HDMI cable to hook up your new 52-inch plasma, don't spend more than $10.

I use monoprice.com (unsolicited plug!) They carry quality products and their prices are second to none. Try them or another online retailer, and save 80% of your hard-earned money.