Implementation of btsppEcho MIDlet
The MIDlet can be started in either the client or server mode in the
initial SettingsList screen. The SettingsList screen
lets user choose the discoverable mode (server) or discovery mode (client)
used for device inquiry, and if the general or limited inquiry access codes
are used (that is, GIAC or LIAC). It also lets the user choose appropriate
security settings (that is, authentication, encryption, and authorization).
The SettingsList screen also has a “Bluetooth properties”
option to allow the user to examine the Bluetooth properties of the local
device.
When the MIDlet is started in client mode, the screen map transitions
from the initial SettingsList screen to a ClientForm.
The ClientForm uses a class called ConnectionServer to
accept and open incoming connections from the remote server. Once a connection
has been set up, the ClientForm allows the user to send messages to the server.
It also displays any messages received from the server.
When the MIDlet is started in server mode, the screen map changes from
the initial SettingsList screen to a ServiceDiscoveryList.
It is used to initiate a device inquiry, and subsequent service discovery
on any found devices that have a suitable COD. As matches (that is, found
devices with a suitable COD where the client is running) are discovered, these
are displayed to the user as elements of the List. The user can next choose
to open a connection from the server to a client. When the connection has
been created, the screen map changes to a ServerForm screen.
The ServerForm is used to display a text message
received from any client and to allow the user to send a simple text message
to all connected clients. It also displays how many clients are currently
connected, and allows a new connection to be added by a screen transition
back to the ServiceDiscoveryList. This is used to select
and open the next connection to some other as-yet-unconnected client.
Class Diagram
The following two diagrams illustrate the class diagram for the MIDlet design. The JAR file for the MIDlet contains all the classes needed for it to be run in either client or server mode. (If needed, the MIDlet could easily be split into two separate MIDlets for each role.) The MIDlet’s design is more clearly illustrated by showing the classes used in each of these modes separately.
Client
When the MIDlet first starts, it displays a SettingsListScreen that
is used to set important settings for the MIDlet, and to start it in either
server or client mode.
When the MIDlet is started in client mode, it next creates an instance
of a ConnectionService object and displays the ClientForm screen.
The ConnectionService runs continuously, waiting
to accept new connections on the appropriate server connection string. When
it accepts a new connection from a remote server, it notifies the ClientForm that
it has accepted a new connection and created a new ClientConnectionHandler to
handle that connection. A ClientConnectionHandler is
runnable, so it may read and write from the appropriate input and output streams.
The ClientForm starts the thread for each accepted ClientConnectionHandler.
This causes the latter to instantiate the actual InputStream and OutputStream objects
needed, and to start both a reader and a writer thread for them.
The ClientForm is a ClientConnectionHandlerListener,
and so accepts callbacks from its ClientConnectionHandler objects
related to opening the input and output streams, received messages, sent messages,
and normal or abnormal connection closes. The ClientForm directly
uses a ClientConnectionHandler to send messages.
Server
When the MIDlet is started in server mode, it next changes the screen
map to the ServiceDiscoveryList. From this screen, the
user may begin a “search” (device inquiry plus service searches). That phase
returns matching devices and services. The end user may then select to open
the first connection to a remote client, and the screen map is changed to
the ServerForm screen.
The ServerForm screen creates the actual connection
to a remote client, and maintains the list of all ServerConnectionHandler objects.
One is created per created connection. The ServerConnectionHandler objects
are runnable, and separate threads are used in each such object for reading
and writing to input and output streams. The ServerForm is
responsible for starting these threads when it creates a new ServerConnectionHandler object.
The ServerForm implements the interface ServerConnectionHandlerListener,
and so accepts callbacks from its ServerConnectionHandler objects.
The callbacks are related to opening the input and output streams, received
messages, sent messages, and normal or abnormal connection closes. The ServerForm directly
uses a ServerConnectionHandler to send messages.
The ServerForm also has an “Add connection” command,
which temporarily causes a screen transition back to the ServiceDiscoveryList screen
to select the next client to open a connection to.