I'm developing an iOS app, using Codename One. I extended the SocketConnection class, in order to receive data from a server.
I tested the app on an iPhone 7s (iOS version 11.2.5 15D60) and it works fine. When I press the home button, the app suspends, but it keeps the connection with the socket server. But when the device goes into standby mode, the socket connection is closed.
Is it possible to avoid this behaviour, in order to keep the socket connected?
Short answer: No and that's a good thing.
Long answer: When an app is suspended in iOS if it uses too much resources the OS kills the app to conserve battery life. Apple does allow some apps in some cases to perform tasks in the background but even then it's under heavy restrictions that are hard to follow and change frequently.
Generally you would define a background behavior that allows you to do something in the background. E.g. in this post we discuss background fetch which allows you to keep polling a server when we are in the background. It might not work with sockets.
The "right thing" in terms of iOS would be suspending your connection when in the background and using push notification to notify the user of a potential update.
Related
Now for those who don't know, can go to https://web.whatsapp.com/ and sync your Whatsapp chats by exchanging a QR code and chat via the web extension of the app.
I am not interested in how they have an initial handshake( might be communicating with whatsapp servers) nor how they sync data so fast for chatting (might be using Open sockets directly from device to client).
I am curious as to how the app works in Background on iOS . AFAIK running a background Intent Service is pretty simple. But not for iOS. iOS allows only up to 30 seconds after the app is shut down normally.
1) I tried crashing the App(swipe up) (Still the web version was running normally)
2) I disabled Background App refresh the web version didn't stop.
3) Even disable Notifications still the web version worked normally.
4) As well they do not have a Blue bar the likes when Google Maps is giving you directions that indicates the app is running in BG
5) Are they using Dummy Geo Fencing to keep them alive? (but that d require BG App Refresh too)
Is it some new feature on iOS 8 that was introduced and I am not aware of
Just as a side note, Apple introduced the Notification Service extension point in iOS 10, which can be used to achieve this. The following applies only to iOS 9.x or earlier.
No app in iOS can be long alive in background with a keep-alive socket, or
guaranteed to wake by remote notifications except those using VoIP background mode (OT: and IIRC Bluetooth background modes).
An app has only ~5 seconds of runtime on applicationDidEnterBackground: after being put in background, unless it is registered for any background modes or tasks. The app would be terminated if it runs out of time in this delegate method.
The background task model mentioned by #xoail has a app-specific, system-imposed time limit (up to 30 seconds...?) and cannot be extended. It is for an app to complete its current work, e.g. uploading a media, before being suspended. Background Transfer Service, since iOS 7.0, is an alternative for long running file transfer.
Silent Remote Notificaiton is observed to be triggered consistently only on charger and Wi-Fi, but always throttled by iOS otherwise. So it is sort of indeterministic - let alone the fact that this can be switched off by flipping the app's Background App Refresh switch.
VoIP background mode (in iOS 8 and later) guarantees to call the app's handler when a VoIP notification is received from APNs. But App Review Guidelines states clearly that background modes should only be used for their intended purpose.
So either Apple waives WhatsApp the use of VoIP background mode for purpose other than WhatsApp Call, or WhatsApp happens to get away from the "use your phone to sync" architecture and does something new for the iPhones.
As per the docs the app can remain in the background performing finite updates to the App. You can continue extending the background process one after the other. Look into Perform finite-length tasks. I think killing the app from background still executes registered actions by the system.
Whatsapp does some clever web session token + background app token generation to keep session valid.
As mentioned in #32112433 by Steven Darbey this is most likely implemented using the new iOS 8 PushKit Service which includes a VoIP service notification type, allowing applications to resume from background. A misuse of the API for non-VoIP purposes, but Apple apparently putting a blind eye on it.
https://developer.apple.com/library/prerelease/ios/documentation/Performance/Conceptual/EnergyGuide-iOS/OptimizeVoIP.html
NOTE: This app I am working on is completely for my own usage and will not be on app store so please don't give answers referring that.
I want my app to do some process in background or after termination (double tap the home button and swipe the app from applications multitask) every few minutes. The process is very very light and quick so it won't drain the battery. This process shouldn't require internet connection. I have seen some answers here like and I will explain what are the problems:
VoIP. The problem with VoIP is wither it should be in background to use UIApplication.sharedApplication().setKeepAliveTimeout(..) method which doesn't work when the app is terminated or it should be connected to the internet to establish tcp connection and receive commands from sever and as mentioned before I want it to be internet independent.
Location Services. I found this excellent site with some great articles but the problem is it only works when the mobile phone is moved more than 500 meters. It depends on the location movement so when the phone is staying somewhere there will be no code execution.
Playing an silent audio loop. The problem here is if the user plays another audio (which is completely possible like music or phone call) the app will terminate!
Jailbreak Launch Daemons. I can't require jailbreak so it should be solved with a non-jailbreak solution:(.
I am free to use any kind of private-API's and there will be no restriction for that.
Thanks in advanced
I also faced with such problem, and don't find any solution.
The main problem is if user manually terminated app - in this case you can't do nothing...
Only way is:
a) use Location Services (as you mention)
b) use Push Notifications with background fetch
I am working on Poker app based on server-client based app. When Poker App goes to the background after some time TCP/IP connection lost because app unable to send/recieve any packet to/from the server. Sever ends socket connection. how can i able to establish connection for long time and update my game UI
The topic you asked for, is called "Background Execution".
First:
You can't update the UI while the app enters the background. But you will be able to finish your API-Requests to the server and save the data on phone while using beginBackgroundTaskWithExpirationHandler. You can use this method to write a block which communicates to your server and handles all the data your app will receive. If the App enters the foreground again, you can use this data received in background to update your UI then.
It is important, that those background tasks have to finish in a short time, so it will be not a good idea here to have an infinite loop. Otherwise, iOS will terminate your process. How much time you really get after your app gets backgrounded is determined by iOS.
Second:
If you want to keep tcp/ip-connections always on even if the app remains in the background, Apple provides a very powerful background mode which enables you to run code for any time in the background. It's called VoIP-Services. Unfortunately your app should provide some VoIP-Stuff to not being rejected by Apple. Here is a good article about those services.
I have a voip app, but it won't wake up from standby mode when a call comes in. The docs say the following:
There are several requirements for implementing a VoIP app:
1. Enable the Voice over IP background mode for your app. (Because VoIP
apps involve audio content, it is recommended that you also enable
the Audio and AirPlay background mode.) You enable background modes
in the Capabilities tab of your Xcode project.
// I did this using the "capabilities" tab in the project's settings.
// I have "audio and airplay", "voice over ip",
// "background fetch" and "remote notifications" checked.
2. Configure one of the app’s sockets for VoIP usage.
// I have 2 sockets, one for sending stuff to the server that closes after sending.
// One socket that stays alive all the time, which is used to
// receive stuff from the server.
// The one that stays alive is configured as voip*.
3. Before moving to the background, call the
setKeepAliveTimeout:handler: method to install a handler to be
executed periodically. Your app can use this handler to maintain its
service connection.
// I did this and in the handler I send a login message to the server,
// On the server side it's detected that the account is already logged in so
// it refreshes the connection instead.
4. Configure your audio session to handle transitions to and from active use.
// I did not do this yet, I might in the future.
5. To ensure a better user experience on iPhone, use the Core Telephony
framework to adjust your behavior in relation to cell-based phone
calls; see Core Telephony Framework Reference.
// I did not do this and probably never will (company's decision, not mine).
6. To ensure good performance for your VoIP app, use the System
Configuration framework to detect network changes and allow your app
to sleep as much as possible.
// I don't do this yet, but will implement it once all the basics run fine.
When a call comes in I create a local notification to let the user know about the call. When the app is minimized this works fine, but when the device is in standby (sleep) there is no notification. When I wake the device from standby, the notification pops up after a few seconds (so it's not already there, it really appears after waking up the device).
I created more voip apps in the past, and I can't remember ever having trouble with this. I'm running ios 8 now, perhaps I have to do some more to make it work while in standby? Are there more requirements for voip now? Or am I missing something stupid?
Note: I know about push notifications. They are an option (in fact, I already tested and they make it work), but I'd rather not be dependent on the apns.
I just spent two full days troubleshooting a similar problem. An iPhone 6+ worked properly but neither of two iPhone 6's did. To make a long story short, SIP packets were not being transmitted reliably. I pinged the VOIP servers offered me and found that I was using one with a latency of 30 milliseconds but one with 15 milliseconds' latency was available, so I tried switching servers. That did the trick.
Be aware that if the user closes the App manually (double click home button, swipe up) your application will not be able to run in the background until the user manually opens it up.
However, the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.
Check it here.
Here is my scenario ..
I have a device that advertises dynamic data per BLE protocol. There are multiple such devices operating for a user
Questions -
1) Can IOS scan such constantly changing advertising data or does it expect advertising packets to be pretty static?
2) Can we create a service that scans for such packets periodically - maybe 30s every 5 minutes?
3) Can such a service be automatically restarted during bootup without user intervention?
You cannot create a service on a normal (non-jailbroken) phone. Isn't even possible to distribute something like that (read the app review guidelines). Sure, you can scan for BLE data on whatever interval you want, but your app needs to be active, or it needs to be doing something approved by Apple for making connections to BLE devices in the background. Just be aware that like any other background app, iOS might suspend or terminate your app at any time, and there's nothing you can do about it.
What you have described is covered by the standard BLE background mode - it is covered in the Core Bluetooth programming guide.
You can set up a scan for specific service UUIDs and this will continue in the background. Your app will be launched into the background when a device is discovered.
The exact scheduling of the notification can't be controlled - but in my experience you are notified pretty much as soon as a new peripheral is discovered. Once you have discovered a device you can even initiate a connection as soon as it disconnects (ie goes out of range) - iOS will automatically reconnect to the device when it comes back into range
In order for the scan or pending connection to survive across reboots you must configure state restoration. This is also covered in the Core Bluetooth Programming Guide.