discussed in Section 9.2.3 how the garbage collector cleans up objects
running out of scope, for example, a Player stored in a local variable
inside a method is freed automatically. However, using this approach
does not give you any guarantees on when this will happen (since the
collector's behavior is non-deterministic); this is a good enough reason
for calling Player.close() whenever it's needed.
We also talked about how explicitly trying to help the garbage collector
usually does not work. Correctly scoping your variables and setting them
to NULL when needed should ensure your application works smoothly
without running out of memory. Calling System.gc() explicitly, in
general, has no beneficial effect and can hurt performance if done too
often. However, when dealing with the Mobile Media API, sometimes
you will have many players active, consuming a lot of memory, and
want to dispose of them quickly, to load a new batch of players with
different sounds or videos. In most cases, just calling Player.close()
is sufficient, but in some extreme situations (15-20 players) you may want
to investigate calling System.gc() right after closing your players. This
makes absolutely sure your application has enough memory to load more
media as needed.
9.3 Streamlining the Deployment and Execution Lifecycle
We now look into best practices in the deployment cycle and the
execution of the application as a whole.
9.3.1 Bundle Lightweight Libraries
At the time of writing this topic, MIDP 3.0 LIBlets are not a supported
standard and Java ME only allows us one JAR file per application.
This is unfortunate, because some libraries not included in the Java ME
implementation could potentially be shared between several MIDlets.
Mechanisms for provisioning and managing dependencies are typically
overly complex for such limited hardware. Hence, Java ME shared
libraries are defined in JSRs and bundled with the JavaME implementation.
As a result we often need to include an external library with our MIDlet.
Our advice is to keep in mind that libraries not specifically written for
Java ME may cause performance and footprint problems. For example, we
could take an existing regular expressions library that was not originally
designed for embedded devices, but we would be much better off taking
a lightweight library that was designed with constrained devices in mind.
9.3.2 Use Remote Portals
As powerful as mobile phones are becoming, there is often the case for
removing some MIDlet functionality to a server. With the advancement