I have a custom framework which the client app can consume. I want the framework API's to run even when the application enters the background. How can I achieve this?
Thanks in advance.
It depends on what your app is doing after entering the background.
Perhaps you are looking for UIBackgroundTask. You can take a look at the method beginBackgroundTaskWithExpirationHandler: of UIApplication.
This method lets your app continue to run for a period of time after it transitions to the background. You should call this method at times where leaving a task unfinished might be detrimental to your app’s user experience. For example, your app could call this method to ensure that had enough time to transfer an important file to a remote server or at least attempt to make the transfer and note any errors. You should not use this method simply to keep your app running after it moves to the background.
Background execution on iOS is a very advanced topic.
Without any details, all I can do is forward you to the official Apple documentation.
This explains ALL possible modes that allow your app to run in background.
Related
What are the different options for running code on an iOS device at a specified time while the app is in the background? So far I have found that I could possibly use a Timer object, use the Grand Central Dispatch timer, and use CloudKit Push Notification with the Apple Push Notification service.
Any ideas are welcome. I'm having a hard time finding the solution.
Here is the apple documentation for background execution.
Here is the apple documentation for the execution states of an application.
You should understand a few things:
When an app moves into the background you have a very small amount of time (3 minutes approximately) to execute finite-length tasks.
If your application is not running, you could use a notification to wake the application. This requires the user to take an action and will make the application active.
You can also wake an application with a local notification, it doesn't have to be a remote notification.
The code that you want to run really needs to fall into one of the blessed scenarios that apple defines otherwise you run the risk of being deprioritized or ignored entirely.
A block of code scheduled to run with a Timer or GCD will not be invoked while the application is in the background.
Roughly, you should register a background execution mode and follow the guidelines I linked above and while your application is backgrounded the application will be given time to execute code.
I’m building a content blocker app for iOS.
Is there any way I can update the blockerList.json file from a server periodically in the background?
I have no idea how to do this, or even where to start.
If, and only if, a background task improves user experience you can declare an iOS app to have a task that runs in the "background". That is, even when another app is in the foreground, your app could potentially perform tasks "in the background".
However, be very picky about that requirement - often enough, it's not really necessary to do this. In your case for example, you could load the list when your app will move to the foreground, and then periodically while it is in the foreground. Doing things in the background when it is not really necessary will drain battery for nothing - one of the bad habits users hate the most!
Well, lets assume you have good reasons for doing it anyway ;)
An iOS app which has not declared such kind of background task will stop executing shortly after it ceases to run in the foreground. In order to support apps that really have to do something in the background - that is, when this app is not in the foreground - there are a couple of certain "background execution modes" (UIBackgroundModes) which can be used to declare that your app wants to execute such kind of task in the background.
So, the first is to find an appropriate "background execution mode" suitable for your background task and declare that in the Info.plist of your app. (In your case, the suitable mode would be fetch: "The app regularly downloads and processes small amounts of content from the network.")
The next thing is to implement the task and the necessary hooks (uhm, I mean delegates), that is in your case you need to implement application:performFetchWithCompletionHandler. You also need to deal with the "application state transitions".
Here are a few pointers to the Apple docs: https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplicationDelegate_Protocol/
And here is a tutorial: http://hayageek.com/ios-background-fetch/
I am currently implementing the delegation in IOS.
But when I put a breakpoint in the XCode and I do some thing which is going to respond back after fe seconds like HTTP request
Then I am checking invoking the delegate method.
But the break point is reached, but it reached only if I restore the application from background. Even sometimes the NSLog is alos not printing when the app in background.
Is this a default behaviour of XCode, can anyone please help me on this
Can we say no normal method calling functionality will work in a background app?
If you need your app to continue operating after being sent to background (your HTTP or network transactions), then you need to execute those operations as a Background task from the beginning. Look at:
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
Table 3-1 on this page shows the various background modes you can register for:
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH4-SW23
While it's possible to register for one of the background modes, just for the sake of being able to du background stuff, it's highly discouraged as Apple might reject the app if you register some background mode that is not necessary for the purpose of your app.
Not knowing exactly what you need, maybe "Background fetch" could solve your problem, since you mention HTTP request?
I'm writing a iOS/Swift application which reads data from a REST service each X minutes and updates the UI accordingly.
Now I would like that when the app is put in the background, a task keeps being invoked at X minutes intervals reading from the REST service and, in case the data just read satisfies a given condition, show a notification prompting the user to bring the app back to the foreground.
In my searches I've read that during applicationDidEnterBackground event, I should start a task with beginBackgroundTaskWithExpirationHandler.
The problem is that, if I've understood correctly, this allows a maximum of 10/15 minutes after which the app is terminated if the task is not stopped with endBackgroundUpdateTask, while I want the task to keep polling the service indefinitely (at least until the user disable it from the app's settings)
My question is:
How is this kind of functionality performed normally? Do some common solutions or best practices exist for the solution of such a problem?
Use iOS Background Fetch feature where you can specify minimum background fetch interval. But actual interval between successive invocation of your code will be determined by iOS framework. For details checkout this link: http://code.tutsplus.com/tutorials/ios-7-sdk-working-with-background-fetch--mobile-20520
I use this approach in my app and I think it is a preferred way of doing.
You can use a local notification that can be presented from the background in case your condition is met.
Correct, iOS will eventually shut down the background process, you can't enforce continuous background activity. Use the backgroundTimeRemaining property to check how much time your application has left and try to handle it as gracefully as possible by calling endBackgroundTask so that iOS does not force kill your app.
As a solution, you could think about using remote notifications with with content-available : YES, which runs the didReceiveRemoteNotification
Have a look at the Parse.com Their local datastore is an abstraction for what you are trying to acheive.
By the way, is it really necessary to refresh in the background. If call is relatively quick, there is no need to refresh until the user open's the app. Background processes like that, using the net can be quite battery consuming when the user are not on a Wifi. So consider the use case carefully!
I know that iOS has its own task management method and users may never need to care about the processes background. But my requirement is to ALWAYS keep a program alive, it cannot be killed under any circumstance.
Is there a way to do this like "LOCK" or something else function already existed? I'm using iPad4 ios6.01 system.
Thanks
No, that's not possible. (Nor should it be if you think about it. What's to stop every app from saying that it can't be killed?)
The closest you can get is for things like VoIP apps that do run in the background and automatically respawn when they die.
The alternative is to work like every other app: when your app goes into the background you save state so you can restore if it gets killed. iOS 6 even has the state restoration functions.
Short and simple
No, there is no way to make your App "unkillable".
A bit longer
If your App requires to receive location updates while it is running in background, you can use the standard way Apple offers to do so.
Two other options are: your App is an VoIP application (afaik they also get autostarted on system boot) or you're playing audio in the background. Without knowing too much details about how iOS handles such Apps, they might get killed if the iDevice runs out of memory (or the user kills it). But you probably already knew that.
However, as you already mentioned, iOS manages everything on it's own and will kill Apps that run in background to free memory. Additionally as we all know, a user might kill your App at any time using the task switcher of iOS.
And don't try to use the described methods just to run tasks in the background. If Apple finds out about it, your App will be rejected/removed from the App Store quickly.