Parameter specified as non-null is null about android-ble-library HOT 12 CLOSED

Thanks for testing the lib! I'll push sone updates asap.

from android-ble-library.

What result would you expect in that case? In both success and fail callbacks, the BluetoothDevice is @NonNull. Should I add another callback for invalid state? Remove the annotation in fail or 'success' (set to @Nullable)? Right now it reports success, as you are indeed disconnected.

It's only this one case when the BluetoohtDevice may be null.

from android-ble-library.

The BluetoothDevice could also be set in the BlueManager's constructor, instead of calling it in connect(..). But that would break a lot when upgrading to the next version. What do you think?

from android-ble-library.

From disconnect javadoc

Does nothing if device was not connected.

In this case, I'd expect the call to do nothing, since we are not connected.

Does doing nothing also invoke fail? I'm not sure if that's what I'd expect, but I understand that you'd rather invoke one of the two, tho I find done is more appropriate in this case.

First option would be to remove the @nonnull annotation from BluetoothDevice and set it to @nullable. That'd fix kotlin expectations, tho it's a breaking change that should be added to release notes.

As a second, more complex approach, would you consider an approach similar to RxJava's Maybe? It either emits onSuccess, onError or onComplete

From its javadoc: onSuccess, onError and onComplete are mutually exclusive events

onComplete's name might be misleading and developers might think it's invoked after done, so maybe something like ignored or skipped

I'd maybe go for the 1st approach. Adding a ignored callback means increasing the complexity of the library. Is there any usecase for such a callback?

Regarding the BluetoothDevice as a parameter to BleManager, that'd also break the possibility connect to multiple devices with a single BleManager. I don't know how desirable that is or if people are using it that way.

If it's not desirable to reuse a BleManager for multiple devices, then I'd definitely enforce it as a constructor parameter to avoid unexpected issues. Otherwise, I'd leave it as it.

from android-ble-library.

I've already started implementing invalid callback to each request. It would only be called when connect was never called and BluetoothDevice is null. At least so far. That would also include Sleep request (which doesn't need BluetoothDevice, actually, but for consistency. And I left @NonNull in both done and fail callbacks. That way, I think, is the most "backwards compatible", as you don't need to make any changes, you don't need to handle the new invalid callback and you are guaranteed that success and fail will indeed have non-null parameter.

RxJava approach also seems good, but that would break everything.

Btw, how does the lib work with Kotlin? I tried to make it Kotlin-firendly, but actually never tried it with it.

from android-ble-library.

Thanks for the quick response!

There are no differences when using it from kotlin, It's straightforward.

The thing is, if a parameter is annotated as @nonnull BluetootDevice, kotlin's type is BluetoothDevice, whereas if it's @nullable the type is BluetoothDevice?, which is different from the non-question mark type. If a non-null parameter receives null, it's a runtime error because it's not of the type it expects.

from android-ble-library.

But there are those thing that make a library more Kotlin'y, like @Nullable or @NonNull that, that you already mentioned, that are converted to optional or not optional fields, but also callbacks as a last parameter can be open, etc. I just wonder if anything could be improved to make it better before going to final version.

from android-ble-library.

sorry I misunderstood your question

I haven't found any issues, but I'm not that experienced with Kotlin

I know of two interop guides, but I guess you already checked that

https://kotlinlang.org/docs/reference/java-to-kotlin-interop.html
https://android.github.io/kotlin-guides/interop.html

from android-ble-library.

Ok, this issue should be fixed with the new PR. Would you like to have a look at it before I merge?

from android-ble-library.

I'm taking a look but I don't expect to be of help, it's a complex code

from android-ble-library.

Released in beta3.

from android-ble-library.

It's fixed, congrats and thanks!!

from android-ble-library.