Различия между createRfcommSocketToServiceRecord и createRfcommSocket

Каковы различия между этими двумя способами ниже подключения к Bluetooth-устройству:

1)

UUID uuid = UUID.fromString(Values.SPP_UUID); //Standard SerialPortService ID mmSocket = mmDevice.createRfcommSocketToServiceRecord(uuid); 

2)

 Method m = mmDevice.getClass().getMethod("createRfcommSocket", new Class[] {int.class}); mmSocket = (BluetoothSocket) m.invoke(mmDevice, 1); 

Я считаю, что первый способ не может работать все время, иногда он будет работать, но после того, как я закрою устройство Bluetooth, он не будет работать снова. Второй способ всегда хорошо работает. Я знаю, что он просто открывает канал для общения с Bluetooth, но я не знаю, как он может это сделать, чтобы подключиться к устройству Bluetooth без использования uuid?

Подумайте об этом немного как о разнице между открытием TCP-соединения с указанным вами номером порта и открытием одного порта, который вы ищете по имени из /etc/services .

createRfcommSocketToServiceRecord берет UUID, который вы передаете, и использует SDP, чтобы решить, какой радиоканал использовать для соединения. Он также проверяет, чтобы сервер прослушивал удаленную конечную точку с тем же UUID. Таким образом, это самый надежный способ получить соединение: он всегда будет использовать правильный канал, и если открытие соединения будет успешным, вы знаете, что на другом конце вы сможете понять свой протокол.

Напротив, createRfcommSocket просто подключается к каналу, который вы ему рассказываете. Невозможно узнать, слушает ли что-нибудь на удаленной конечной точке: вы знаете, что устройство есть. Кроме того, ваш выбор радиоканала может быть совершенно неуместным. Вот почему эта функция не публикуется в API, а другая функция предпочтительнее.

createRfcommSocket может показаться на первый взгляд более надежным, но это связано с тем, что он не проверяет наличие слушателя на другой конечной точке: он игнорирует некоторые случаи ошибок. Это может быть хорошо для экспериментов, но это бесполезно для производственной системы, потому что часто пользователь забудет запустить сервер на другой конечной точке, и ваше приложение не будет запутывать.

Конечно, поскольку createRfcommSocket не публикуется в API, у вас нет гарантии, что он будет продолжать работать вообще в будущих выпусках Android.