Home > Language Reference > Classes

StreamBluetooth Class

  + Object
    + Stream
      + StreamBluetooth

Description

The StreamBluetooth class encapsulates Bluetooth sockets, which allow data transfers between two devices over a Bluetooth link, using either the RfComm or the L2Cap protocol. This class is instanciable, but can neither be derived nor duplicated. For more information about streams, see also Data Streams.

Note that instantiating a StreamBluetooth object on a device that does not have a Bluetooth support causes a runtime error to occur. To prevent the default, unfriendly error message to be displayed, it is advised to instantiates this class from a function protected by an error handler, as described on the Bluetooth page.

The L2CAP protocol

This protocol doesn't support flow control. On the other hand, it allows multiple inbound connections. It is typically used for implementing network games, where multiple client devices have to connect to a single game server. To set up a L2Cap server, you'll do the following;

• Instantiate a StreamBluetooth class. You should not forget to properly set its Recipient property, as you'll have to catch and process events.
• Call its L2CapListen method, specifying the UUID that uniquely identifies your application.

Your socket is now listening, and ready to accept inbound connections. Each time a remote device tries to connect to your application, the following happens:

• A ConnectRequest event is raised. Responding to this event gives you an opportunity to reject the connection.
• If the connection is accepted, a ConnectedInbound event is raised, providing your application the socket that will be used to exchange data with the remote device.

If the local device is the master of a piconet, the socket remains in the listening state and can accept new inbound connections. Otherwise, the socket is placed in a hold state, rejecting any new connection until the current one is closed. For more information about managing piconet, refer to the Bluetooth class.

To establish a connection as a client to a remote L2Cap server, you'll do the following:

• Instantiate a StreamBluetooth class. You should not forget to properly set its Recipient property, as you'll have to catch and process events.
• Call its L2CapConnect method, specifying the UUID corresponding to one of the service the remote device advertises.
• Then you can exchange data on this socket using the Read and Write methods and the DataArrival event (see below).

The RfComm protocol

This protocol emulates a serial connection. On the other hand, it only allows peer-to-peer connections. It is typically used for reliable data exchange between two devices, such as a GPS and a computer. To set up a RfComm server, you'll do the following:

• Instantiate a StreamBluetooth class. You should not forget to properly set its Recipient property, as you'll have to catch and process events.
• Call its RfCommListen method, specifying the UUID that uniquely identifies your application.

Your socket is now listening, and ready to accept inbound connections. Each time a remote device tries to connect to your application, the following happens:

• A ConnectRequest event is raised. Responding to this event gives you an opportunity to reject the connection.
• If the connection is accepted, a ConnectedInbound event is raised, providing your application the socket that will be used to exchange data with the remote device.

After an inbound connection is established, the socket is always placed in a hold state, rejecting any new connection until the current one is closed. To establish a connection as a client to a remote RfComm server, you'll do the following:

• Instantiate a StreamBluetooth class. You should not forget to properly set its Recipient property, as you'll have to catch and process events.
• Call its RfCommConnect method, specifying the UUID corresponding to one of the service the remote device advertises.
• Then you can exchange data on this socket using the Read and Write methods and the DataArrival event (see below).

A typical application

Most applications behave both as client and server. They maintain two sockets: one for accepting inbound connections, and one for the data connection itself. The following example shows the skeleton of a typical Bluetooth application:

Private Const sUUID As String = "{00000000-0000-0000-0000-000000000000}" ' Insert your own UUID here

Private sServer As StreamBluetooth  ' The listening socket
Private sClient As StreamBluetooth  ' Socket to exchange data

Private Sub Form_Load()
  Set sServer=New StreamBluetooth ' Error handling omitted for clarity
  Set sServer.Recipient=Me
  sServer.RfCommListen sUUID, "MyApplication"
End Sub

Private Sub Form_Unload()
  If Not sServer Is Nothing Then sServer.Close
  If Not sClient Is Nothing Then sClient.Close
End Sub

Private Sub sServer_ConnectRequest(ByVal dfAddr As Double, ByRef bAccept As Boolean)
  bAccept=sClient Is Nothing
End Sub

Private Sub sServer_ConnectedInbound(ByVal sConn As StreamBluetooth)
  Set sClient=sConn
  Set sClient.Recipient=Me
End Sub

Private Sub sClient_Disconnected()
  sClient.Close
  Set sClient=Nothing
End Sub

Private Sub sClient_DataArrival(ByVal lSize As Long)
  ' Code that process data exchange with clients
  ' omitted for clarity
End Sub

Private Sub Button1_Click()
  Double addr

  If Not sClient Is Nothing Then
    MsgBox "Already connected!"
    Exit Sub
  End If

  addr=ChooseRemoteDevice() ' This function omitted for clarity

  Set sClient=New StreamBluetooth
  Set sClient.Recipient=Me
  sClient.RfCommConnect addr, sUUID, False
End Sub

The BtChat and BtWhiteboard samples show full functionnal implementation of such an application. You can also refer to the BtGPS sample, that shows how to connect to an arbitrary Bluetooth device, such as a GPS.

Receiving data

Unlike other streams, you should not call the Read function on a StreamBluetooth object and expect the call to block until the requested number of bytes are received. Instead, you should wait for the system to notify your code that enough data are available, and then read it. This behavior is imposed by the underlying architecture of the Bluetooth API. For more information on receiving data, refer to the DataArrival event.

Members

System requirements