Lets say i have an client application on iOS which is connected to a server using a C socket.
I receive and send data on this socket.
Now the user closes the App, so something else (let's say check his mail) and returns to the application.
My (bundle of) question(s):
What to do with the socket connection?
Should you close it and try to reopen the socket when relaunching the application?
Or can i leave the socket open? If so, what happens with the data which is received on the connection?
Other situations to consider are:
I do not know when the user returns to the application.
I do not know if the user stays in the same network.
Thanks
The connection should be closed and the received data saved [if necessary], when the application is about to 'resign active'.
The connection would not be able to run in the background. And you will not receive any data in the background.
When the application resumes from the background reopen the connection and continue.
These methods will help you keep track of your application's state
– applicationWillResignActive:
– applicationDidEnterBackground:
– applicationWillEnterForeground:
I would close the connection and open a new after the app comes to focus. I wrote an app some months ago where the app talked to a radiostation playoutserver to display some information.
- you don't know how long the app stays in background
- you don't know if the user stays within the same network
- you don't know if the user forgets about the still in background living app
...
i would vote for closing the socket connection.
Related
I am using an implementation of https://github.com/webrtc for my app. I have a networking stack implemented that uses WebRTC. The issue I am seeing is that when the client exits the app it closes the PeerConnection object, and the server gets a state change from kIceConnectionConnected to kIceConnectionDisconnected which is good and all but I would expect to see kIceConnectionClosed. The problem with the disconnected state is that if your network is spotty then you can intermittently get kIceConnectionDisconnected state which may heal itself afterward. And I don't want to close the connection.
The question is: how do I as a server guarantee that the client has quit the app and that I can tier down the connection on the server side right away?
Edit:
According to https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-data-channel-13#section-6.7
there should be a channel reset that happens on both sides, how would server knows that it needs to reset the channel?
I'm using react native android and want to ask if there's any way to have mqtt connection with background service so that when the app closes I can still receive messages via mqtt?
I have not done this myself, but this should be somewhat possible. While I do not know if it is possible to leave a single connection open that will receive MQTT messages regardless if the app is running in the foreground, running in the background, or has run and closed, I do think that effect can be achieved.
Background tasks (run when the app is in the background or has been closed) do not always work cross-platform (mostly Android-only), and do not allow you to run on an event-based trigger like receiving an MQTT publish. For this reason, you will see my suggestions based on things like setInterval and checking for messages at a given point. Because the connection is not alive at all times, you will have to either set a large keep-alive interval (or unclean sessions) on the MQTT connection to match with the interval you are checking for messages and rely on QoS 1 or 2 (harder), or close and re-open MQTT connections and rely on retain (easier).
If you only need the MQTT messages to get through when the application is in the foreground or background, you can use something like https://github.com/ocetnik/react-native-background-timer to setInterval and wake-up to check for messages at specific intervals that have tight granularity. If you need the messages to get through even when the app has been closed, you require something like https://github.com/vikeri/react-native-background-job , which will only allow you to run code at a granularity of 15 minutes and above.
I wish you the best of luck!
I have created a web-service app and i want to populate my view controllers according to the response i fetch(via GET) in main thread. But i want to create a scheduled timer which will go and control my server, if there becomes any difference(let's say if the count of an array has changed) i will create a local notification. As far as i read from here and some google results, i cant run my app in background more then ten minutes expect from some special situations(Audio, Vo-IP, GPS).. But i need to control the server at least one per minute.. Can anyone offer some idea-or link please?
EDIT
I will not sell the app in store, just for a local area network. Let's say, from the server i will send some text messages to the users and if a new message comes, the count of messages array will increment, in this situation i will create a notification. I need to keep this 'controlling' routing alive forever, whether in foreground or background. Does GCD give such a solution do anyone have any idea?
Just simply play a mute audio file in loop in the background, OR, ping the user's location in the background. Yes, that will drain the battery a bit, but it's a simple hack for in-home applications. Just remember to enable the background types in your Info.plist!
Note: "[...] I fetch (via GET) in main thread." This is not a good approach. You should never fetch any network resources on the main thread. Why? Because your GUI, which is maintained by the main thread, will become unresponsive whenever a fetch isn't instantaneous. Any lag spike on the network results in a less than desirable user experience.
Answer: Aside from the listed special situations, you can't run background apps. The way I see it:
Don't put the app in the background. (crappy solution)
Try putting another "entity" between the app and the "server". I don't know why you "need to control the server at least one per minute" but perhaps you can delegate this "control" to another process outside the device?
.
iOS app -> some form of proxy server -> server which requires
"babysitting" every minute.
I need to connect an iOS Device to a computer/mac. It's necessary to take this connection alive, even if the app goes in background mode. I know that the normal life cycle of a multitasking app will cut the connection at unknown time. Now my idea was to declare the app as an VOIP-App, so that I can use the SignOfLive to send signal to the PC. Is that possible?
Please note that I'm only asking if it's possible, not if apple would like this way ;)
Sure it's possible to set any app as a VoIP app and enable keep-alives. But, Apple will reject the app and the keep-alive trigger interval has a 600 second minimum and can only run for 30-seconds.
The keep-alive is limited and is really intended for sending SIP registrations.
Why don't you describe what you are trying to accomplish and someone may be able to offer a better solution?
The voip setting will also allow the app to listen for network traffic, while in the background. Or, if you just need to be able to have a network process finish, any app can continue to run in the background for up to 10 minutes.
I want to send data to my web server while the app is closed. Is that possible? I've read I can send the position, but I waant to send some id of the phone too.
If it's not possible to have the app running, could I at least communicate with it from my server and then do stuff in the background?
Thanks
When the app goes into the background the applicationDidEnterBackground method on your App Delegate will get called.
In that method you can use the beginBackgroundTaskWithExpirationHandler on UIApplication object to start background processing.
Just realise that you don't get forever to perform tasks in the background. You can find out how long you have left by reading the backgroundTimeRemaining property in UIApplication if you need to know if you're running out of time.
If your processing is short you should be fine, but remember if your processing requires network access then you can't be sure how long that will take.