Characteristic notifications arrive out of order on Android

Expected Behavior

I expect ‘onNext’ of safeMonitorCharacteristicForDevice for each notification to be called in the same order that the notifications are received. This would then log (using characteristic.logValue("Notification from", bytes);) the notification bytes in the correct order.

This is the behaviour that is observed in iOS.

Current Behavior

Currently, some notifications arrive out of order for Android only.

Steps to Reproduce

We are using a BLE device that sends notifications very fast (every few milliseconds) in order to transfer large amounts of data when we request it from the device.

Context

Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions. Both JS and platform logs can be enabled via setLogLevel function call.

I was originally thinking that this could be similar to the issue fixed in https://github.com/Polidea/RxAndroidBle/pull/639 but I’m not sure?

• Library version: 1.1.1
• Platform: Android
• Contents of the package.json file:

{
  "name": "...",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "concurrently -r \"tsc -w\" \"REACT_DEBUGGER=\\\"open 'rndebugger://set-debugger-loc?host=localhost&port=8081' --args\\\" react-native start\"",
    "test": "jest",
    "lint": "prettier \"app/**/*.{ts,tsx}\" --write "
  },
  "dependencies": {
    "@react-native-community/async-storage": "^1.5.0",
    "base64-arraybuffer": "^0.2.0",
    "date-fns": "^2.9.0",
    "react": "16.8.6",
    "react-native": "0.60.5",
    "react-native-ble-plx": "1.1.1",
    "react-native-gesture-handler": "^1.5.3",
    "react-native-keep-awake": "^4.0.0",
    "react-native-permissions": "^2.0.2",
    "react-native-reanimated": "^1.7.0",
    "react-native-share": "^2.0.0",
    "react-native-tab-view": "^2.11.0",
    "react-redux": "^6.0.1",
    "redux": "^4.0.1",
    "redux-devtools-extension": "^2.13.5",
    "redux-persist": "^6.0.0",
    "redux-saga": "^1.1.3",
    "reselect": "^4.0.0",
    "rn-fetch-blob": "^0.12.0",
    "styled-components": "^4.4.0",
    "text-encoding": "^0.7.0",
    "ts-enum-util": "^4.0.1",
    "uuid": "^3.3.3"
  },
  "devDependencies": {
    "@babel/core": "^7.8.3",
    "@babel/runtime": "^7.8.3",
    "@react-native-community/eslint-config": "^0.0.6",
    "@types/react": "16.8.6",
    "@types/react-native": "^0.60.11",
    "@types/react-native-keep-awake": "^2.0.2",
    "@types/react-native-share": "^1.1.5",
    "@types/react-redux": "^7.0.5",
    "@types/styled-components": "^4.1.19",
    "@types/text-encoding": "^0.0.35",
    "@types/uuid": "^3.4.6",
    "babel-jest": "^24.9.0",
    "concurrently": "^4.0.1",
    "eslint": "^6.8.0",
    "jest": "^24.9.0",
    "metro-react-native-babel-preset": "^0.56.4",
    "prettier": "^1.19.1",
    "react-test-renderer": "16.8.6",
    "tslint": "^5.11.0",
    "typescript": "^3.7.4"
  },
  "jest": {
    "preset": "react-native"
  }
}

[dariuszseweryn]

Feel free to update with whatever outcome you will have so other users who will stumble upon this issue could get the final thoughts as well.

[robwalkerco]

Just wanted to update this issue with our final solution.

We have ended up supporting two data transfer speeds on our BLE device firmware. (normal & slow)

When we fetch a batch of data, we check the integrity of the data to see if there were any transfer issues. If there were issues we refetch in slow mode.

When testing on an iPhone 7 and Samsung S7, we sometimes need to fallback to slow mode, and on a Pixel 3 we always get the data through first time (and super fast!)

We also do the same slow mode fallback if we get a MissingBackpressureException.

We are using version 2.0.0 of react-native-ble-plx now, and have not bothered about batching the notification data on the native side. It does not seem to make any difference (this was originally to rule out issues caused by transfer over the RN bridge).

We are finally happy with this solution, and it seems to make for a fairly reliable data transfer 😃

Thanks for your help @dariuszseweryn