I am a bit confused with how performFetchWithcompletionHandler engaged with the iOS app life cycle. In the docs it's mentioned that it gives us 30 seconds to download any data but will our app freeze for 30 seconds at that time?
... will our app freeze for 30 seconds at that time?
No, the exact opposite. This method is called when your app is suspended, but the OS is going to let you check for data to retrieve. So, your app will be awaken, run in background, and this method will be called, at which point you can perform your quick fetch (not more than 30 seconds) to see if there is any data to retrieve. When you’re done processing your quick fetch, you call the completion handler to let the OS know that you’re done and that your app can safely be suspended again.
If, though, you fail to complete your request in 30 seconds, your app may be summarily terminated and not participate in future background fetches. So it’s important to finish in the allotted time.
As the docs say:
Implement this method if your app supports the fetch background mode. When an opportunity arises to download data, the system calls this method to give your app a chance to download any data it needs. Your implementation of this method should download the data, prepare that data for use, and call the block in the completionHandler parameter.
When this method is called, your app has up to 30 seconds of wall-clock time to perform the download operation and call the specified completion handler block. In practice, your app should call the completion handler block as soon as possible after downloading the needed data. If you do not call the completion handler in time, your app is terminated. More importantly, the system uses the elapsed time to calculate power usage and data costs for your app’s background downloads. If your app takes a long time to call the completion handler, it may be given fewer future opportunities to fetch data in the future. For more information about supporting background fetch operations, see Background Execution in App Programming Guide for iOS.
This is regarding background fetch, like when an app receive silent notifications. In this case, iOS wakes up an application in background for max 30 sec. and do the stuff as per writer code and the kill the app. So user will be unaware of this.
It is not recommended to write complex logic in this method performFetchWithcompletionHandler. The reason is the time limit(30 sec.) and the app developer doesn't have a control over it.
To get this work, background mode should be enabled in capabilities of project.
One of the example about this is silent push notification (notification payload has the key content-available = 1)
For more details see this
Related
HKObserverQuery has the following method that supports receiving updates in the background:
- initWithSampleType:predicate:updateHandler:
The updateHandler has a completionHandler which has the following documentation:
This block is passed to the update handler. You must call this block
as soon as you are done processing the incoming data. Calling this
block tells HealthKit that you have successfully received the
background data. If you do not call this block, HealthKit continues to
attempt to launch your app using a backoff algorithm. If your app
fails to respond three times, HealthKit assumes that your app cannot
receive data, and stops sending you background updates.
From looking at other posts it seems like there's a lot of confusion revolving around this handler. Below are some questions that I have about it:
When should the handler be called? If called too late, then HK might think that the app never received the query update causing you to hit the background update 3-strikes back-off algorithm. The documentation states that it should be called after handling other queries. Depending on how long it would take to run those queries, it sounds like you could get dangerously close to hitting the background update strikes.
Why is this needed? Shouldn't the system know that the app has been launched and has received the background update? When using CoreBluetooth in the background it just wakes your app up in the background for 10 seconds. No need to call any handler or deal with the background update 3-strikes.
If you hit the background update 3-strikes and HK stops sending updates is that permanent? Does HK ever start sending the background updates again? What if there's a bug that prevented the handler to be called and now you've fixed it. Is the app stuck never receiving the updates? Or will it reset when the app is re-launched or updated?
Does HK keep your app running in the background until the handler is called? Is that part of its purpose or just a side effect? If it's part of its purpose how long can we run before needing to stop (and hit the first background update strike)?
When should the handler be called?
Call it after you are done your job. Your code should not do complex operations. The app is in the background and the user does not see what's changed. You can just set a "flag" that data is updated and do complex operations after the user launched the app. If your decision about either notifies the user or not based on complex operations, then try to refactor code so that all necessary data is pre-calculated (e.g. in UserDefaults) and extra data is simply fetched with that data. So, 1-2 seconds is enough for your calculation.
Why is this needed?
All such handlers have completion closures. They are needed for iOS to know if your app works fine. If your app will eat too much CPU time, then iOS could become slow. Hence, Apple wants to be sure that iOS works fine despite bad apps.
If you hit the background update 3-strikes and HK stops sending updates is that permanent?
No.
Does HK ever start sending the background updates again?
Yes. But it depends on many factors. It may try to call your app again in 1-2 days. If nothing changes it will call it rarely.
Does HK keep your app running in the background until the handler is called?
This is unknown. It depends on many factors. Probably if iPhone is charging it will allow running your app longer just to estimate if the completion handle is called or not. If your iPhone is not charging and closed to 0% battery, then more likely iOS will kill your app. So, you should not do any job after you called the completion handler. And try to keep it simple.
Recommendations
You should process new data as quickly as possible. If you need to fetch a lot of data, then try to optimize this and pre-calculate it when the app is in foreground, then save somewhere (UserDefault), and use new data with cached data to make a decision (e.g. notify user about something; I believe you need background updates exactly for that).
1-2 seconds or less is a good time for background updates.
just wondering what will happen after performFetchWithCompletionHandler, will my app stay in the memory, or will it get purged immediately? I've googled but no one seems to be caring about this.
When this method is called, your app has up to 30 seconds of wall-clock time to perform the download operation and call the specified completion handler block. In practice, your app should call the completion handler block as soon as possible after downloading the needed data. If you do not call the completion handler in time, your app is terminated. More importantly, the system uses the elapsed time to calculate power usage and data costs for your app’s background downloads. If your app takes a long time to call the completion handler, it may be given fewer future opportunities to fetch data in the future.
Straight from Apple documentation - UIApplication Delegate
iOS 7+, 8 (last one not released yet, however targeting on it).
The app.
As a user I start the app and switch to other apps (mail, safari, etc.), leaving the app running but not a foreground one.
The app establishes HTTP connection to server via Internet and starts periodically sending GPS location data to the server (with some interval).
Is it possible while the app is not on the foreground? I mean is it possible to get geolocation data and periodically send it from the app to the server via HTTP POST while using other apps?
If the answer is "YES", please help me with references. I will investigate it further.
Yes, and the method you want to research is performFetchWithCompletionHandler:
Implement this method if your app supports the fetch background mode.
When an opportunity arises to download data, the system calls this
method to give your app a chance to download any data it needs. Your
implementation of this method should download the data, prepare that
data for use, and call the block in the completionHandler parameter.
When this method is called, your app has up to 30 seconds of
wall-clock time to perform the download operation and call the
specified completion handler block. In practice, your app should call
the completion handler block as soon as possible after downloading the
needed data. If you do not call the completion handler in time, your
app is terminated. More importantly, the system uses the elapsed time
to calculate power usage and data costs for your app’s background
downloads. If your app takes a long time to call the completion
handler, it may be given fewer future opportunities to fetch data in
the future. For more information about supporting background fetch
operations, see “App States and Multitasking” in iOS App Programming
Guide.
https://developer.apple.com/library/ios/documentation/uikit/reference/uiapplicationdelegate_protocol/Reference/Reference.html#//apple_ref/occ/intfm/UIApplicationDelegate/application:performFetchWithCompletionHandler:
Just as Mike mentioned, you should look into background fetch. For more details, checkout this objc.io post.
The information you need should be in the Background Fetch section.
After your application completes its actions during a background fetch you must call the completionHandler block with one of the three UIBackgroundFetchResult states: UIBackgroundFetchResultNoData, UIBackgroundFetchResultNewData, or UIBackgroundFetchResultFailed.
How are each of these three results handled by the OS once the completion handler is called?
From the iOS App App Programming guide:
When the application:performFetchWithCompletionHandler: method of your delegate is called, use that method to check for new content and to download that content if it is available. When your downloads are complete, execute the provided completion handler block, passing a result that indicates whether content was available. Executing this block tells the system that it can move your app back to the suspended state and evaluate its power usage. Apps that download small amounts of content quickly and accurately reflect when they had content to download are more likely to receive execution time in the future than apps that take longer to download their content
They don't give us so many details, but I think is clear enough: you pass the result of the fetch to the System, so it can decide when to give background execution time (and how much).
Example, consider two different apps:
- one downloads files that are updated every night
- the other downloads files that are updated more frequently, many times in a day
In both cases, the system will wake up your app, takes note of the start time, your app starts the download and then tells the system that there was or not content available.
After some time, you'll see that the system will wake up the first app less frequently than the second one, optimizing battery consumption.
Moreover, if you use NSURLSession to start you download, the system will evaluate your app's power consumption (since using NSURLSession you have "unlimited" time to download files), even this metric is used to decide how often wake up your app.
Is applicationDidEnterBackground ALWAYS called before applicationWillTerminate in an iOS app? I know that applicationWillTerminate is not always called (multitasking) - but when it is called, is applicationDidEnterBackground ALWAYS called first? I don't want to duplicate code unnecessarily by including it in applicationWillTerminate if it is already included in applicationDidEnterBackground, for an app that supports multitasking.
in ios 4.0 and later applicationDidEnterBackground is called instead of applicationWillTerminate so you don't have to call both of them. Here is the portion of the Apple docs:
Discussion
In iOS 4.0 and later, this method is called instead of the
applicationWillTerminate: method when the user quits an application
that supports background execution. You should use this method to
release shared resources, save user data, invalidate timers, and store
enough application state information to restore your application to
its current state in case it is terminated later. You should also
disable updates to your application’s user interface and avoid using
some types of shared system resources (such as the user’s contacts
database). It is also imperative that you avoid using OpenGL ES in the
background.
Your implementation of this method has approximately five seconds to
perform any tasks and return. If you need additional time to perform
any final tasks, you can request additional execution time from the
system by calling beginBackgroundTaskWithExpirationHandler:. In
practice, you should return from applicationDidEnterBackground: as
quickly as possible. If the method does not return before time runs
out your application is terminated and purged from memory.
You should perform any tasks relating to adjusting your user interface
before this method exits but other tasks (such as saving state) should
be moved to a concurrent dispatch queue or secondary thread as needed.
Because it's likely any background tasks you start in
applicationDidEnterBackground: will not run until after that method
exits, you should request additional background execution time before
starting those tasks. In other words, first call
beginBackgroundTaskWithExpirationHandler: and then run the task on a
dispatch queue or secondary thread.
The application also posts a
UIApplicationDidEnterBackgroundNotification notification around the
same time it calls this method to give interested objects a chance to
respond to the transition.
For more information about how to transition gracefully to the
background, and for information about how to start background tasks at
quit time, see iOS App Programming Guide.
Hope this helps clear the issue for you man.
Adrian
Here is the link to the technical note that is available on developer section. It is dealing with networking and multitasking. The actual method used in this doc deals with only applicationDidEnterBackground and since iOS 5 they have a system called watchdog which terminates the app if the network is unresponsive automatically. Hence there is no need to actually call applicationWillTerminate and try to execute codes to allow your app to finish its task before the app is terminated. The app will enter the background and will continue its task until the last task is completed. I hope that makes sense, but here is the link. Please read the watchdog section.
https://developer.apple.com/library/ios/#technotes/tn2277/_index.html#//apple_ref/doc/uid/DTS40010841
Hope this helps. :)