I have a navigation application that works with both CoreLocation (Backgrounding mode Location updates) as well as GPS data provided over a UDP connection from an external sensor.
I've noticed that when I background the app the socket goes down (which likely makes sense).
What is the procedure to keep the socket open in backgorunding?
Idea
I thought perhaps to register as a VoIP app - would keep the socket open but it looks like that works differently now.
The documentation suggest implementing setKeepAliveTimeout:handler: but this appears to be deprecated.
I'm not sure exactly how to proceed. Any ideas? The best I can come up with is a hack to have my location-update handler run a check on the socket so see if there is new data - but I'm assume there is a legitimate way to do this.
When the phone goes in stand-by all the UDP socket are closed and only TCP connection can be used. Yes probably with VOIP app you can use the UDP but in that case your app will be reject because your don't use a real VOIP service. I had the same problem ... In my case, even if the phone is in background, I want to send UDP message to a domotic system but is not possible.
Related
The iOS APIs allow me to open listening sockets for example using the ServerSocket class, however if my App is not in the foreground I assume I won't receive any requests sent to the socket. Is there a way I can keep the listening socket open in the background? Thanks!
Having researched this further I am now convinced that listening sockets on iOS in most circumstances are only useful if your app is the foreground.
The only methods I have found that allow a persistent listening socket in the background abuse other parts of the API e.g. location API so are not suitable for anything beyond an academic demonstration of the capability.
Apologizing in advance, I am no 802.11 expert and this is a long winded question...
I am working on an iOS voip client, we use the Cocoaasyncsocket library for our TCP/UDP connections. The app/iDevice is allowed to roam in/out of wifi coverage (for the purposes of this discussion we will assume the app is using wifi only... no cellular connection). We have the appropriate plist settings for backgroundmode (voip, audio) as well as requiring persistent wifi.
We are having a problem that seems particular to Cisco AP's. With the client app in the foreground and roaming out and in of wifi range, we noticed that eventually the iOS device will eventually not automatically rejoin the network. After a great deal of debug the failure to rejoin was noted to have nothing to do with the app. The failure to re-join can ultimately be reproduced by forcing the AP (via config) to deauthenticate the iDevice three times. After the 1st and 2nd deauthentications, the iDevice readily automatically re-joins. But after the 3rd time, iOS does not automatically rejoin the network.
The network will be rejoined if, for example, the iOS email app is put in the foreground.
We were curious if any other VOIP type apps suffered this problem, and ran an experiment with running FaceTime and Skype on the iOS device.
Skype behaved much like our voip app, after the 3rd deauth the connection was lost. Trying to initiate another call resulted in a message to the effect of "must have an internet connection to make a call".
FaceTime did disconnect on the 3rd deauth and failed to automatically rejoin... however, we were able to re-initiate another FaceTime call which caused iOS to rejoin the network and make the call.
We would like to emulate the FaceTime behavior, but so far do not understand what we should be doing differently. To the best of our knowledge, we are properly closing the open sockets when we get disconnected. Is anyone familiar with this issue and have some insight to offer?
I've searched the web extensively but haven't found a good answer to this.
Im writing a socket based application in C++ using posix sockets on iOS/Android.
When switching from wifi->3g, SOMETIMES the socket goes dead without giving any errors when reading/writing.
I can use the reachability API on iOS (and similar on android) to detect when the network switches.
I am destroying/recreating the socket when this occurs. The problem is if the socket is alive, the server will receive the signal when I close the socket. If the server receives the close signal, it will assume the client disconnected intentionally and notify others about this, which is not what I want. If the socket is dead, the server doesn't receive this signal and everything is OK.
How do other people handle this scenario? I really don't want to use a timeout to detect this.
Why does it only sometimes die too? And how can I tell the socket is actually dead?
Just to close this issue, this is the approach I'm taking.
When switching networks, I'm sending a ping-and-reconnect packet to the server, AND creating a new socket.
Which ever responds first, I close the other connection.
Required a bit of server side changes to handle this correctly too
I am designing an app that needs to exchange data in real time over network and I am planning to use socket connection to achieve this. To keep the socket connection open in background I plan to declare my app as a VOIP app (I already know apple's rule prohibiting this and willing to take the risk), and use keepAliveTimeout to keep connections alive.
Now can I declare and own a socket which will listen to any incoming data or I have to use an existing/specific socket given by Apple? Also is the port unique per app or per phone? Means if my app is continuing in background and also a call comes over Skype would they interfere with each other?
Thanks in advance for response. Help would be appreciated.
I am trying to implement an iOS VOIP application.
I am using GCDAsyncSocket to listen on a port for connections. I did add the required background modes in info.plist and also registered the readstream and writestream to kcfNetworkServiceTypeVOIP.
I also added KeepAliveTimeOutHandler to wake up the app. The handler block just prints the wake up time to stdout.
As long as app is in foreground new connections are accepted but when the app is in background, the app is not waken and all the connections attempted are sent to the socket when the app moves to foreground again.
I searched through many solutions but could not get it to work.
Thanks in advance.
I am not sure if it is still relevant for you but in case someone else reads this question.
As discussed in other similar question on stackoverflow in this one for example you can have only one socket which is in NetworkServiceTypeVOIP mode. Otherwise both of them will not work and your app will not wake up and not accept new connections.