Skip to content
This repository has been archived by the owner on Jul 4, 2024. It is now read-only.

Remove enum ambiguity from TransactionResult.responseStatus() #36

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

droolingsheep
Copy link
Contributor

@droolingsheep droolingsheep commented Sep 26, 2020

Fixes

description

TransactionResult.responseStatus was used to hold ordinals from both GattStatus and GattDisconnectReason enums, which created ambiguity about its meaning. Also, sometimes the "code" was passed in instead of the ordinal, creating an incorrect mapping.

Furthermore, there are 2 GattDisconnectReason enums, one of which appears to be a superset of the other.

changes

  • Changed the type of responseStatus to GattStatus to enforce type safety
  • Added a disconnectReason field to TransactionResult to carry this information as well
  • Marked the less complete GattDisconnectReason as @Deprecated
  • Tried to use the correct enum that corresponds to the namespace of the status argument in each callback. Definitely could have made a mistake here as it's not always easy to tell.

how tested

No changes to bluetooth behavior, so I didn't test it.

@droolingsheep
Copy link
Contributor Author

Please double-check that I picked the correct enum (GattStatus vs GattDisconnectReason) for each callback's status argument.

@@ -15,6 +15,7 @@
* Created by iowens on 8/10/17.
*/

@Deprecated
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could also just delete this enum entirely in favor of the other one.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say yes with renaming the other one to GattFailureReason since they are not all ending in a gatt disconnect.

@ionutlepi ionutlepi self-assigned this Sep 29, 2020
@@ -65,7 +65,7 @@ protected void transaction(GattTransactionCallback callback) {
if(null != serviceChar) {
if(doesDescriptorAlreadyExist(serviceChar, descriptor)) {
TransactionResult.Builder builder = new TransactionResult.Builder().transactionName(getName());
builder.responseStatus(GattDisconnectReason.getReasonForCode(GattDisconnectReason.GATT_CONN_NO_RESOURCES.getCode()).ordinal());
builder.disconnectReason(GattDisconnectReason.GATT_CONN_NO_RESOURCES);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel for these cases we should maybe have it as failureReason since this does not result in a disconnection

@@ -15,6 +15,7 @@
* Created by iowens on 8/10/17.
*/

@Deprecated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say yes with renaming the other one to GattFailureReason since they are not all ending in a gatt disconnect.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants