1

I am programming an application which connects to a Bluetooth device, then sends a message and gets an answer. This is the code I am using to get the answer :

    StringBuilder res = new StringBuilder();
    while ((char) (b = (byte) in.read()) != '>') {
        if ((char) b != ' ') {
            res.append((char) b);
        }
    }
    rawData = res.toString().trim();

Basically, it takes every characters one by one and adds them to a StringBuilder

When there is an answer, no problem, it works. But the issue is when there is no answer from the device (because the connection was lost anyhow).

How can I put a limit on the time I am waiting for a character?

EDIT :

Here is my BlueTooth connection

final BluetoothAdapter btAdapter = BluetoothAdapter.getDefaultAdapter();
    _dev = btAdapter.getRemoteDevice(remoteDevice);
    try {

        Method m;
        m = _dev.getClass().getMethod("createRfcommSocket", new Class[] { int.class });
        _sock = (BluetoothSocket) m.invoke(_dev, 1);
        _sock.connect();
        setState(STATE_CONNECTED);
        sockIn = _sock.getInputStream();
        sockOut = _sock.getOutputStream();

    } catch (Exception e) {
        closeConnection();
    }
WhiskThimble
  • 547
  • 3
  • 10
  • 23

1 Answers1

1

Use the InputStream "available" method

reference page for InputStream

to check if there is data in the stream before reading without blocking, and check for the elapsed time between reads to decide if a timeout occurred (System.getCurrentTimeMillis() should do the job).

Check this answer for reference and a complete listing:

Implement a timeout in BluetoothSocket inputstream.read() in Android

EDIT:

If I'm correctly reading between lines from your comments, you could really use a Bluetooth UDP socket...

Sadly it seems that you can't use datagrams with Bluetooth on Android, therefore you have to stick with TCP.

If the data you want to send between devices is event driven (e.g. you want the user on device A to receive a notification as soon as the user on device B touches the screen/fires his weapons/etc) you can still adjust your reading loop to do what you want.

All you need is a working thread where to put the loop doing the I/O heavy lifting, and a Handler (create it in the UI thread) that will notify some Listener of your choice as soon as you receive anything.

Keep in mind that I'm only guessing your usage scenario, so don't get mislead if asynchronous event-driven communication is not the problem.

Hope this helps

Community
  • 1
  • 1
Rick77
  • 3,121
  • 25
  • 43
  • If I understand well, in this example, you check if the InputStream has some byte in it, then you start to read it. That causes a problem for me, provided I need to get the answer message very fast I will try this anyway, to see if it works without a timer loop – WhiskThimble May 27 '13 at 16:05
  • I have expanded my answer a little, still I'm not sure of what the problem is. What do you mean with "I need to get the answer message very fast"? As far as I understand, the speed of the answer you'll receive will mostly depend on how fast your peer is sending it... – Rick77 May 27 '13 at 17:07
  • The application I am coding is a bit particular. When I write some command with my android device, the other Bluetooth device (which is not Android at all) sends an answer. I need to get this answer really fast, thats why I will try to minimize the `Thread.sleep(someTime);` in the loop. After reflexion, if the time to sleep is really short (maybe 5 millis), this shouldn't slow the app too much. Thanks for your complete answer – WhiskThimble May 28 '13 at 07:34
  • well, if battery consumption is not a big issue, you can probably remove the Thread.sleep altogether, as since everything happens in a separate thread it shouldn't hurt responsiveness. Depending on your usage scenario you can also try to match the sleep with the expected activity on your comm channel (e.g.: if you expect the commands to come in bursts, you can wait for 100 ms each loop iteration until some message arrives, then for at least the next 10 iterations and as long as the commands keep coming you wait 1ms. Just an example). Your welcome – Rick77 May 28 '13 at 08:30