I am a newbie for Android and Pusher.
We just migrated Pusher in Android Native App. However, we are facing a problem with the subscribed the Channel Twice(I think the connection will be twice too).
Checked that we just create the pusher object under the onCreate and establish the connection.
We also added the pusher.subscribe under onResume and unsubscribe under onPause, onDestroy.
As document said An exception will be throw when subscribe twice.
When I start the apps. I checked the logs with the attached debug message.
Showing two connections.
The attached file is my MainApp. Anyone can help? Many thanks. :) .....
* all subscribe and unsubscribed is added try .. catch .. exception now.
Thanks all. Since we are working this issue nearly 5 days...... Thanks all again and again.
2013-08-12 Update:
Hi all, i just amend the log and retest the program. The following is my result:
I checked that the connection is from connecting to connected once only. However, the pusher debug console show me:
- The Channel: 2235d980e0621a54
It is quite strange. We are still investigating this issue.
The updated new source is here:
Latest Source - MainActivity
A few clarifications:
When you create a new Pusher instance and call connect you establish a connection.
When you call pusher.subscribe('channel'); you create a subscription to a channel - not a connection
The code you've provided subscribes to the same channel in both the onCreate and the onResume. You don't need to resubscribe in onResume as the library handles this for you. This existing code could result in an exception being thrown. So, you can remove the onResume code and remove that problem.
I'm not sure why you would be seeing two connections. Could you please provide details of the client log from your application?
Related
I'm trying to write BLE Android app. I found that sometimes when I call
BluetoothGatt.writeDescriptor() it returns false.
I have not found in documentation any note of limitation to this function. But ppl on stack overflow says that I need to wait for BluetoothGattCallback.onDescriptorWrite() before I try to write another descriptor.
Here is one reply saying that BLE is busy with writeDescriptor() and can not do other write.
Here is another thread saying that you can not call twice writeCharacteristic().
My questions are
is it really true?
is there really missing some internal android API buffer for serializing BLE requests and every developer has to do it on it's own?
Is it true for different functions? For example when I call writeDescriptor() I understand I can not call second time writeDescriptor() before I receive onDescriptorWrite(). But do I have to wait for onDescriptorWrite() when I want to call writeCharacteristic()?
Also if there is inter-function dependency then what else function have this limitation (namely: readCharacteristic(), readDescriptor(), requestMtu()...)?
And additionally is there interdependency between BluetoothGattServer and BluetoothGatt. So for example when I call BluetoothGattServer.notifyCharacteristicChanged() shall I wait forBluetoothGattServerCallback.onNotificationSent before I can call BluetoothGatt.writeDescriptor() or BluetoothGatt.writeCharacteristic()? (BTW praise for google documentation onNotificationSent() is by luck documented properly. Doc says:
When multiple notifications are to be sent, an application must wait
for this callback to be received before sending additional
notifications.
Lastly having all this questions - I feel that Android BLE API is under-documented. Or am I wrong and there is documented somewhere what are allowed methods calling sequences? If yes can you please point me to such documentation? If not is there some channel we can open issue with google and ask them to add to documentation something? I mean it may not be much text - some function like onNotificationSent() is arleady properly documented. They just need to copy this sentence to other functions.
The documentation lacks information. However you can read the source code to find out the rules, which (currently) are the following:
For each BluetoothGatt object, you can only have one outstanding request at a time, including requestMtu, readCharacteristic, writeCharacteristic, readDescriptor, writeDescriptor and executeReliableWrite. So if you issue a read request you need to wait for the read response before you issue a write request. While they implemented the code that returns false if there is an ongoing operation in BluetoothGatt.java, they forgot to do this for requestMtu, so if you have multiple requests at a time where requestMtu is one of them, you will get random errors sooner or later (in the latest versions at the time of this post).
So yes, every developer has to manually serialize the requests. Note that the Bluetooth stack actually has a queue of requests, but it is limited to only one request per client (i.e. BluetoothGatt object). So if two apps on the same phone talk to the same device simultaneously you will never get "busy" errors. The only exception is if you use Write Without Response for which the current data flow implementation is quite buggy (see https://issuetracker.google.com/issues/37121017 which Google seems to have ignored).
You can send notifications at the same time as you write a characteristic, since the server and client roles are separated.
Regarding updating the documentation, you can always try to file an issue at https://issuetracker.google.com (but I get the feeling nobody reads that), or, since Android is open source, send a pull request to https://android-review.googlesource.com/ which updates the Javadoc from which the documentation is generated.
I am getting getBluetoothService() called with no BluetoothManagerCallback as an error frequently in my Android application.
I have no idea what is causing this or anything about bluetooth manager callbacks. Can anyone give me a good idea of what could be causing this problem or where to start looking.
By reading into the Android source code, it seems to be a warning you cannot do anything about. The source code shows that if you call
BluetoothSocket#connect();
Then it will call
BluetoothAdapter.getDefaultAdapter().getBluetoothService(null);
The key here, is the null parameter that it passes in the above line. Due to this, there will be no callback, and then the BluetoothSocket class will throw out a warning.
Since it is only a warning, I do not think you need to do anything about it.
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/bluetooth/BluetoothSocket.java line 306
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/bluetooth/BluetoothAdapter.java line 1610
It appears that this gets called when multiple bluetooth sockets are opened at once. I fixed this by ensuring I was only opening 1 socket at a time.
I get this error even after my application has been closed and I can't get rid of it in any possible way. After this start happening I need to hard-reboot my phone because I'm not able anymore to even turn ON bluetooth.
Right now (with the same code) it happens only on one of my phones.. maybe it's an issues of the drivers.
This also comes up if the BluetoothServerSocket isn't currently accepting [bluetoothServerSocket.accept()] with the same UUID you are trying to connect.
If you are sure you are accepting with the server socket, double check that you haven't provided a too short timeout (I had previously set it to 200 to check something, whoops).
I received this message after trying to BluetoothSocket.connect() directly after receiving the BluetoothHeadset.ACTION_CONNECTION_STATE_CHANGED with a state of BluetoothHeadset.STATE_CONNECTED. The BluetoothSocket.connect() also failed. After adding a timeout of 500ms before trying to BluetoothSocket.connect() this resolved my issue of actually connecting. The message "getBluetoothService() called with no BluetoothManagerCallback" still remains but everything works.
getBluetoothService() called with no BluetoothManagerCallback
I am also facing the same problem. But I solved.
In my case already one socket is in open state and I am trying to open another socket. So we trying to open more than one socket at a time as a client. I felt that this is the reason
I'm writing a NDK wrapper around libspotify on Android. But sp_session_callbacks:: logged_in callback never called.
This is content of tracefile:
libspotify trace from 12.1.51.g86c92b43 Release Android-arm
< sp_session_create() = 0
> sp_session_login(0x240ea8 'moodstream1#gmail.com' '<hidden>' 0) on 0x400fc4c8
This is a log received with sp_session_callbacks:: log_message callback.
13:30:07.361 I [offline_authorizer.cpp:297] Unable to login offline: no such user
13:30:07.372 I [ap:1752] Connecting to AP ap.spotify.com:4070
13:30:07.382 I [network.cpp:438] Connecting to 193.182.8.10:4070
13:30:07.526 I [ap:1226] Connected to AP: 193.182.8.10:4070
As you see session was created correctly.
I've tested on real devices and emulator. The result is the same. Any ideas?
The problem could be that they are not driving libspotify properly. This is one of the common problems that people have.
Specifically it is important to listen to the notify_main_thread callback. This indicates that libspotify needs to process some data from the GUI main thread.
sp_session_process_events should then be called from the GUI main thread. sp_session_process_events must also be called periodically based on the next_timeout value returned
The faq covers this https://developer.spotify.com/technologies/libspotify/faq/ and the sp_shell examples serves as an illustration.
can you provide a code snippet that shows such error? From a quick test (using the spshell example) I get the logged_in callback called correctly on Android.
As daek says, and judging from the output to the tracefile, it seems you're not driving the libspotify event processing using sp_session_process_events() and listening to the notify_main_thread callback.
When correctly implemented you should be able to observe a "sp_session_process_events" line now and then in the tracefile log.
My android app keeps logging this warning :
IdleConnectionHandler removing a connection that never existed
What does that mean? Is that a big problem? What should I do to avoid this?
My app makes many http connections in AsyncTask, is that related?
EDIT:
I found that this call was the reason of this message :
httpclient.getConnectionManager().closeIdleConnections(30, TimeUnit.SECONDS);
So maybe it tries to close some connections that don't exist?
It sounds like there is a logic error in your code. You may be able to track down the problems using this Android tool called ARO. You can find out more about it here http://developer.att.com/developer/legalAgreementPage.jsp?passedItemId=9700312
It will help you to understand more about how your application is using the network and how you can improve that part of your application to make it more efficient.
Is there a reason you need to make many http connections at once?
I got that error too, but my app uses internet only for ad loading. Currently I have no permission that my app can use internet, so that is why it says "Removing a connection that never existed". That may be one of the reason for this warning.
In my application when i am making a outgoing call and if i ended it from my application its ended properly but when call receiver ends that call, sometimes it ends sometimes its not.
i debug the application many times and came to know that sometimes call goes into onEndCall() method and sometimes it does not.if call goes into this method it works fine.so what could be the reason for that?
I am using Android 2.3.3 and Asterisk 1.8.10.0
I guess you are experiencing a similar issue as me:
https://stackoverflow.com/questions/9875935/android-2-3-4-sipaudiocall-listener-oncallestablished-not-firing-every-time
Even in your case I think that the Listener that you connect to incoming calls (which are passed from the call receiver to your activity) is not always firing the methods. Therefore the call is closed in your application, but not in asterisk / on the other device.
I am sorry that I can't give you a solution, I am stuck by myself with this problem...
Best Regards,
Armin
EDIT 02/04/2012:
I have now - just for curiosity - changed VoIP server using the 3CX software and I am not able to reproduce the problem anymore!!! Maybe there is something in the replies of asterisk that causes the strange behavior! I will now start some wireshark tests to understand the difference between the messages of asterisk and 3CX and keep you updated!