Please add possibility to use hidden metod refresh on BluetoothGatt about rxandroidble HOT 10 OPEN

Thank you for the suggestion. We will considerate it. Unfortunately we're currently occupied with different things.

You're always welcome to make a Pull Request. :)

from rxandroidble.

This refresh may be the last resort for problems like #49.

from rxandroidble.

This refresh is essential for any kind of function that involve change of characteristic during reconnection. I believe the framework can be much more powerful if "refresh" is supported

from rxandroidble.

@s1155030742 I did not had a need for using the refresh function. Could you describe or paste link to a place where the usage is described? Should the method be called when the connection is active/disconnected/closed? What exactly the method does?

from rxandroidble.

Use of this method is discussed here: http://stackoverflow.com/questions/22596951/how-to-programmatically-force-bluetooth-low-energy-service-discovery-on-android

Basically, some phones cache the list of services and characteristics between connections. So if the device has changed it's services or characteristics since you last connected, you can have fatal errors. The refresh() method will clear the phone's cached list.

Based on the code samples and how I understand that it works, I think refresh() would have to be called after connection but before service discovery starts.

I just got bit by this this morning, connections are failing left and right. Is there a way to get hold of the native BluetoothGatt so I can implement the fix described in the Stack Overflow until this feature can be implemented?

from rxandroidble.

@kenwdelong You could try to use <T> Observable<T> queue(RxBleRadioOperationCustom<T> operation); function.

from rxandroidble.

Yes! Thank you!

from rxandroidble.

To all interested people:
What is the supposed scenario for calling BluetoothGatt.refresh()?

1. Call it at the beginning of the connection
2. Call it in the middle of the connection
3. Call it at the end of the connection

The last option looks to be the most bulletproof in terms of implementation. The first one seems also to be doable and should not require a big amount of work. The second does look like a pain to implement as some Observables that could have beed created / subscribed before refreshing could stop working properly.

Any information about the use-cases for this is valuable! :)

from rxandroidble.

Hi all, just ran into this problem now! The bluetooth connection on my device disables and I cannot re-enable it unless I flush the data/cache of the bluetooth process. The only way to do this is to call BluetoothGatt.refresh();

Problem 1. Bluetooth is currently disabled and I need to be able to run the refresh method first (because I don't have a valid connection)

Regarding best scenario for calling BluetoothGatt.refresh(), I would personally prefer at the beginning of the connection.
Reasoning: It's the only predictable place where I can reliably call it.

from rxandroidble.

For us, our device can be in normal "application" mode or in "dfu" (direct firmware upgrade) mode. In dfu mode, the list of services and characteristics is a subset (generally) of what's available in application mode. So, for example, if the device is scanned in dfu mode, and the phone caches the results of service discovery, then even if the device has returned to application mode it can't be accessed because the phone does not believe that the required characteristics exist (and vice versa).

I really don't know when is the best time to refresh. Just after connecting and before service discovery, or just before or after connecting. I doubt that refreshing in the middle of the connection is a good idea.

The Nordic DFU Upgrade library, I think, disconnects but then before it releases the BluetoothGatt object it invokes the refresh() function. That's probably a pretty safe option.

from rxandroidble.