Android Question Bluetooth Connect/Disconnect Intent

I assume that you are using AsyncStreams. You should handle the Error and Terminated events and try to reconnect.

Erel said:

I assume that you are using AsyncStreams. You should handle the Error and Terminated events and try to reconnect

Click to expand...

I am, and it is working fine (I modeled it on your "ConnectOrReconnect" method example). I was just hoping there was some type of Intent I could monitor rather than just blindly attempting to connect to a specific MAC every few seconds once I've lost a connection.

From the research I've done it seems that Android Bluetooth is something of a mess and there doesn't seem to be any Intent notifications from the OS until after a device has connected. I was looking for some type of "I've detected a paired but un-connected device now!" Intent but I can't seem to find anything like that and I was hoping I was just searching the wrong Intent tree. Other than blind-reconnect the only other solutions I've found are variations on building and monitoring a list of all Bluetooth devices and their states, etc. which seems a bit of overkill.

I was just hoping that there was a solution that didn't involve a timer and a blind-connect attempt that I had not discovered. If there really isn't then that means all the apps on my phone that talk to my automobile/speakers/headsets/etc. are constantly idling in the background trying to connect to the associated BT devices? No wonder my battery drains quickly

Why don't you try to discover the device with BluetoothAdmin?

The device is already paired, so it's in the device list regardless if it's on or not. And discovering still requires the app to run a timer and poll something. If you're going to do that you might as well attempt a blind connect and save yourself a step. I was hoping for a more object-oriented solution that didn't require my app to waste CPU cycles trying to connect to a sleeping device but I haven't been able to find anything like that in the Android BT documentation.

The barcode reader is something of a special case, unlike headphones or a speaker or another device running your app, the reader is designed to stay powered off unless you're actually using it so it disconnects frequently. As a result the connection state is not driven by the app usually but rather by the device itself.

The model our customer is using has a 30-second idle timeout so nothing scanned in 30 seconds means the reader disconnects and powers down. Once the reader wakes up, you need to connect to it ASAP so the user isn't waiting on your app before they can scan something. Because, believe me, our users are somewhat impatient and not very gentle when it comes to peripheral hardware. ?