Miscellanea

There’s a difference between the URL your Flex application’s SWF file was loaded from and the URL your Flex application’s SWF file is actually running from.

The former is easy to retrieve via the read-only property Application.application.url.

The latter is (slightly) more complicated. Although Flex does not provide the built-in ability to determine the URL your Flex application is running from, our good friend JavaScript is happy to lend a helping hand.

Using ExternalInterface, you can call “window.location.href.toString” to retrieve the URL your Flex application is running from.

Although there are many different permutations to retrieve this URL using window.location, I prefer the above method because it also returns any query parameters passed into the URL.

I created a static class called JSUtil so I could quickly access this method in my code, the source of which you can view here.

Adobe has a great article over at the Flex Developer Center on how to add drag-and-drop support to your Flex application:

http://www.adobe.com/devnet/flex/quickstart/adding_drag_and_drop/

This article provides a great foundation for developers who want to learn how drag-and-drop works inside Flex.

However all their examples use what’s called a “drag proxy” for their drag operations, which is pretty weak if you want a true drag-and-drop look-and-feel in your application.

The problem with using a drag proxy is that the object being dragged looks like it’s being copied instead of dragged. The original object is only moved after the drag operation is complete.

That may be good enough for some applications, but when you want your objects to look like they’re being moved in real-time, this “copy effect” just doesn’t cut it.

So let’s take a look at what goes into a drag operation.

The first parameter in the DragManager.doDrag() method is the dragInitiator. This is the component that started the drag operation.

As it turns out, the dragInitiator is all you need to improve the look-and-feel of your drag operations.

If you pass the dragInitiator in as the dragImage for your drag operation, the DragManager will drag the component directly!

How’s that for simple?

Anyone who’s designed a Flex application built on LiveCycle Data Services knows the love-hate relationship that comes with it.

But regardless of the effort, no one can deny that managed collections kick some serious ass. With paging enabled, you can access datasets with hundreds of thousands of items one page-at-a-time, thereby reducing server load and avoiding a UI-rendering black hole.

However, this comes at a price. You no longer have immediate access to all of the data in your collection, although it certainly seems like you do. Iterate through the collection once, and you’ve ruined all the benefits paging was designed to offer you.

LDS Tip #1: NEVER iterate through a managed collection!

How does this affect sorts and filters applied to your collection? The Flex implementations of ICollectionView retrieve all the items from a destination before executing a sort or filter.

That’s the rub. Apply a sort or filter to your collection, and paging is out the door. Which kind of defeats the purpose of using LCDS to begin with.

Or does it?

You could of course include the sort or filter criteria in the signature for your destination, but even that’s an unnecessary step. If you simply apply a sort or filter BEFORE you perform the fill, LCDS will know what you’re trying to do and will happily return paged data that is sorted and/or filtered.

How’s that for awesome?

So long as you don’t need to change the sort or filter criteria after the fill, you’re in the clear. And if you do have a variable sort or filter you can, like I mentioned above, simply release your collection, re-apply the sort or filter, and then perform the fill again.

I knew I loved LCDS.

One of my biggest pet-peeves in Flex is the apparent lack of tweening support for device fonts.

Let’s say you have a container with a couple of text components, and the text components are all using device fonts. If you try to apply a Fade effect, for example, to animate the alpha property of the container from opaque to transparent, the text will not animate.

This leaves you with a couple of text components that appear to have broken free from the confines of their container. This is anarchy.

So how do we apply tweening effects to text components using device fonts? Apply filters to them.

Let’s return to the example above. If you apply a filter to each of the text components (such as a BlurFilter) before you apply the Fade effect, the device fonts will animate beautifully with the rest of the container.

myLabel.filters = [new BlurFilter ()];

Once your effect is complete, you can remove the filter (if necessary).

myLabel.filters = [];

It’s that easy.

Let’s be honest: localizing the UI text in an application is pretty easy.

Add all the strings you plan to display to a properties file or a value object and simply reference them in your UI components.

But what about the components that have information known only at runtime, such as a username or the current date? How should they be handled?

There are two ways. The first way is stupid and complicated. The second is completely awesome. Let’s start with the stupid way:

1) Create strings for each static segment of a dynamic piece of text

For example, if you wanted to display a simple greeting in your application, such as “Hi [some user] ! Welcome to [some application] !” it would look like this:

public var greeting1 : String = "Hi ";
public var greeting2 : String = "! Welcome to ";
public var greeting3 : String = "!";
<mx:Label text="{greeting1 + username + greeting2 + appName + greeting3}" />

Gross, isn’t it?

This brings us to the better (and totally awesome) way:

2) Use regular expressions to replace dynamic information at runtime

Let’s look at the same example using regular expressions:

public static const USERNAME_PATTERN : RegExp = /USERNAME/;
public static const APP_NAME_PATTERN : RegExp = /APP_NAME/;
public var greeting : String = "Hi USERNAME! Welcome to APP_NAME!";
<mx:Label text="{greeting.replace (APP_NAME_PATTERN, appName).replace (USERNAME_PATTERN, username)}" />

Isn’t that beautiful?

Although using regular expressions involves creating a RegExp pattern for each piece of dynamic information, the benefit is that the locale data can be changed without having to recompile the application.

For example, say you wanted to change the simple greeting to something like: “Welcome to [some application], [some user] !”.

Using text segments, you would not only have to change the locale data, you would have to reorder the variables in the Label component and recompile the application.

Using regular expressions, you would simply need to change the locale data. Depending on your setup, you might not even need to reload your application!

Regular Expressions + Locale Data = Happy Applications