February 3, 2009 3:32 PM
sandboxviolation has garnered more than 711 unique visits since its
launch. Porting it to AIR took only two hours! Hearing about how AIR
lets you take your web app to the desktop is one thing. Actually
seeing it happen in a span of two hours is freaking awesome. A change
of the root tag to WindowedApplication, add a bit of custom chrome, a
pinch of offline support by hooking in another listener to your remote
object and modifying your Cairngorm delegates, throw in auto update
and finally, make the window startup with a size that is suited for
the desktop by looking at mainScreen.visibleBounds.
Okay, I already had the auto update part as a component (based on Rich Tretola's work) written beforehand, had played lots with custom chrome before, knew how the mx.rpc and SuperImage components work and knew about Badger. So I knew what I had to look at each stage. But even then, its super awesome to see your application, the code that you labored over and dedicated a part of yourself into take life as a desktop application and work offline beautifully in such a short time frame.
Download / install / get more details about sandboxviolation desktop.
The Devil is in the Details
So, how exactly was this done? I'll explain more about the offline capabilities because the others details mentioned are not as interesting and have been documented elsewhere. This is one case where Cairngorm proved its usefulness yet again.
AIR's URLMonitor class can be used to determine whether you are online or offline. It checks only the first you call start and when it detects changes in the network status. Every time this check is done, I update a boolean in my model.
Initially, I added a default responder to the only single RemoteObject in my application that persists the result object to the filesystem via FileStream's writeObject() call. The key was the operation name. This was a blind approach and had serious overhead for calls I didn't want cached.
To narrow down things, I added the "persisting object to the file" logic to the respective Commands that had to work offline. The delegates were modified to call the RemoteObject when online and call the file store to read the result when offline. With this change I had decent offline capability. Any data viewed when online would be available offline.
Things were rosy till I noticed the avatars were not showing up. I'm using the gravatar service to pull up an avatar based on the email address of the user. So I added support to Ely's SuperImage for persisting the contentLoaderInfo.bytes to a file. With that done, the avatars also worked beautifully.
Voila! Offline support. Wait, but what happens when you are writing a question or answer and the app goes offline? Simple. the data in the post question / answer view is persisted to the file system. When the app is online and the user visits the same view, the data is restored.
As you can imagine, all this writing and reading to the filesystem is quite expensive. So the reads are cached and the write is once only while the app is alive for images.
sandboxviolation desktop can be considered as proof of the promise that Adobe AIR easily lets you take a Flex app to the desktop with offline support. There is an icon now in the web version which leads you to the installation page of the AIR version. So install sandboxviolation desktop and post the gems among your flex / flash questions there so that it becomes an invaluable resource to the community that can be used offline as well (and also puts you on the beginning of the users list based on the amount of up votes your content gets).