Adjust BleCannotSetCharacteristicNotificationException to be more descriptive

[kanat]

Summary

• app has connection to BLE device
• BLE device has characteristic with indicate enabled
• disconnection happens
• when app tries to invoke rxBleConnection.setupIndication(...) BleCannotSetCharacteristicNotificationException comes, but I expected to see BleDisconnectedException

P.S. before disconnection I could see:
BleGattException{macAddress=ED:78:87:F9:85:31, status=8 (0x08 -> https://android.googlesource.com/platform/external/bluetooth/bluedroid/+/android-5.1.0_r1/stack/include/gatt_api.h), bleGattOperationType=BleGattOperation{description='CONNECTION_STATE'}}

Preconditions

Steps to reproduce actual result

1. get app connected to BLE device

2. get app disconnected from device by going away

Actual result

BleCannotSetCharacteristicNotificationException

Expected result

BleDisconnectedException

Logs

error.txt

[dariuszseweryn]

BleCannotSetCharacteristicNotificationException is quite accurate in this situation as that is actually what is happening. What can we do:

• Emit the exception that caused the disconnection. This could fit in a patch release (it would be either BleDisconnectedException or BleGattException) as it would be in line with how the library works on different requests.
• Wrap BleGattException in BleDisconnectedException. It would be a change in the behaviour and should wait at least till 1.4.0 release.

I can go with the first point now and the second for 1.4.0. Would that fit your idea?

P.S. You should not use Observables derived from an RxBleConnection after that connection has been disconnected. It shows that you have more than one .subscribe() call. It is not a good idea when using RxJava as it may introduce state somewhere. While using BLE the connection is stateful and that is why a single .subscribe() should be used.

[RobLewis]

Regarding @dariuszseweryn P.S.: apologize for off-topic; please let me know if I should open a separate issue or address this somewhere else:

My app writes to 2 different characteristics and receives notifications from 2 others. I don't see any realistic way of combining all these into a single .subscribe(), especially since one notification is a pretty constant data "firehose".

Not knowing any better, I have been simply storing the RxBleConnection in a variable and using it in multiple .subscribe()s. As far as I can tell, this has been working OK. I've investigated the ConnectionSharingAdapter but as I discussed here, I don't understand what benefits it offers over my simplistic approach, though I would love to know.

In general, some elaboration on how multiple .subscribe()s introduce state, and the potential pitfalls, might be helpful.

[kanat]

I can go with the first point now and the second for 1.4.0. Would that fit your idea?

Ok.
The Idea is to get what is the reason of BleCannotSetCharacteristicNotificationException.
Adding getCause() could help as well.

The second problem is I cannot ask somewhere what is a current state. The only way is to susbscribe to RxBleDevice.

You should not use Observables derived from an RxBleConnection

Yeah, that's what I'm trying detect in onError branch, but Exception tells me nothing about Disconnection.

My logic is following:

1. Scan selected device
2. Get connection
3. Subscribe to indication
4. Communicate until Disconnection
5. Restart from 1 if it was a Disconnection or from 2 otherwise

As I understand I need to restart subscription if I get any exception from RxBleConnection. Am I right?

[dariuszseweryn]

@kanat Yes. If the .establishConnection() will emit an error then no observable derived from the connection should be used - they will emit an error anyway.

So far it seems that your use case also could be fulfilled with only one .subscribe(). You can open a question on www.stackoverflow.com with a tag rxandroidble and rx-java and someone will answer on how to get the connection error there.

@RobLewis Your question should go to www.stackoverflow.com as well as it is a general question about how to use rx-java

[kanat]

Ok.
The only diff between knowing it's a disconnection or not is where I'll start again from point 1 (scan) or from point 2 (if it wasn't disconnection then I can try to reconnect without scanning)

Should I close the issue? Or it will be opened until version 1.4.0?

[dariuszseweryn]

Do not close it. I will leave it be until I will better specify the behaviour.

[kenwdelong]

@RobLewis Rob, did you post this question on SO? I am very interested in the answer as this fits my scenario as well.

[RobLewis]

I did, here: https://stackoverflow.com/questions/44637878/using-multiple-subscribe-statements-with-rxjava/44639493#44639493 Hope to try out the ConnectionSharingAdapter tomorrow. Cheers,

…

--Rob

On Jun 20, 2017, at 14:37 , Ken DeLong ***@***.***> wrote: @RobLewis <https://github.com/roblewis> Rob, did you post this question on SO? I am very interested in the answer as this fits my scenario as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#225 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJVYtrAxu1m7oVSzAVigJ7wu-x299Gtks5sGDuEgaJpZM4N-NrK>.

[dariuszseweryn]

@kanat Feel free to check and comment the above Pull Request wether it will be useful for your use-case.

[kanat]

@dariuszseweryn it's ok now, thanks

[dariuszseweryn]

Is available in 1.4.0-SNAPSHOT