Implementing the Comm module

The Comm module (implemented in the com.nokia.example.bcexchanger.comm package) handles all Bluetooth and OBEX operations for the MIDlet. It consists of the following classes:

• ExchangeListener—This callback interface is implemented by the BCExchangerMIDlet. By means of the interface methods, the OBEX communication module signals to a listener about various networking events.

• ExchangerComm—This interface contains methods representing the functionality of the OBEX communication module to the other classes of the MIDlet. The OBEX communication module implemented by the Comm module classes realizes the exchange of the business card over the OBEX API. The control of the module is abstracted in this interface.

• ExchangerCommImpl—This class is the central class in the OBEX communication module. The BCExchangerMIDlet calls the methods of the ExchangerComm interface (implemented by the ExchangerCommImpl class) to control the process of sending and receiving business cards.

  The ExchangerCommImpl class is also a parent for the states of the communication state machine: it keeps the current state of the state machine and implements the ExchangerStateParent interface. Using the ExchangerStateParent interface, the state classes can access the required functionality of the parent.

  The ExchangerCommImpl class waits for an incoming Bluetooth connection in a separate thread and therefore implements the Runnable interface. The ExchangerCommImpl class also works as an OBEX server. To serve OBEX requests, it extends the ServerRequestHandler class and overrides some of its methods.

• ExchangerState—This class is an abstract base class for all the states of the communication state machine. Each state implements only those methods which can be executed in that particular state.

• ExchangerStateParent—This interface contains the function used by the state to address the functionality of the ExchangerCommImpl parent class . It includes the methods which the states of the communication state machine use to get certain functionality from the parent.

• IdleState—This class implements the idle state of the communication state machine. In the idle state, the machine waits for external events, such as incoming Bluetooth connections or a user command to start a card exchange. The IdleState class extends the ExchangerState abstract class.

• InquiryState—This class represents the state of the running inquiry. In this state, an active device discovery is performed and no OBEX server commands are handled. The InquiryState class extends the ExchangerState abstract class, and implements the DiscoveryListener interface to receive Bluetooth inquiry callbacks.

• ReceiveState—This class represents the state when a business card is received from the remote device. In this state, the client OBEX GET operation is performed, and no OBEX server commands are handled.

• SendState—This class represents the state when a business card is sent to the remote device. In this state, the client OBEX PUT operation is performed, and no OBEX server commands are handled. The SendState class extends the ExchangerState abstract class.

• ServiceDiscoveryState—This class represents the state of the running service discovery. In this state, an active service discovery is performed and no OBEX server commands are handled. The ServiceDiscoveryState class extends the ExchangerState abstract class and implements the DiscoveryListener interface to receive Bluetooth service discovery callbacks. The service discovery procedures are run from a separate thread, and therefore the class also implements the Runnable interface.

The following figure shows the state machine diagram of the Comm module. When the MIDlet initiates the exchange of cards, the normal state change flow is "idle > inquiry > service discovery > send > receive > idle". However, each state can be canceled or can end in an error, in which case the execution of the exchange process ends and the MIDlet returns to the idle state.

Figure: Comm module state diagram

Accepting a connection is implemented as serving OBEX GET and PUT requests, and therefore it is done without a state change. However, note that the state machine has to be in the idle state to serve the OBEX requests. In other words, the MIDlet is always ready to accept a card exchange from a remote device if it is not currently performing an active exchange itself.

To create the Comm module:

1. Implement the OBEX server connection

2. Implement the idle state

3. Implement the inquiry state

4. Implement the service discovery state

5. Implement the send and receive states

Now that you have implemented the Comm module, implement the Address Book module.