Following up my post last week on creating channel definitions, I realize I forgot to add one key piece of code - timeouts!

Why are these important?

For starters, the connection timeout prevents you from waiting until the end of time to get a response from the remote destination. Since you typically connect when your application first loads, this can result in an unnaturally long startup time when the remote destination is slow or unavailable.

Not having a connection timeout also causes failover (e.g. from RTMP to polling) to take a really long time.

Similarly, the request timeout helps prevent your application from appearing unresponsive. Better to handle slow asychronous calls with progress indicators rather than simply hope they’ll return in a reasonable amount of time.

So without further ado, here are the lines to add to your channel definitions for connection and request timeouts:

The actual values are arbitrary, so you should adjust them as needed.

Original post: Creating FDS Channel Definitions in AS3

Anyone familiar with Flex Data Services knows about services-config.xml.

This file usually contains security constraint definitions, channel definitions, and logging settings that each of the services can use. (more here)

It’s one of those config files that always feels more complicated than it needs to be, and to top it off, it’s a compile-time resource. This limits its flexibility, especially when it comes to channel definitions.

Why should you have to recompile your application whenever your channel definitions change? Let’s declare them in AS3 instead!

Here’s an example of two channel definitions from a services-config.xml file:

Now let’s look at the same two channel definitions in AS3:

At first glance this code doesn’t appear to offer any advantage over the channels defined in services-config.xml. However in the AS3 code, the server name for the channels is passed in as a flashVar to the application.

This allows your application to determine at runtime which channels to use, and it also eliminates the need to compile the XML file into your application.

Two wins in my book.

Addendum: Adding Channel Definition Timeouts

LiveCycle Data Services. I’ve mentioned it before.

It can be an indispensable tool. But like any good black box, getting it to work properly is a huge pain in the ass.

One of the biggest benefits of LCDS is paging. Paging lets you dynamically load data as soon as it’s accessed within a collection. This is great for large data sets, and the beauty of this approach is that you don’t have to do anything special for it to work.

Create a collection, bind it to your view, and connect it to a data service. As you interact with the view, LCDS will automatically retrieve the data in the background.

Beautiful, right?

But let’s say you want to use a custom component instead of a standard List or DataGrid to display your data. This is where the magic breaks down.

You see, LCSD only works “as advertised” when you use built-in components. Any Flex component that can accept an ICollectionView as a dataProvider has specific logic to handling paging.

This is because paging is just a series of asynchronous remoting calls performed behind the scenes. When a component tries to access data that isn’t available, an ItemPendingError is thrown and a remoting call is made to retrieve it.

Since there’s nothing to access right away, the component will substitute a placeholder in lieu of the actual data. When the remoting call returns, the component will then swap out the placeholder for the data.

This is all fine and good, even though it does reveal somewhat how the sausage is being made. You just don’t get any of this for free if you use your own custom component.

However this doesn’t mean it’s impossible. You just have to support the asynchronous method in which the data is accessed - something I’ll detail in a future post.

(cliffhanger)

Caching images in your Flex application can greatly improve performance and reduce the overhead of loading external resources.

And I’m not simply talking about using the cacheAsBitmap property to improve rendering performance or the cachePolicy property to speed up animations. I’m talking about caching the actual bitmap data of an image.

To get started, you’ll need a hash map to store the image data. A Dictionary or an associative array will also work just fine.

Loading an image for the first time is the same as usual. You create a new Image object and add a listener for the COMPLETE event:

Once the image has finished loading, you add a copy of the bitmap data to the hash map using the image URL as the hash key:

Now we can use the image as many times as we want without ever having to load it again!

To take advantage of this, you’ll need to check the hash map every time you create a new image (or change the source property) to see if you’ve already cached it:

And that’s it!

If you have an application that loads a large number of images you may want to limit the number of cached images to prevent the Flash player memory usage from getting out of hand, but in general caching even several dozen large images only results in a slightly increased footprint.

A simple way to track memory usage in your Flex application is to create a Label that displays the System.totalMemory property and updates it on render events.

This isn’t anything fancy, but it’s useful when checking for memory leaks and helps you avoid making mistakes when dealing with memory intensive applications.

Also, its just kind of cool.

You can even go a step further and create a button that allows you to manually perform garbage collection. This, coupled with the memory monitor, gives you the basic workings of a Flash Player memory management tool.

Just remember that System.totalMemory reports the total memory in use across ALL instances of Flash Player and not just the current one - so if you have other Flash or Flex applications open your usage patterns will be skewed!

Here’s some sample code for the label and button: