Limitations of Applets

Why is Omniscope, although a Java application, not available as a Java applet?

Applets were first introduced several years ago to provide little animations inside web pages, before the days of Flash. They are not architected for large applications and pose several problems, some insurmountable.  (please scroll to the end for discussion of alternative deployment options).

Insurmountable problems

Memory

Memory requirement in Omniscope is the result of a complex equation depending on upon data complexity, view configuration and use case. Omniscope was built to leverage the higher memory capacity of relatively modern PCs to provide a rich data navigation experience.

Applets are limited to 128mb of memory which, as a very rough guideline, may be enough to navigate smaller files with limited views. The only true way to find the applet memory limit for a particular type of data is to experiment with data size in terms of records and fields. 

Life-cycle Issues

"Life-cycle" is the manner in which an application or applet is started, executes, and is stopped, then later restarted.  Applets have a fundamentally different life-cycle from applications.

With an application, whether Web Start or installed, each time you open it it gets a clean start. Multiple instances of the application run independently. When you close it, it stops completely.

Instead applets are started and stopped by the container.  The container is the combination of the web browser software and the Java plugin.  Applet stopping and starting is triggered by navigating to/from a page or refreshing a page. 

Unlike applications, applets don't get a clean start each time. Instead, stopping and restarting applets is done by the container using certain techniques which do not completely restart the application cleanly. These techniques are well documented as "inherently unsafe" and for larger applets result in unpredictable effects and instabilities.

The applet can get into a state which it will not recover from despite page refreshes, unless the browser is restarted. The only way to restart the browser is to close all browser windows before opening a new one which cannot be considered an acceptable solution.

Other significant problems

Size and progress display

Omniscope is very large by applet standards at roughly 10mb.  With some stripping-down work this could be reduced, perhaps to 7mb.  Regardless, it can take a minute or two to download on typical connections.  This would be acceptable if the user was reliably informed of progress during this period, but applets do not do this effectively.  The container typically shows a blank screen or box with no progress indication.  Most users would give up waiting.

Recent versions of Java added the ability to show applet progress and to cache previously viewed applets, except the implementation was buggy.  The progress went up to 100%, then carried on going with no predictable end, and the caching did not provide any improvement.  This is an ongoing problem and an indication of a lack of motivation from Sun (who make Java) to support applets.

Environment

There are a wide range of environmental variations that create a complex set of permutations which need to be tested for and handled when deploying an applet.  These are out of the applet developer's control and make providing a reliable applet extremely difficult:

• Browser: Internet Explorer (version 5, 6 or 7), Firefox (version 1, 1.5, 2), Opera, Safari...
• Java plugin: a plethora of versions from 1.4.2 to 1.6 (there are possibly 30 different versions in-between).
• Browser state: has the page been viewed before?  Is it cached?  Is the applet cached?

• The way the applet looks while it is loading.  Older versions of Java show a grey box; later versions show a Java icon; subsequent versions show a spinning logo.
• How the applet is stopped and started.  Internet Explorer and Firefox stop and restart the applet differently when the page is refreshed.  It is quite likely that a user would click refresh on seeing a blank screen for a long period.
• Internet Explorer now shows a "click to activate this control" for applets, but other browsers do not.

Java detection

Different browsers have different mechanisms for checking Java (and prompting for installation if necessary) with variable reliability.  There are several ways of doing this check, none of which reliable, requiring complex cross-browser javascript checks.  If Java is too old, on some browsers the applet just won't open, requiring a second applet just to check the version of Java.  While not unsurmountable, these add up to additional complexities delivering a reliable applet. 

Interface

Omniscope's user interface was designed for full-screen use.  While it will scale down to small window sizes, more room is generally better.  One of the philosophies behind Omniscope is to "show you the data"; an applet restricted to a panel within the web page may not have enough room to do this and will restrict ease of use.

Web page responsiveness and freezing

When a user first opens a web page containing an applet, the web browser will often freeze for several seconds while Java is started.  During this time the browser does not respond to interaction such as scrolling, clicking or navigating in other windows.  This can appear concerning. Also, users expect web pages to respond within a few seconds.  If a page takes more than 10, most will give up.  Opening an applet page will often take longer than this to become responsive and several minutes to complete.

Linked programs

With an applet, the web browser and the Omniscope program are inextricably linked.  If either has a problem, the other does too.

• If the browser crashes, Omniscope does too.  Internet Explorer and Firefox are known to crash occasionally.
• If Omniscope crashes, the browser may be unrecoverable.  A fatal problem in Omniscope (most likely a life-cycle, above, symptom) may cause the browser window to freeze.  Alternatively the browser may need to be restarted.

Either of these situations mean the user's session in both applications may be lost if there is a problem in the other.

Excessive security restrictions

To prevent rogue applets from causing damage, applets are unable to access files on a user's hard disk or communicate with other websites.  This prevents the user from saving their work.  It is excessive since the web browser allows users to save and upload files; logically the user should be able to authorise an applet to do the same.

Deployment Alternatives to Applets

Publishing to installed local clients

Our recommended approach to distributing data over the web is publishing .IOK files to any number of readers/users with local installations of Omniscope (Free Edition or Professional).   Those users with an activated Professional  licenses will also be able to add/export data and analysis, and re-publish/re-distribute an enhanced .IOK file

This method is similar to the PDF document publishing model, where the ubiquitous Acrobat Reader must be installed.  You can also compare this method to providing Excel XLS files for download.

'Zero-footprint' deployment with Web Start

A zero-footprint solution requires no software installation and no administrative capabilities to get started using the software.  Java 1.4.2 or later is still required, although most users already have this.  Deploying with Web Start is the preferred solution as it solves almost all of the problems above with applets. 

Web Start is a technology which has been built into Java for the last few years.  Instead of seeing an applet buried in a web page, the user clicks a link which launches the application in its own window, much like starting the application from the Start menu.

With Web Start, memory allocation is controlled by the publisher and there are no life-cycle problems.  Security restrictions are more intelligent, allowing the user to open and save files, for example.  The browser and Omniscope are isolated, so a problem in one won't affect the other.

In particular the user experience starting Omniscope deployed using Web Start is much improved over applets.  Accurate progress is shown when the program is downloaded, which only happens on first visit, and the application opens much faster.

There are still some environmental variations of concern.  With Java 1.3.1 onwards, Web Start was bundled and handled Java version checking automatically.  In theory, if the user has Java 1.3 they will be prompted for auto-installation of a more recent version of Java before Omniscope will open.  Unfortunately older versions of Web Start did not always handle this well, and many corporate systems administrators do not test for Web Start operation on deploying Java to their desktops - occasionally resulting in problems locating a suitable version of Java.

These minor problems make publishing to the installed application the preferred deployment/publishing method.  However it is quite possible to do both by providing a link for the .IOK download, a link to download the software, and an alternative link to start via Web Start.