- Once you have finalized your applet code,
the final stage in the development process will be to determine
how to make your program available to browsers on the web.
- In the last section, we showed an example
of this when we created a class file, referenced it with our HTML,
and sat back while web surfers played with our applet.
- This approach is
realistic for "example" applets and silly little ticker tape
programs typical of current Java development, but it may be
unrealistic for real-world applications.
- Rather than simply placing raw class files
on the web for download, it is likely that as your applets grow in
size, you may want to utilize some of the distribution technologies
now available to Java developers. Though, placing your raw class
files on the web will work, it is not necessarily the most efficient
way to distribute your applet.
- As you will know if you have spent any time
web surfing or playing with Java applet demos, the Internet's biggest bottleneck is the speed of the slowest link in a connection. Although the so-called back bones of the Internet might exchange data at massive rates, most people web browsing, do so with a modem. That's very slow.
In fact, it is so slow that it is very possible that if your applet
takes too long to download, potential clients will simply surf-on
and ignore your dour looking gray square box page. You will never
even get to show off all your hard work.
- Perhaps we should take a moment to get some
perspective on this problem. How slow is slow?
- Let's assume that the average viewer of
your page will be using a 14.4 modem. Though this may not be the
typical modem speed used by the average web programmer, it is
actually a fairly realistic assumption about the average web surfer
and probably will be for at least a couple more years. With their
14.4 modems, your viewers can expect it to take 1 second per
kilobyte to transfer. This means that 60k worth of class files would
take a minute to download. What's worse, you must also factor in the
time it takes for their web browser to start the virtual machine and
instantiate your applet. Most people have enough patience for about
5 seconds. You get the picture.
- Traditionally, Java has addressed the speed
bottleneck by attempting to be an amazingly small language. Further,
developments in the JDK have been slowly incorporated into the main
web browsers so that the majority of the class files your applets
will need will already be resident on the client's machine.
- However, until recently, there were no
great ways to address the size of your own code, or the class
libraries that you use. Fortunately, recent developments in
archiving and compression technologies have given developers
excellent ways to make their large applet code much more
modem-friendly.
- But wait! Is it necessarily better to use
one of these flashy, new distribution technologies if you have a
large application? Well, unfortunately, there are no easy answers
because it depends on the specifics of your situation. Consider the
following scenarios:
The Deadweight Scenario
- Suppose you have a large application with
dozens of class files. However, because of the average work flow of
your application, it is unlikely that the user will need all of the
functionality in any one usage. Thus, many of the classes that are
part of the application will be deadweight in any given
execution.
- So, given that situation, if you archive
the application and force the user to download the entire bundle at
once, you may be forcing them to download more class files than they
need to. Even considering the fact that you may have compressed
those class files, the deadweight of the extraneous classes could
counter the benefits of compression or even end up making the final
download time longer than it needs to be.
- In this case, archiving or even archiving
with compression may not be your best option.
Thin Button and Progress Bar Scenario
- Suppose again that you have a large applet
and your users are webbing away from your page before they get a
chance to see the applet because it takes so long to download. You
think to yourself that an ideal resolution would be to place a very
lightweight push button that the user could press to begin the
application. When a user presses the button, you continue to
imagine, a progress bar could popup and let the user know that the
applet is loading by filling up proportionally to the number of
class files downloaded.
- Thinking that is a good solution you add
something like the following to your code:
try {
Class C = Class.forName("myClass1");
thinButton.setLabel("Loading...20%");
thinButton.repaint();
C = Class.forName("myClass2");
thinButton.setLabel("Loading...40%");
thinButton.repaint();
C = Class.forName("myClass3");
thinButton.setLabel("Loading...60%");
thinButton.repaint();
C = Class.forName("myClass4");
thinButton.setLabel("Loading...80%");
thinButton.repaint();
}
catch (ClassNotFoundException e)
{
System.out.println("Class not found exception");
}
- The lightweight button would solve the
problem of the applet taking too long to download and the progress
bar would be a psychological crutch which would help the user
through the download time. But again, this would be impossible if
you downloaded the entire application as an archive because by the
time the light weight button was instantiated, the entire class
library would have been downloaded.
Web Server Twiddling Its Thumbs Scenario
- One of the "official" benefits of archiving
is that a web browser need only make one HTTP request from a web
server in order to download an applet. This saves the web browser
from having to open separate HTTP connections for each class file,
image and data file in your program.
- Thus, if you have two dozen files in your
applet, you would reduce the number of necessary HTTP connections by
11. Wow, 11 times faster!
- Well, not exactly. In actuality, the time
it takes to make an HTTP connections is minimal. In fact, the more
connections you open the better it is for you. After all, if the web
browser multi-tasks by downloading class files in tandem, it can
download the class files even faster.
- So why archive (besides compression if it
is available)?
- The "real" danger of multiple connections
is that if everyone multi-tasks, we may end up with some pretty
nasty traffic jams on the I-way.
- Further, the more HTTP requests that you
hit a web server with, the busier it becomes. If two people download
a 12-file applet that is archived, the web server must juggle two
requests. If, on the other hand, the web server has to distribute
the 12-file un-archived applet, it has to juggle 24 requests. As you
can imagine, this could bog down a web server pretty quickly.
- So the official word is that you should
always archive. In a sense, archiving is more a courtesy than a
performance boost. By archiving you are doing your little part to
reduce the total traffic on the net. And in exchange you agree to
accept some slowdown in your own work.
- Well, as it so happens, and as you might
expect, very few people are courteous on the net. In fact, in terms
of the number of HTTP connections, Netscape and Internet Explorer
have had well-publicized speed wars throughout the last few years in
which they ruthlessly opened up connection after connection in order
to boast their marketing superiority over the other. "We're
faster!" "No, we're faster!" Faster at what cost?
- And as for the benefits of slamming servers
with multiple HTTP requests, because of web server time slicing,
applets that demand 12 HTTP requests get a higher priority over
those that demand only one connection.
- So what is a web designer to do?
- From a selfish perspective, it is better to
multi-task. The designer must ask, "why should I be courteous and in
the process, be less competitive"?
- Courtesy and morality are up to you,
however we would suggest that you at least consider the load on the
web server you are using. If your web server is relatively unused,
feel more free to demand more of its attention. However, if your
applet is hosted on a public ISP, try to keep the other users on the
system in mind. Also, carefully balance the time savings that you
gain from multi-tasking. Clearly, the time saved for multi-tasking a
3-file applet does not necessarily justify the network traffic and
server load you cause.
The Final Word
- As you can see, deciding how to distribute
your applet can be a challenging design decision in itself. However,
regardless of what you choose in any given case, it will be
necessary for you to have at your disposal an array of tools for
distribution. This chapter will discuss the process of distribution
to give you a more detailed look at the available technologies to
make distributing your applet faster and more efficient.
Previous Page |
Next Page
|
