-
Notifications
You must be signed in to change notification settings - Fork 572
OnDataReceived #30
Comments
Hi, It may be too late, but this may help someone else. I had the same problem and solved. Somehow the "setOnDataReceivedListener" method gets called more than once, and the mDataReceivedListener points two different objects. You can fix it as: Find the following part in BluetoothSPP.java: public void setOnDataReceivedListener (OnDataReceivedListener listener) {
mDataReceivedListener = listener;
} modify it: public void setOnDataReceivedListener (OnDataReceivedListener listener) {
if (mDataReceivedListener == null)
mDataReceivedListener = listener;
} |
Not sure that works... what happens if you want to add again a new receiver? The function will reject it because it was previously set. |
Well, I accept there may be some side effects, but I am 100% sure that it works this way, if there are no other errors. By the way, I used the autoconnect example provided in the library itself adding datareceivedlistener to it. Answering your question: I can't think of any case having more than one event handler (or listener) in the same code for the same event that is useful. Even so, the library programmer would have provided an array of "mDataReceivedListener" and invoke all upon the event occurrence, i.e., upon data reception. |
Well, the library does not offer an array parameter. Maybe you can't think of any case... but I certainly do and actually use. Just think of a program that passes different messages back and forth... for each message you would expect a different response, so one think you can do is re-program the receiver. I agree there are other ways to do it, though. Besides, coming back to the original question from @mschopra , there are many reasons why you can't receive, but without further analysis it's impossible to come up with an answer. I don't know where @lazy21tr second call to setOnDataReceivedListener comes from... but there are other users (look in the isses section) that report that you need an end-of-line sent for the receiver to pass the message through. There is an Android BlueTooth Debug option in your phone that dumps the buffers to a file in the SD Card, maybe you can try that out. |
Thank you @naevtamarkus for your thorough responses. Of course there may be plenty of causes preventing data reception. I use the same hardware as @mschopra, the HC05 module. Yes you are right that the receiver needs to send end-of-line characters since the library does a check (in BluetoothService.java, ConnectedThread's run section) for end-of-line before invoking the datareceivedlistener. But I think this is not an issue to fix, just a preference of the library programmer. I don't have any problem regarding data reception anymore, that is why I commented here. I share my source files here as it may help someone who got stuck with the issue. Update: P.S.: The same problem happens for the setBluetoothConnectionListener method either. I figured out today that this is happening as I set listener methods in onCreate method. For some reason (e.g., upon orientation changes) onCreate gets called again. Someone may come up with another solution to the issue, but I solved it in this way: preventing duplicate assignment. |
Hehe, this is interesting... I use HC05 too! Any Arduinos behind? :) I actually have a problem with the setBluetoothConnectionListener... you gave me the idea with the setOnDataReceivedListener, funny that you mentioned setBluetoothConnectionListener just now!! It's very weird: The thing is that, when I use this BT module from a normal activity it works like a charm (I mean, setting all those callbacks) but when I do it from a background thread (a BroadcastReceiver, to be specific) the callbacks somehow disappear! It looks like, in your case, someone-or-something is wiping them without my consent! I will try your workaround when I have some time and, if that worked, I am going to send you flowers :) Not that is a solution, though... we need to find where this setBluetoothConnectionListener(null) comes from! |
淡定 ------------------ 原始邮件 ------------------ 主题: Re: [Android-BluetoothSPPLibrary] OnDataReceived (#30) Hehe, this is interesting... I use HC05 too! Any Arduinos behind? :) I actually have a problem with the setBluetoothConnectionListener... you gave me the idea with the setOnDataReceivedListener, funny that you mentioned setBluetoothConnectionListener just now!! It's very weird: The thing is that, when I use this BT module from a normal activity it works like a charm (I mean, setting all those callbacks) but when I do it from a background thread (a BroadcastReceiver, to be specific) the callbacks somehow disappear! It looks like, in your case, someone-or-something is wiping them without my consent! I will try your workaround when I have some time and, if that worked, I am going to send you flowers :) Not that is a solution, though... we need to find where this setBluetoothConnectionListener(null) comes from! — |
the setBluetoothConnectionListener was not listed as an issue by @mschopra or someone else (afaik), that's why i didn't mentioned it before. hope you come up with a good solution :) |
Yeah, sorry, I was using this thread as a chat :-) |
Hi, My BT SPP device is receiving the data I sent, and replies back, and I can see the reply in the Bluetooth HCI snoop log (so definitely is received by my Android tablet), but the event is never raised in the BluetoothSPPLibrary. I am using: Any thoughts? |
I found the reason.
When the byte equals '0x0D' which means ENTER, it will notify the handler.I debuged here, it entered with the message, but it not notified the method onDataReceived since there is no byte '0x0D'. When I send the message contains '0x0D' (ENTER), it works. |
public void run() {
I have same code but still it is not working. |
add '\r' end,and it really works! |
any one solved the problem |
hi,
I have tried this code and everything is working fine except data receive , i am not able to receive data by my HC-05 module .
Data send by mobile is working fine , please suggest
The text was updated successfully, but these errors were encountered: