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

Question

Каковы различия между этими двумя способами ниже подключения к 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?

Answer 1

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

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

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

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

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