Skip to content
This repository has been archived by the owner on Dec 15, 2020. It is now read-only.

turn off science journal sensor scan to allow bluetooth classic scan to proceed #23

Open
sorenoid opened this issue Aug 4, 2017 · 2 comments

Comments

@sorenoid
Copy link

sorenoid commented Aug 4, 2017

Hi!

We are working on connecting a bluetooth classic sensor hub to SJ.

the issue we encounter is that the SJ sensor LE scan runs when the Sensor Settings activity starts, which blocks results from the bluetooth classic scan.

we can workaround by manually refreshing our BT classic scan after the SJ LE scan finishes.

the issue is exacerbated by the fact that we must connect to the hub to know what sensors are attached, so the process is quite painful already,

not the official docs, but this gives some context: https://stackoverflow.com/questions/25065810/android-bluetooth-scan-for-classic-and-btle-devices

hope all is well!

@dsaff
Copy link
Contributor

dsaff commented Aug 10, 2017

Sorry for the late response. Exciting to hear that you're working on a Science-Journal-connected sensor!

This makes sense; we had not realized that the scans would conflict in that way. I'll take a look at fixing in an upcoming release.

@sorenoid
Copy link
Author

I have more requests!

on the topic of needing to connect before we can call onSensorFound():

While scanning devices, as soon as we call onDeviceFound() for a discovered device, we receive an scanSensors() call for that device. We are usually still scanning for devices when this happens and we cannot connect to a bluetooth classic device while that scan is ongoing.

We have a few ideas about how to work around this, the preferred is listed here:

run a background thread to do the actual scanning, so when scanDevices() and scanSensors() calls come from the client SJ, we just report what was found by the thread.

however it has some shortcomings, the biggest being that we can't start the thread until the service is bound which makes it hard to provide results the first time a user opens the Sensor Settings activity. It is also difficult to know when we can join this thread in any absolute way.

I propose some new api calls to be called by SJ before SJ calls scanDevices() to give the thread a headstart, and to know when to shutdown the thread:

if (service.needsHeadStart()) {
service.pleaseStartScan();
//sj could put a spinner on Sensor Settings activity for some short period.
}
...
service.scanSensors();

//the call to tell the service to stop all scanning.
//as used, for example, from SensorSettings' onStop callback.
@OverRide
void onStop() {
if (service.needsHeadStart()) {
service.pleaseStopScan();
}

}

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

No branches or pull requests

2 participants