Java Reference
In-Depth Information
Being clean applies to any type of stream, record stores, and record enumerations. Anything
that can be closed should be, preferably in a finally block.
Optimize the User Interface
It's important to remember that you are trying to optimize the perceived speed of your applica-
tion, not the actual speed of the application. Users get fidgety if the application freezes up for a
few seconds; adding some sort of progress indicator can go a long way toward making users
happier. There's really nothing you can do to make the network run faster, but if you display a
spinning clock or a moving progress bar, your application will at least look like it's still alive
while it's waiting for the network.
Keep in mind that users of mobile phones and other small “consumer” devices will be much
more demanding than typical desktop computer users. Through years of experience, bitter
desktop computer users have fairly low expectations of their applications. They realize that
most desktop applications have a learning curve and are frequently cantankerous. Consumer
devices, on the other hand, are much more likely to work right the first time, requiring neither
manuals nor advanced degrees to operate.
With this in mind, be sure that your MIDlet user interface is uncomplicated, fast, respon-
sive, intuitive, and informative.
Optimizing Application Deployment
One last area of optimization has to do with the actual deployment of your application. As you
may remember from Chapter 3, MIDlets are packaged in MIDlet suites, which are really just
fancy JAR files. One way to optimize your application is to partition your classes so that only the
ones you need are loaded into the runtime environment. If you are careful, you can reduce the
size of your MIDlet suite JAR by eliminating classes you don't need. Finally, a code obfuscator
may be used to further reduce the size of the MIDlet suite JAR.
Tip In general, you should be careful not to use an excessive number of classes in your application. Each
class you use has a fixed memory/storage overhead.
Partition Your Application
The MIDP runtime environment loads classes as they are needed. You can use this to your
advantage to optimize the runtime footprint of your application. For example, suppose you
write a datebook application that has the capability to send you reminder e-mails, or ticklers .
You would probably realize that many people will not take advantage of the tickler feature.
Why should tickler code take up space in a MIDP device if the user is not using ticklers? If you
partition your code correctly, all of the tickler functionality can be encapsulated in a single class.
If the rest of the application never calls the tickler code, the class will not be loaded, resulting
in a slimmer runtime footprint.
 
Search WWH ::




Custom Search