Is there a universal time of iOS app suspension time (i.e when it goes out of background mode and terminates).
Background
The app is in the background and executing code. Most apps enter this
state briefly on their way to being suspended. However, an app that
requests extra execution time may remain in this state for a period of
time. In addition, an app being launched directly into the background
enters this state instead of the inactive state. For information about
how to execute code while in the background, see Background Execution.
Suspended
The app is in the background but is not executing code. The system
moves apps to this state automatically and does not notify them before
doing so. While suspended, an app remains in memory but does not
execute any code. When a low-memory condition occurs, the system may
purge suspended apps without notice to make more space for the
foreground app.
No, there is not any possibility to know about that, according to this:
Suspended: ...The system moves apps to this state automatically and does not notify them before doing so...
Link: https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html
Related
I am working in a chat application where I need to show user status (offline/online).
When my app is in foreground and background then I need to show user as online (managing by VoIP).
But when the user kill the app then it should go to offline.
I have to maintain a flag to show offline which I am managing in delegate function applicationWillTerminate but this function only called when app is in foreground state and user kill it by pressing double tap home button and swipe up.
This function does not get called when app is in background state. I mean simply press home by single tap (app will go in background) then again double tap to swipe up.
Is there any function where I get 100% call either app is in background/foreground state and user kill the app?
Is there any function where I get 100% call either app is in background/foreground state and user kill the app?
No. Just the opposite. If your app is terminated when already in the background, if it is suspended (ie not running in the background due to special entitlement), it is 100% certain you will get no event. You cannot. You are suspended and not running. The app dies in its sleep.
No, As per Apple Document
https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623111-applicationwillterminate?language=objc
For apps that support background execution, this method is generally not called when the user quits the app because the app simply moves to the background in that case.
What you can do execute a method(which hit an API for keeping status online) after few seconds(whatever you find suitable time) when you app goes in Background, If method is calling successfully after that specific seconds then user stay online, if its not call after specified second then server update its status to offline. So It require both server and client handling.
Is there a way to detect lock after the app has entered background? For example,
I have my app (A) open at the foreground
Then I bring another app (B) to the foreground
Then lock the screen
Is it possible for (A) to detect the lock?
The answer is "In theory yes, but usually not."
Apps actually have more states than active and background.
The states are:
Active
Background (still running, but another app is in the foreground)
Suspended (in memory, but not getting any CPU time)
Not running. (no longer running or in memory.)
When the user swaps apps, presses the home button, or locks their device, your app gets notified that it is going into the background, but it actually only runs in the background for a VERY short time. It transitions to suspended almost immediately. Once you're suspended, you can be terminated at any time without further notice.
If you need more time to finish a task when you get notified that you are being moved to the background, you can ask for it using the beginBackgroundTaskWithExpirationHandler call. However, as of this writing you get at most 3 minutes, and then your expiration handler fires and your app is suspended.
As a result of this, you don't actually get to run in the background for very long and it's likely that by the time the user locks the screen (or it locks automatically) you are already suspended and don't get notified.
Is it possible for (A) to detect the lock?
No, for two reasons:
You cannot detect, under any circumstances, that the screen has been locked. Even if your app is frontmost when the screen is locked, all you learn is that your app was backgrounded, without your being able to learn why.
In your scenario, by the time the screen is locked, your app isn't even running — it has been suspended. So it cannot "detect" anything.
I have an app that makes heavy use of video out. In a typical use-case, I'll have an iPad connected to an external monitor. I just want the external monitor on; the iPad display does not need to stay on.
The ideal case would be for someone to connect to an external monitor, then lock their iPad. But that pauses my app. (Currently, I'm calling setIdleTimerDisabled to keep the iPad from locking up and pausing my app.)
I'd like to give the user the option of locking the iPad, but still having my app running and sending images to video out. (Note: I'm not talking about keeping my app running when it's not in the foreground. I just want to keep it running while it's in the foreground, but the device is locked.)
Is this possible?
I would say no, it is not possible. Here's why:
The docs read:
Pressing the Sleep/Wake button is another type of interruption that causes your app to be deactivated temporarily. When the user presses this button, the system disables touch events, moves the app to the background but sets the value of the app’s applicationState property to UIApplicationStateInactive (as opposed to UIApplicationStateBackground), and finally locks the screen.
Something interesting to note in the docs above is that a bit further down under "What to do when an interruption occurs" Apple recommends that you stop doing certain tasks.
In response to this change, your app should do the following in its applicationWillResignActive: method:
Stop timers and other periodic tasks.
Stop any running metadata queries.
Do not initiate any new tasks.
Pause movie playback (except when playing back over AirPlay).
Enter into a pause state if your app is a game.
Throttle back OpenGL ES frame rates.
Suspend any dispatch queues or operation queues executing non-critical code. (You can continue processing network requests and other time-sensitive background tasks while inactive.)
This tells me that Apple doesn't want or expect your app to be doing much of anything in this state, other than preparing to be fully backgrounded.
On a related note here's a thread that shows how to determine whether you've hit the Sleep/Wake button or not:
Is it possible to distinguish between locking the device and sending an app to background?
In my application, I'm downloading and uploading data at some point of time on a separate thread using NSOperation. Both process take approx. 2-3 min. If application remains active then everything works fine. But if the iPad screen is locked (automatically or manually), the app becomes inactive and download/upload get paused and when screen is unlocked after some time process failed with timeout error.
I have "App plays audio" for "Required background modes" in plist file. Do I need to set any other flag for running app while screen is locked?
Please help me what is going wrong.
When the screen is locked, your app becomes inactive. Per "Responding to Interruptions" in iOS App Programming Guide:
Pressing the Sleep/Wake button is another type of interruption that causes your app to be deactivated temporarily. When the user presses this button, the system disables touch events, moves the app to the background but sets the value of the app’s applicationState property to UIApplicationStateInactive (as opposed to UIApplicationStateBackground), and finally locks the screen.
You can get extra time for background tasks according to "Executing a Finite-Length Task in the Background" in the same guide:
Apps that are transitioning to the background can request an extra amount of time to finish any important last-minute tasks. To request background execution time, call the beginBackgroundTaskWithExpirationHandler: method of the UIApplication class. If your app moves to the background while the task is in progress, or if your app was already in the background, this method delays the suspension of your app. This can be important if your app is performing some important task, such as writing user data to disk or downloading an important file from a network server.
You can refer to the document to implement a finite-length download task in the background.
Other references:
Download data in background with iOS4
iOS Application Background Downloading
What delegate is called in this situation if I have an app running.
Over time, if iPad is set to lock after 2 mins, what is its state? Does the app still run? or does it suspend?
I'd like to know thanks
If the iOS device automatically locks after a period of inactivity, the same thing happens as when it's locked by pressing the lock button: the app briefly goes into the background before being suspended. (Unless of course it is an audio-playing app or other app that requests extra execution time, in which case it may stay in the background longer, or indefinitely, without being suspended).
In terms of UIApplicationDelegate methods, applicationWillResignActive: will be called first, followed by applicationDidEnterBackground:.