I have developed an Android application that uses a TCP socket connection that listens on and writes to a particular port. My issue is, every time data connection switches to an EDGE connection, the application force closes. I have try catch blocks, none of which throw an exception. Is there a reason why this should happen?
Note: it works fine on other connection types such as HSDPA.
Related
After launching the application, it connection to the server. I am using Socket. TCP connection type. As long as the application is active on the screen, everything is fine. But if the application is moved to the background and the screen turns off, and after a while the connection with the server is lost, then it is impossible to create a connection again. The socket throws an exception:
"Unable to resolve host "m15.cloudmqtt.com": No address associated with hostname".
Where "m15.cloudmqtt.com" is the server name.
But if you take the phone out of the background and open the application, then the connection occurs immediately.
The creation of a socket is implemented using AsyncTask, which is launched from the Service.
Is it possible to solve this problem? I have been looking for various solutions for several days.
I'm developing an app using Ionic Framework and Firebase. I've been reading a lot about the subject (Websockets not reconnecting after Internet connection comes back) and I found that I'm not alone with this issue.
I can create new nodes without internet connection (I put the phone in airplane mode to simulate the lost of the connection), but when the Internet connection comes back, Firebase doesn't synchronize the information.
I suspect that Socket reconnection is the problem because even if I stop using airplane mode the connection never comes back, and the new nodes never syncs.
I've tried Firebase.goOnline() and Firebase.goOffline() with no results or changes in the behavior of the connection status.
in my app I have a service that runs a thread that reads/writes to a BluetoothSocket. If i explicitly close the connection on one device, the other device's thread throws an IOException immediately. This is ideal because I can tell when the connection has been lost.
However, when the devices get extremely far apart (way past the range of bluetooth) the thread does not seem to notice. It throws no exceptions, and seems to be in its normal connected state. The socket is only written to when an sms is received. So perhaps when no sms has been received, no attempts to read/write to the socket have occured, and therefore no exceptions have yet been thrown.
How can I tell when to close the connection if the devices have become too far apart? Perhaps using a timer to periodically attempt to write to the socket would force an exception to be thrown?
Bluetooth tries to maintain connections even when far apart by increasing its transmitter power. Your best bet is to make a timer to see if they are no longer communicating.
I'm currently developping an Android application which connects to a server through TCP. The server is written in Qt and runs on a computer.
In server side, I use a QTcpServer and the signal QTcpServer::newConnection() to get the QTcpSocket newly connected with QTcpServer::nextPendingConnection(). I have implemented a class I called SocketManager, which manages the data received by this socket.
In Android side, I use java Socket to connect to the server.
All work great. When the Android side disconnects from the server, my SocketManager object is well notified and destroys itself. But I would like to manage properly the case when for example the Android device goes to offline or is turned off. In that case, I'm not notified of the disconnection of Android. I connect these signals of my QTcpSocket:
QAbstractSocket::disconnected(),
QAbstractSocket::stateChanged(QAbstractSocket::SocketState)
QAbstractSocket::error(QAbstractSocket::SocketError)
QObject::destroyed(QObject*), thinking that perhaps the QTcpSocket is internally destroyed by the QTcpServer.
But no signal is received when the Android device goes offline or is turned off.
When the QTcpSocket will be released by the QTcpServer? Only when the socket is explicitely disconnected? So in my case, will it never be destroyed? Should I manage the disconnection in all cases in the Android side?
Thanks everyone.
TCP will not notify you of disconnections unless the remote peer explicitly sends disconnect request (by using close() or shutdown() methods) or you try to write to a disconnected socket (in which case you get a broken pipe signal)
The classical way to solve this problem is implementing a heartbeat messaging system where after a certain amount of heartbeat inactivity you close the socket concluding that the remote peer has died suddenly or there is a network problem.
I have a EVO (running Android 2.2) and a Sumsung Intercept (running 2.1). I'm trying create a simple chatting application (similar to the BluetoothChat example) but I cannot get the two handsets to connect. I am able to get them through the discovery process such that each handset is able to discover the other, but when I try to connect I always get a "Service discovery failed" error.
What makes this even more interesting is I'm never able to initiate the connection from the 2.2 -> 2.1 (EVO to the Intercept handsets). But, if the EVO attempts to connect first (which will always get the above referenced error), then I attempt to connect from the Intercept, I will at least get the PIN code / Accept Pairing dialogs on both handsets. But, if I attempt to send anything (the write() method) I will get an error stating the 2 handsets are not connected.
Any help would be greatly appreciated.
One of the handsets has to be a listener (waiting with a bluetooth socket) and the other has to make a connection to the one with the socket.
In other words, you appear to be trying to initiate a connection from both devices while neither one is in a state where it can receive an incoming connection (which is the function of a bluetooth socket).