Can someone tell me a scenario when an iOS application directly enters the background state?.
Here I have quoted the lines from iOS Application Programming Document in multitasking section.
If your app is launched into the background instead—usually to handle
some type of background event—the launch cycle changes slightly to the
one shown in Figure 3-3. The main difference is that instead of your
app being made active, it enters the background state to handle the
event and then is suspended shortly afterward.
Added ...
In the iOS Application Programming Document if you see the figure 3.3 titled Launching an app into the background, the flow is like this User taps app icon -> main() -> UIApplicationMain() -> Enter background. Is there any chance when the app directly enters background when an user taps app icon. I interpreted the image like this. Is it correct?
Thanks.
One scenario for a background launch (App X)
X registered for location background mode in its Info.plist
X is run by the user, and registers for significant location changes while running
The user switches to another app Y, so X goes to background and is then suspended (it will be returned to background mode whenever there is a significant location change to handle, and then be suspended again)
The app Y eats lots of memory, so suspended applications (including X) get kicked out of memory
a significant location change comes in. Now X is launched into background.
Scenario
Lets say you had registered your application for Local/Push notification. Then your application will launch in background run some code which have written inside your applicationDidEnterBackgroud: delegate method and then it terminates immediately.
Check listing 2
Apple documentation
EDIT:
Applications might also find local notifications useful when they run
in the background and some message, data, or other item arrives that
might be of interest to the user. In this case, they should present
the notification immediately using the UIApplication method
presentLocalNotificationNow: (iOS gives an application a limited time
to run in the background). Listing 2-2 illustrates how you might do
this.
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.
We're seeing a strange situation on our iOS app that is impacting our user experience.
When a user background's the app (by pressing the Home button), we can clearly see the app entering the background. When the user then force-closes the app (by double-tappinging the Home button and sliding-up on the app), the app terminates normally. When the app is then re-opened, it follows the normal iOS start-up sequencing.
However, if the user double-taps the Home button while the app is running (resigning the app from active, but not sending it to background) and then force-closes the app (by sliding-up on the app), we're seeing the app terminate (the process gets killed), but then the app immediately re-starts in the background (with a new pid). The app is not designed to start-up or run in the background, and this is causing UX issues.
The app has no entitlements to run in the background, although we do have a couple of third-party libraries that have tasks that wind-down when the app enters the background.
I suspect the issue is a result of the app being force-closed from a non-active state rather than a background-state. If the app enters the background first, the third-party tasks are getting a chance to complete. If the app is force-closed from the non-active state, the tasks never get a change to complete in the background, so iOS is restarting the app in background to give those tasks a change to finish. It's unclear, however, if this is correct behavior.
-Stix
I'm kinda thinking the questions were self-evident, but if not:
Is this correct behavior for iOS? Should iOS be restarting the app in the background when the user force-closes the app w/o putting it into background?
If this is correct behavior, what can cause this to occur? Is it possible some third-party framework - still running a background task that hasn't completed - is the culprit?
The force-close works fine if the app is put into background first (giving background tasks the ability to complete/expire). Is there anyway to force it into background when force-closing the app while it's in a non-active state?
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.
My app uses location services in the background and as a result it shows on the iOS 8 lock screen (see picture). Is there any way to tell when an app is brought to the foreground by the user sliding this button?
The app will necessarily be launched when this button appears -- since it's being awakened by the same location signal that is causing it to appear on the lock screen. Accordingly, application:didFinishLaunchingWithOptions: has a launch options dict with UIApplicationLaunchOptionsLocationKey = 1.
That's useful, but what I want to know is when the app is brought to the foreground due to interaction with the button. No relevant application delegate methods seem to be called in this case, except didBecomeActive: and didMoveToForeground: but these methods don't carry extra data.
G'day iOS Guru's,
I have searched extensively for an answer, but can't find one (I bet the first response to my question will be to another similar question, but I cant find it).
Anyway, my problem is that I am running a simple map app that the user can drop pins on the map with a customised circle overlay around the dropped pin.
When the app goes into the background (iphone locked or home button pressed), if I re-enter the app within ~ 5 mins, the pins are still there and the app reopens to the last screen.
All good.
However, if I leave the app in the background for longer than 5 mins, the app restarts and all the pins are lost.
I have "Application does not run in background = NO" in the plist, and also enabled "App registers for location updates" under Required background modes.
How can I prevent the app from restarting after it enters the background and load the last opened view?
iOS can, and will, terminate your app while it's in the background if it needs additional resources to carry out whatever's going on in the foreground.
You need to ensure that your data is saved/archived when your app is terminated, and unpacked when re-launched so as to go back to where the user last was. The traditional way to do this is to use the applicationDidEnterBackground method, which is called when your app is suspended. You can then save all the data you need in order to resume cleanly in case your app is later terminated.
However, if you're targeting iOS 6 and upwards you can take advantage of a new feature - State Presumption & Restoration (link to documentation). State restoration off-loads some (but not all) of the heavy lifting onto iOS, and it can automatically snapshot your UI and provides easier ways to preserve and restore data.
in your AppDelegate.m
- (void)applicationDidEnterBackground:(UIApplication *)application
{
// 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.
// If your application supports background execution, this method is called instead of applicationWillTerminate: when the user quits.
// Save your data
}