Flex 3 deep linking is a dangerous source of race conditions
Flex 3 adds support for deep linking, which allows the browser URL to reflect the state of your application, and lets users link to specific application states. In Buzzword, this means that users will be able to use the URL in the browser’s address bar to link to a specific document, as well as use the Back and Forward button to navigate among documents and the document organizer once those states are in the browser history.
Linking to a specific document is a bit trickier in a Flex application than in a pure HTML app, because typically in a Flex application, there is only ever one “page,” the first page that comes back from the server. Everything after that happens inside Flash. So if the user switches from one mode to another, a Jedi mind trick browser trick has to be used to make the browser’s URL change without making the browser request another page from the server. That trick involves changing the URL fragment, which can be done via JavaScript, and which doesn’t trigger an HTTP request. Flex 3 wraps all of this trickery inside a framework class called BrowserManager, and some additional JavaScript, CSS, and html files that need to be included by the application’s main wrapper page.
Integrating the BrowserManager into an application is really easy. I got it working in about 15 minutes. But I’m spending significantly more time chasing down race conditions that are introduced by the fact that the user can press the Back and Forward button repeatedly while the application is in the middle of something else. For example, if the user initiates a save of a large document, presses the Back button while the save is taking place, and then presses the Forward button before the save is finished, the document editor might try to reload the same document before it is finished being saved. Not good.
Fortunately, Buzzword already uses a Command pattern to execute user actions, and our implementation already has a synchronization and queueing mechanism that correctly handles cases where a second command is initiated before a previous one has finished. So preventing these race conditions wasn’t as hard as it might have been.
Moral of the story: when you implement deep linking, watch out for asynchronous operations that might still be pending when the user uses the Back and Forward buttons.
Technorati Tags: Flex 3
I'm working on Noteflight, an online music writing application that lets you create, view, print and hear music notation with professional quality, right in your web browser. Work on a score from any computer on the Internet, share it with other users, and embed it in your own pages. Noteflight is free for individual use. Email me at dcoletta at noteflight dot com.
How do you deal with situations where the second command needs the first command to cancel before it can continue (i.e. cancel any currently running commands)? e.g. opening 2 documents straight after each other. Queuing won’t be good because if it takes 10 seconds to open the first document, the user interface will appear to “stick” until it’s loaded the first document, then it will load the second.
I guess I see this as not so much a problem with deep linking as a problem with how document state is represented when a save operation is underway. Regardless of whether commands are used, I’d think of having some global state in the app that knows that a document with a given URI is “busy” because a save operation is underway. Attempting to load such a document can result in the user seeing it immediately with the content that’s being saved, but the UI should reflect that “busy-ness” (by blocking further interaction, or whatever else you’d do while a doc is being saved). This doesn’t suffer from some of the issues with queuing commands, etc.
In any case, it’s good to raise consciousness on the danger of treating URL changes as if they had to invoke instant behavior regardless of any other operations underway in the app. In my deep-linking package UrlKit (which works with Flex 3′s BrowserManager), the browser location is coupled to an application model of that state via some declarative rules. This direct coupling can certainly get one in trouble in some cases if changes to that “location state” have asynchronous consequences. But I suggest that rather than decouple the browser from the location state, it’s better to decouple location state from other things inside the app. This is also far more testable (since a test can manipulate location state without actually having a browser as part of the action).