Is there anyway to run background task on iOS? Like periodically checking some system condition of the phone and report on the widget?
Also, I found that if the iPhone is shut down, then those background task cannot execute again when the phone restart.
The short answer: No.
The long answer is more nuanced, but you shouldn't do it anyway. You can schedule your application for background refresh, but that is unreliable (app will not be run on constant intervals), and if user swipes the app in task switcher, the app will not run at all in the background. Another hacky way is to have a server send a silent push to wake the app more reliably. However this is still not guaranteed to succeed; if user swipes the app in task switcher, your app will not run.
In either case, you cannot trigger widget updates from your app. Widget lifetime is managed by the operating system. Instead, implement widgetPerformUpdate(completionHandler:) and perform your widget updates there. However, as above, this is not a periodic operation.
Related
Imagine i am setting up a location background task, for my iOS app, to track the users location. The user granted my app access to his location "Always". Does this mean, the background tasks runs only when started from the app, until the phone ist shut down, or does this mean, that the location background task is restarted after rebooting the os?
It means you have access to location services even when the app isn't in the foreground. However, you must have some active task such as navigation in process.
The Always API function isn't tantamount to constant background execution.
A task has to belong to a process. If the thread's process does not work, the thread can not work. So, the answer is the first, the background task runs only when started from the app. Because your background task belongs to your app that means your process.
You have to create a system thread if you want it to work even if your process kills. But, most operating systems do not allow the user to do if you do not develop a device driver.
Before asking a question, let me clarify what I understand about iOS App states:
Backgrounded: In this state, your app is not in the foreground anymore but it is still able to run code.
Suspended: Your app enters this state when it’s no longer able to run code.
Now, I wanted to keep downloading going on when App is in background, i.e. it still does exist in multitasking screen. It is working as expected with background transfer service.
But, in some tutorial reference, I have read that you can perform downloading even when App is Backgrounded / Suspended. Can it work even when my App is suspended, i.e. removed from multitasking screen ?
I have been reading many documents including Apple class reference regarding background transfer service with download task, but no one clarifies that the download will not work when App is suspended (killed).
Appreciate your thoughts and advices !!!
If your app has been suspended by the system (without force quiting from multitasking screen) your background session will continue to work.
If you force quit the application all download tasks will be canceled.
The following is from backgroundSessionConfigurationWithIdentifier(_:) documentation :
If an iOS app is terminated by the system and relaunched, the app can use the same identifier to create a new configuration object and session and retrieve the status of transfers that were in progress at the time of termination. This behavior applies only for normal termination of the app by the system. If the user terminates the app from the multitasking screen, the system cancels all of the session’s background transfers. In addition, the system does not automatically relaunch apps that were force quit by the user. The user must explicitly relaunch the app before transfers can begin again.
Apps displayed in the multitasking UI aren’t necessarily executing code or fetching data. Listed apps may be suspended or not running at all
[[UIApplication sharedApplication] applicationState] will check your application state, you can test your app.
NSURLSession class can hand off downloads and uploads to the operating system when the app becomes inactive. As with almost all background execution APIs, if the user force quits from the multitasking UI, the background operation will terminate
In iOS 7, Apple added support for background fetch—a kind of smart, per-app crontab that wakes up at opportunistic times. There is no way to force background fetches to execute at exact intervals. iOS checks how much data and battery power was used during previous background fetches when scheduling future callbacks.
Background fetches can also be triggered by remote push notification and have a very similar delegate method with the same completion handler.
Full Tutorial is here
https://blog.newrelic.com/2016/01/13/ios9-background-execution/
I'm little bit confused with background fetch. I read in Apple Developer documentation that fetch happens when OS decides that it should, user can't control background fetch, while on Apple Developer forum post by Apple employee says that if user kills app (double tap on home and button swipe up) background fetch wont happen, in that case user can control background fetch. So can someone please clarify to me if user kills the app with task manager will background fetch still continue in the background or it's killed at the same time as app.
Apple documentation:
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH4-SW1
From the doc you link:
When a good opportunity arises, the system wakes or launches your app into the background and calls the app delegate’s application:performFetchWithCompletionHandler: method.
So, it seems that the system is able to launch in the background an app that is not running so it executes a background fetch. On the other hand, though, later in the document you can read:
In most cases, the system does not relaunch apps after they are force quit by the user. One exception is location apps, which in iOS 8 and later are relaunched after being force quit by the user. In other cases, though, the user must launch the app explicitly or reboot the device before the app can be launched automatically into the background by the system.
So, Apple's engineer is right: force quitting an app puts it into a sort of special case where background fetches are not allowed anymore.
If the user feels the need to allow background operations, he wouldn't kill the app. But when he kills it, it is only appropriate to disallow background fetch. User can only control if background fetch should happen or not by allowing it to stay in background/by killing the app. But once the app is in background, user cannot control "when" the background fetch happens. The OS determines it based on how free it is.
I think this quote (from the linked document) is the most important for the scenario you're describing:
Once configured, your NSURLSession object seamlessly hands off upload and download tasks to the system at appropriate times. If tasks finish while your app is still running (either in the foreground or the background), the session object notifies its delegate in the usual way. If tasks have not yet finished and the system terminates your app, the system automatically continues managing the tasks in the background. If the user terminates your app, the system cancels any pending tasks.
When iPhone app is in background state or when app is minimized, I want to monitor the duration of time the app is in background and on every regular interval like every 24hrs need to get updates from web server and write the modifications in my local database.
This monitor cycle will repeat as long as app is in background. Is this kind of task is possible in iPhone applications ? Could any body help me how can I perform these tasks when app is in background state ?
beginBackgroundTaskWithExpirationHandler: is the API to make the app in background for long tasks but how long will this support.
Background tasks are killed after 10 minutes time, so to answer your question: No, it's not without faking some kind of long term event handling through a significant location's update, and even then, you have no control over when exactly the events are sent. On the other hand, using APNS to alert the user to a change has the possibility of being ignored, but comes with regularity.
I was trying to run some services in the background so I struck the control in the background by using a while(1) loop in the background delegate for some time.
On the emulator it is working fine but on transfering it to my iPad, the app is crashing after going into the background.
Does the while(1) loop not work for on the device?
On emulator it is working fine but on transfering it to the Ipad device , the app is getting crashed after going in to the background.
If I interpret correctly this that you are writing, what I think is that your app gets killed on iOS devices simply because you are not allowed, except in a few spare cases, to run a thread in your app when the app is "in background" (i.e., after the user has "quit" it by clicking on the home button).
So, if I am right in my reading what is happening, either your app is in a specific class of
apps (see later), or the only thing you can do is "registering" a background thread to run for a limited amount of time after the app goes in the background.
Excerpt from Background Execution and Multitasking
Most apps are moved to the suspended state shortly after entering the background. Only apps that provide important services to the user are allowed to continue running for any amount of time.
As much as possible, you are encouraged to avoid executing in the background and let your app be suspended. If you find you need to perform background tasks, here are some guidelines for when that is appropriate:
You need to implement at least one of several specific user services.
You need to perform a single finite-length task.
You might be especially interested in the "Implementing Long-Running Background Tasks":
For tasks that require more execution time to implement, you must request specific permissions to run them in the background without their being suspended. In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background, such as a music player app
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Newsstand apps that need to download and process new content
Apps that receive regular updates from external accessories