Thursday, September 24, 2009

Multi-threading options in Rich Internet Applications

A non-responsive user interface due to heavy computational work can lead to very poor user experience. In order to avoid freezing user interface, use of multi-threading is a must in any complex Rich Internet Application. Here are some pointers on multi-threading options in existing technologies and those that will come in the (near) future:

Silverlight

Silverlight provides a wide range of threading features and it's all done in a familiar .NET way. MSDN documentation about threading in Silverlight is extensive and you can read it here, and there are lots of examples out there about using threads in Silverlight application. You can use Thread, ThreadPool, BackgroundWorker, Timers, Monitors, Wait Handles, and more . Sure, lots of options here.

JavaFX

To my surprise, I've found that JavaFX script as of version 1.2 (released June 2009) is single-threaded, and all background work must be done in Java code as stated here by key members of JavaFx team at Sun Microsystems. More in their blog post:

There is one major caveat that I need to make clear. As of JavaFX 1.2, JavaFX Script is single threaded. All background work must be done in Java code. The JavaTaskBase abstract class is the base class intended to be used by all background threading implementations in JavaFX 1.2. Unfortunately, the hookup between JavaTaskBase and RunnableFuture didn’t come out right in 1.2 and you’re left with very little guidance as to how to do this appropriately.

The key thing is to understand that nothing should touch JavaFX variables from a background thread. So the idiom to use is to have the JavaTaskBase subclass to have a Java language peer which does the background work. The JavaTaskBase subclass would register a listener on the peer, and the peer would communicate back to the JavaTaskBase through that listener interface. The JavaTaskBase subclass would then pump events from the peer back onto the JavaFX thread (i.e. event thread) using FX.deferAction.
More information about background tasks in JavaFX using Java code is available here.

Flash

There isn't much you can do in Flash, since Flash is single-threaded application.
Alternatives include voting for missing threading feature here (if you are a part of Adobe community), or you can use Pixel Bender for calculating purposes, which is not a part of Flash and is programmed using GLSL syntax. There are more Flash alternatives for threading here, but that just doesn't look viable to me (and surely not just me!).

Html 5 and JavaScript

Html and JavaScript are not categorized as RIA technologies, but that could be changed in the near future. There are some sources here that mention things like multi-threaded JavaScript in Html 5. Draft recommendation for "Web Workers" is here and it's strongly influenced by a work of Google Gears. So we will have to wait until Html 5 is implemented in all major browsers. In the meantime you can try some nasty tricks for "simulating" multi-threading in JavaScript by James Edwards here.

Conclusion

Microsoft Silverlight provides great multi-threading features in today's RIA with lots of options.
Multi-threading in JavaFx 1.2 (released in June 2009) has changed so that JavaFx Script is single-threaded and therefore all threading operations are handled by Java code since JavaFx is fully integrated with Java Runtime Environment (JRE). Some multi-threading improvements (a hookup between JavaTaskBase and FutureRunnable) are coming in next JavaFx releases.
Communicating using only primitive types with Pixel Bender (which is not a part of Flash) doing background work written in GLSL syntax represents a very poor multi-threading choice. Moreover, missing multi-threading feature unfortunately doesn't have highest priority in Flash community.
Web Worker as a part of Html 5 which is currently in draft recommendation form have a long way to go. A lot of existing Ajax and Flash application could also take advantage of Html 5 Web Worker once it comes out, so it is also an option to watch for.

Monday, September 14, 2009

Silverlight SaveFileDialog doesn't work in Opera

Generally, most Silverlight 3 applications work ok in Opera. There were some problems with windowless mode in Opera using Silverlight 2, but it appears that it's been fixed in Silverlight 3.
Nevertheless, Opera is still not on the list of Microsoft Silverlight 3 officially supported browsers, and today I've found one more reason why. There isn't much documentation about this stuff, but I've got an exception when Silverlight 3 SaveFileDialog is used in Opera 10 (build 1750). The thrown exception is:
"Dialogs must be user-initiated at System.Windows.Controls.SaveFileDialog.ShowDialog()..."
which appears in other browsers, too, but only if you try to invoke save file dialog avoiding button click event. I haven't found any workaround for this, so my code looks like this. I would like to know if there is a better way to solve this problem in order to use Silverlight applications in Opera. Any thoughts?