<http://www.javasaver.com/testjs/jws/cache/>
The theory is that the (<20KB) of classes of this
(sandboxed) application should spring onto screen
quickly, but once the user clicks a list entry, the
media files (ranging from 270-370Kb) will then be
downloaded and cached (and displayed).
Does it work that way for you?
Andrew T.
Yes.
--
Dag.
Thanks.
I also got another positive from ratnaprasad via gmail.
"Yes its working as you said.
I tested it.
The initial class loads very fast, upon clicking the images its taking
time to down load, once its cached everything is faster."
Thanks Ratna(? first name). Note that it is better to
share your results with the group - where we can all
benefit from the information.
I am looking to prepare another example that attempts to
reference the classes in code (other than by using reflection)
to see if I can retain that 'lazyness'.
Andrew T.
This example references the classes in 'lazy' resources
as local variables..
<http://www.javasaver.com/testjs/jws/cache2/>
Not only are all jars downloaded eagerly, but as soon as the
main classes load (the ones flagged as 'eager', and before
the GUI is on-screen) the JWS splash *disappears* and the
end-user is looking at about 20 seconds* of 'blank space'
before anything else appears on-screen!
* Whatever time it takes to download the media
jars which are marked as a lazy download.
...Ugggh!
Andrew T.
That first example simple blocked the GUI for
a long while as the lazy resources were loaded.
<http://www.javasaver.com/testjs/jws/cache/#eg3>
This one shows the webstart progress dialog* as
the lazy resources are downloading, but it's *blank*,
despite the fact I attached the DownloadServiceListener.
Has anybody successfully used the JNLP API's
DownloadService?
* See the page for a screenshot.
Andrew T.