Java Reference
In-Depth Information
public void destroyXlet( boolean b )
throws XletStateChangeException {
}
}
The process for obtaining a remote object is similar to that for registering a remote
object: obtain a reference to the
IxcRegistry
for the
XletContext
, and then invoke
lookup
to obtain the stub for the remoted object. The returned stub will be a proxy to the original
class, so you can cast it to the original class definition; you should be sure that both the
producing and consuming Xlets include the class definition for the remoted class.
When looking up a remote object, many of the same things can happen as when
registering one. In very rare circumstances, there may be no registry with which to
obtain a remote object, or the registry may fail to create the local stub for the remote
object. It's far more likely, however, that the remote object simply isn't registered,
because the producing Xlet isn't running. If that happens, the registry's
lookup
method
will throw a
NotBoundException
, and your Xlet will be free to proceed as it sees fit per its
business rules without the remote object.
Be prepared for your remote object disappearing while you're using it. When this
happens, accessing any of the object's methods throws a
RemoteException
. This can hap-
pen for a number of reasons, but the most likely reason is that the Xlet producing the
object has exited, and the original remoted object has been freed. For that reason, it's
generally best to access a remote object only when you need its services, and release it as
soon as you're done using it, rather than relying on the serving Xlet and object to persist
throughout the lifetime of the consuming Xlet.
Wrapping Up
The CDC has similar application execution constraints to the CLDC, including limited
memory and I/O options. To reflect this, the PBP atop the CDC defines the Xlet, which is
an executable interface not dissimilar to the MIDlet defined by the MIDP.
Like the MIDlet, an Xlet has a well-defined life cycle that consists of three states:
paused
,
active
, and
destroyed
. An Xlet begins its life after creation in the paused state,
moving to the active state when the application manager calls its
startXlet
method. Sim-
ilarly, the application manager can pause the Xlet at any time by invoking its
pauseXlet
method, and it can resume execution by forcing the Xlet to re-enter the active state by
invoking
startXlet
again. At any time, when the Xlet is in any state, the application man-
ager can terminate the Xlet's execution by invoking the
destroyXlet
method. Unlike a
MIDlet, however, the Xlet can refuse a state transition and generate an error by throwing
the
XletStateChangeException
.
