search

googlearchive / science-journal

Use the sensors in your mobile devices to perform science experiments. Science doesn’t just happen in the classroom or lab—tools like Science Journal let you see how the world works with just your phone.
https://sciencejournal.withgoogle.com/
Apache License 2.0
509 stars 131 forks source link

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

Open sorenoid opened 7 years ago

sorenoid commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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(); }

}