You are currently browsing the monthly archive for May, 2008.
This library allows you to programmatically create TinyURLs in your Flex or Flash application. It contains exactly one class with exactly one static function:
TinyURL.create (url : String, callback : Function) : void
The premise is simple - pass in a URL, and get back a TinyURL in your callback method. Callback methods have the following signature:
function callback (tinyURL : String) : void
I toyed around with having the create() method return the TinyURL directly, but that didn’t work out very well given the fact it’s an asynchronous operation.
Still, I’m happy with how it turned out. I wrote this library mostly because I wanted to see if I could, and I thought it would be cool. And I did. (and it is) 
Click here to view the application demo (source included)
When I write Flex applications I often encapsulate the user interface in a single container so the main MXML file isn’t muddled with both startup logic and UI components.
This also has the benefit of reducing the layout complexity. Since there’s only a single container to worry about, it can always have 100% height and width.
With absolute positioning, the container is placed at (x=0, y=0). With vertical or horizontal positioning, the vertical and horizontal alignments are set to middle and center, respectively.
Either way you end up with a single container in the center of your application taking up 100% of the width and 100% of the height - no difference, right?
Not quite.
Check out the following two screenshots. The one on the left uses absolute positioning. The one on the right uses vertical positioning.
See the difference?
It turns out that vertical and horizontal positioning result in a rather sizable margin around your container. Setting the vertical and horizontal gaps to zero have no effect.
Absolute positioning results in the appearance you would expect - the container taking up the entire application space.
While it’s not hard to modify the vertical positioning code to produce the same result as absolute positioning, why bother?
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.
Update: Code snippets I’ve posted using Private Paste are randomly disappearing, so if the above link no longer exists, here’s a backup.
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.
LCDS 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. 
