The Bluetooth API provides access to RFCOMM, L2CAP, and SDP protocols.
Most Bluetooth applications use point-to-point connections between two devices. However, in certain applications, such as games, point-to-multipoint connections could provide added value. To get the best out of point-to-multipoint connections, a few conditions must be considered.
Note that not all Bluetooth devices support point-to-multipoint. Also, test your point-to-multipoint application with multiple devices to find out the actual number of how many devices can be used with your application. The Bluetooth specification defines seven as the maximum number of slaves, but in practice the device implementation or its resources may limit the number.
In current phones, scatternet is not widely supported. This means that a slave can only accept one connection at a time, and it cannot be a master while already being a slave in another piconet. This means that you can only establish multiple connections from one single device (master) to slaves.
In point-to-multipoint scenarios, the handling of interruptions becomes crucial. For more information on interruptions, see the guidelines in section Handling interruptions.
Check that:
If you state that your application connects with, for example, seven devices via Bluetooth, make sure that it supports those seven devices and that the usability of the application does not suffer.
Bluetooth device and service discoveries may take a while to complete. Therefore, it is advisable to optimize these procedures. In device discovery, use Limited Inquiry Access Code (LIAC) instead of General Inquiry Access Code (GIAC) whenever possible. With a LIAC inquiry, the application finds only the devices that are in Limited-Discoverable mode, thus speeding up the procedure. Using LIAC is especially feasible when discovering counterpart device(s) that are waiting for your connection, for example, to start a game. Please note that you have to set the counterpart device (application) into the Limited-Discoverable mode. In Bluetooth devices, Discoverable mode is usually set as the default.
You can also optimize the discovery procedures by stopping the discovery after the first match(es). In service discovery, for example, you can stop the search after you have found the first device(s) running the desired service of the application.
Check that:
Device and service discoveries are efficient. Use Limited Inquiry Access Code to speed up the discovery procedure if feasible.
In idle mode, Bluetooth does not significantly increase power consumption.
However, when you have an active Bluetooth connection, it is worth considering
disconnecting the link whenever no data is transferred for a long time to
decrease power consumption. When the connection is reopened, use the retrieveDevices() method
of the DiscoveryAgent to return an array of Bluetooth
devices that have either been found by the local device during previous inquiry
requests or have been specified as preknown devices depending on the argument
of the method.
Check that:
The connection is turned off if it has not been needed for a long time.
The application is responsible for possible recovery actions, for example, for reconnecting the link, for continuing to work after one device has left the session, and for notifying users about the situation. However, when implementing recovery features, keep in mind that the user interface must be logical in order to provide a good, intuitive user experience.
A typical interruption occurs when one of the devices receives an incoming
call or a message. In this case, the Bluetooth application should locally
go into the paused mode using the hideNotify() method
as described in section Pausing
a MIDlet. A Bluetooth application should also inform the connected
devices about the pause (in the case of a point-to-multipoint scenario, the
slave receiving a call or a message first informs the master, which in turn
should then inform other slaves). The application has the liberty to use any
proprietary message in order to command other devices into the paused state,
as there are no standardized methods. The Bluetooth link remains connected
also during the paused state, so there should be no need to reconnect just
for continuing the application.
There are also several cases that may happen to a remote slave device: It may move out of range, run out of power and eventually be switched off, or its application may be closed (disconnected) by the user. For the master-side application, all of these cases look as if a remote device was disconnected. The slaves cannot see if one of them is disconnected. Therefore it is the master-side application’s responsibility to inform the remaining slaves about the changed situation. There are several possible ways to handle these cases. The application could be continued by the remaining parties or the master could attempt to reconnect to the disappeared device. In the latter case, it is possible that the device won’t be found again because, for example, its application may not have been restarted.
It is a trickier scenario if the master disconnects from the application, because it leads to the dismantling of the whole piconet (the slaves cannot run the piconet without a master). There is the possibility for any slave to start discovering the devices and become a new master. The game should be saved so that it can be continued. It is up to the developer to evaluate if this kind of recovery is feasible and reasonable to implement.
The system usually closes connections when the application is about to close. For convenience, it is recommended that the Bluetooth connection is either disconnected by the user or programmatically before the application closes.
Check that:
Other devices continue the Bluetooth session even though one device would disappear from the session.
The user is informed in case of interruptions.