I have a web app that is now being used in an Android app by launching it in a webview. Most of the Android functionality is native & the webview part is mainly just for communication via socket.io
It all works okay but as soon as the phone goes to sleep it kills the socket connection after a few minutes. This connection is used for incoming messaging so I need the connection to stay alive.
I tried creating a foreground service and using it as a keep-alive but since the socket connection is in the webview, it still gets closed no matter what I do i.e. the service stays alive and I can make a new network connection, but I can't keep the existing app connection alive.
Is there a way to keep a webview socket connection alive when the phone dozes? Am I doing something wrong? Or is my design flawed and I need a different approach?
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 am creating an Android application with Socket IO
But I checked from log, the socket is not disconnected when app go to background, I don't need to use socket when app is in background. So, is it correct? Does it drain battery much when socket still works in background?
If I want to force disconnect socket in background, how can I do it?
Thanks for reading this
Situation:
I'm developing an Android app using a socket for communication with a server via the websocket protocol.
The starting point to open the socket is a Service started from the application context. Opening and communicating with the server works fine.
Problem / Question:
The socket is not closed, when the device is going in mode SCREEN_OFF.
So my question / concern is, what is really going on with my process when the device is in such power state? Should i react and close the socket to save battery? The websocket is also using ping/pong mechanism to keep the connection alive. So if the system never "stops" my process i will always communicate until the battery is down or the OS kills my app?
Or am i understanding something wrong?
When device go in sleep mode, you have to close all service, thread to save battery.
i'm writing a client-server application which uses TCP socket connection. In my android project, Service creates a thread for listening the TCP socket.
Everything seems OK. But i have got one problem.. My network service running in background fine; But some time later (10-15 min..), when i try to open my application (main activity) again, I can't get responses from the socket connection. It freezes or something?? i cant send or get TCP messages from the socket.. What can be the reason of this? I'm working on my phone, via 3G connection.
(Besides, the app running in the emulator hasn't got such this problem; I assume Its connection is stable, long-during )
Thank you for your answering.
Due to power optimizations and perhaps changes in connectivity (GPRS/HSDPA/Wifi) it's very likely your connection is being dropped.
In order to maintain a connection, your background service needs to claim a wakelock using the PowerManager class. This prevents the device from going to power-saving mode and thus disconnecting your socket. But beware, this significantly lowers the battery life of the device.
Also, you need to handle changes in connectivity which break your open connection. Android sends out a broadcast message named android.net.conn.CONNECTIVITY_CHANGE to notify of changes in connectivity.
Depending on your use-case I would poll with when the device is in the sleep-mode and only build a connection when the device is actively in use or just use C2DM push notifications
When I have experienced something like this in my apps, it has usually been because of power optimisations on the phone (which cant be overridden). If the socket has been idle for too long, it is automatically closed and needs to be reopened.
Are you sending data from time to time? Like implementing a heartbeat protocol ? if you are not, you should...or maybe it has to do with socket READ/WRITE TIMEOUT
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.