Java Reference
In-Depth Information
instance, and send the message using the
MessageConnection
and configured
TextMessage
instance. Once the
run
method sends the message, it cleans up by closing the
MessageConnection
before exiting.
Note that this example keeps error handling to a minimum; the
try
-
catch
blocks show
you where errors can occur (for example, a lack of wireless coverage would cause the invo-
cation of
send
to throw), but the code doesn't do anything with these errors. When crafting
applications that use the wireless network for data exchange, it's important to pay special
attention to how your application handles errors, because they can occur frequently (espe-
cially considering the vagaries of wireless coverage). How you handle errors when sending
and receiving wireless messages in your application depends to some extent on the nature
of your application, but generally falls into one of these three broad categories:
•
Ignore errors entirely
: Simple applications—especially those that rely on a sophisti-
cated back-end server—can often simply rely on the back end to resend messages
and manage errors. Applications that send many repetitive messages, such as
those reporting user position or other status, can often ignore transmission fail-
ures, because a subsequent message will be sent soon after the failure anyway.
•
Notify the user and let the user deal with the error
: This approach is appropriate for
simple applications but can quickly frustrate users, especially if the application
loses content you enter when the error occurs. It's far better to fail silently and
notify the user of an abnormal condition passively (such as through a signal status
icon) than it is to create a modal interface that forces the user to respond to various
errors as they occur.
•
Queue messages for later delivery
: Applications requiring reliable message delivery
should provide their own message queue, likely as records in a record store. This
can gracefully handle most errors that can occur without user data loss.
Sending and Receiving MMS Messages
The exchange of MMS messages via the WMA is similar in principle to the exchange of SMS
messages, although two wrinkles arise. First, as you saw in the “Managing the Multiple
Parts of a MultipartMessage” section, sending or receiving an MMS message requires that
you work with not only the message, but also the content that makes up the message.
Second, the MMS protocol itself is a much more expensive protocol than the SMS protocol;
sending or receiving an MMS message can take far longer than sending or receiving an SMS
message, because MMS messages are larger and use the network's data channels more
heavily than SMS does. This means that when using MMS, your application
must
use mul-
tiple threads to avoid stalling the user-interface thread. Moreover, your application should
be prepared to receive more than one message at once, because heavily used applications
may well be receiving a single MMS when another MMS message arrives.
