I am in the middle of development of an iOS OpenGL based game. So far I was not very concerned with the app states change and life cycle - background, foreground, suspended, terminated etc. Now I wanted to add support to moving the app into a suspended mode (after pressing home) and then nicely recuperate it after restarting it.
My problem is that after pressing home button, the app always gets terminated (the application delegate always reaches -applicationWillTerminate:)
The documentation mentions that in order to prevent termination it is important to clear as much memory as possible, stop any timers etc. Doing this did not help to prevent termination, so I tried to experimentally copy the app delegate form an Xcode template app, with completely NO initialization of my app objects after launch/activation, no storyboard, nothing special in main.m.
While the template (I used an Xcode game template) is never terminated after pressing home, it ends at -applicationDidEnterBackground:, my app despite of the fact that is uses less memory and starts completely no tasks is always terminated.
What may be the reason. Included but inactive frameworks ? I have no clue.
Related
I’m putting an app into background.
Assuming that I’m not doing anything to keep the app alive in the background, then the app goes through suspended state in a matter of 5 seconds. Right?
What happens if I then tap on the app icon? That’s not suppose to trigger a didFinishLaunch right? It will just bring me back to the last screen I was at and also trigger didbecomeActive & willenterforeground notifications. I won't be getting any other callback. Right?
Assuming there is no restart of the phone, point 2 is true even if there are hours between me tapping home and then tapping back the app icon. Right? Does it also persist device restarts but not force-restart?
The only time I won’t be brought back to the screen I was at (before hitting home) is if the device receives a memory warning and my app is flushed out of suspended state. At this point tapping on the app icon will result in didFinishLaunch. Right?
(I’m asking all of this because sometimes after putting the app in the background and tapping the app icon again (e.g. 10 minutes later), the app is going through it’s launch phase. Most of the time it just goes back to its previous screen)
I've already seen Will ios terminate the app running in background after a specific time? but that doesn't address all aspects I want.
It will just bring me back to the last screen I was at and also trigger didbecomeActive & willenterforeground notifications.
Right, if your app was not terminated in the background.
I won't be getting any other callback.
Not necessarily true. If you were summoned to the front by a local notification, for example, you'll also get an event about that.
Assuming there is no restart of the phone, point 2 is true even if there are hours between me tapping home and then tapping back the app icon.
Not necessarily. The app might well be terminated silently in the background.
Does it also persist device restarts but not force-restart?
Absolutely not. How can the app run when the device is off? Shutting down the app terminates every app.
I’m asking all of this because sometimes after putting the app in the background and tapping the app icon again (e.g. 10 minutes later), the app is going through it’s launch phase
It's not a matter of time. The watchdog process is constantly combing the suspended apps looking for the ones that take up too much memory so that other apps can run. You must not be surprised if yours is one of them.
You can come back to the front launching from scratch or by coming back to life from suspension; it's the most basic fact of iOS app life! You just need to accept it.
But there are lots of things you can do to reduce your chances of being terminated in the background. Giving up memory-consuming objects as you background is first on the list.
If I send my app to background by clicking the home button and wait a certain time (perhaps 1 or 2 hours).
What will happen if i tap on the app icon now?
Will the app relaunch or simply be brought from background to foreground?
Quick "prologue":
Welcome to the wonderful world of stack overflow (SO), I myself am rather new here, but found it much friendlier to use welcome you anyway!
Just in case you haven't: Before you ask a question please look around a bit on SO in case someone else has asked the same thing, but if you can't get your question answered from that, then you should of course ask your own question.
Answer:
This question has no definite answer, because it depends. When you tap the home button your app enters, as you've said, the background and is still running to a certain degree. However after done so, the apps life cycle is up to iOS (the devices operating system) to determine. iOS controls and checks memory and CPU usage (etc..) of the device, and if you start another activity while your app is in the background that makes the available memory and CPU etc of the device not sufficient, iOS will terminate any apps in the background to not waste those resources (or battery etc). If so your app will relaunch next time you tap on it.
Although if you don't do anything performance heavy it is more likely that iOS keeps your device running in the background.
I'm not sure about the exact conditions and such the iOS works on, but i would say its very likely your app will have gotten terminated and is relaunched after 1 or 2 hours "in the background". Additional conditions apply if the device is locked during that period.
For proper documentation of this i would recommend reading Apples documentation for handling App State Transitions and/or the api for UIApplicationDelegate on apples developer website. Where you can see what the different methods in the AppDelegate does and how they interact.
Edit (answer to comment):
A way to relaunch the app everytime it goes into background?
Hm, yes, but also no. I'm not 100% sure about this (never encountered that "wish" before), but you can do this in your AppDelegate: (It will basically crash your app, but beware that apple does not encourage you to crash your own app anywhere). Doing this might stop the app from passing through apple store review process (i.e. your app might not be accepted to the App Store).
func applicationDidEnterBackground(_ application: UIApplication) {
exit(0)
}
Check out the answer to these post for a bit more information: call exit(0) in iphone app , objc - Proper way to exit iPhone application?.
Personally I would recommend you to work around it and don't do this. Also remember that when your app will enter the background applicationWillResignActive will be called and when the user opens it again, applicationDidBecomeActive gets called so you can do a reload or something from there if you want to refresh any data.
Whenever we press the home button in our device, the application releases the currently being used memory and moves to background stage. However, when we press this application app icon again it brings the app on top of the iPhone screen and occupies memory again. This is definitely not the relaunch because relaunch depends upon the UIApplicationDelegate method
didFinishLaunchingWithOptions. When we are switching app from background to foreground then applicationWillEnterForeground method fires.
For better understanding, the following link might be useful
iOS Application Life Cycle
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?
OK, this is pretty basic but I've read the documentation over and over and want to be sure I've got this right. In plain language, my watchkit app will be shut down by some user interaction exiting the app that's external to my code, right? I don't need to clear or reset the screen with any kind of close procedure that sets it up for another run? I don't need to build an "Exit" or "Close app" routine, right? It's confusing because the documentation implies the app will deactivate once it's no longer on screen (presumably by a user action like swiping to another app) and that this will call the didDeactivate function. But the documentation also claims:
In iOS Simulator, WatchKit calls the didDeactivate method for the current
interface controller when you lock the simulator by selecting Hardware > Lock.
When you subsequently unlock the simulator, WatchKit calls that interface
controller’s willActivate method again. You can use this capability to debug
your activation and deactivation code.
But the simulator doesn't appear to deallocate memory or reset variables or reset my app in any way. It remains persistent on screen in the state at the time of the lock, and it comes back in that state when I unlock. What worries me is that if I've got this wrong, I have an app built for one run. But I don't see routines for shutdown, screen clearance, or any of the elements you'd expect in a conventional shutdown routine.
I agree that the documentation can be confusing. The easiest way to think about it is that willActivate is called whenever your interface controller is displayed/activated. Likewise, didDeactivate is called whenever it is hidden/deactivated. So, if you're flipping through pages of controllers, each will receive a willActivate when it shows up and a didDeactivate when it disappears. Similarly, if a controller is deactivated because the app is no longer visible (e.g. it was suspended), didDeactivate will be called. If the user then raises their wrist to resume the app, willActivate is called, because the interface controller is being displayed.
There is no promise about whether your WatchKit app will be suspended or terminated (it's up to the OS), so you have to consider both possibilities. Based on experience, I know that dropping your arm will call didDeactivate before suspending your app. If you then raise your wrist, the app will resume and call willActivate. In my testing, the app was simply suspended (not terminated) in this situation.
You're correct that there is no built-in method that is called when the app is terminated. However, iOS 8.2 added four notifications that can be used to monitor the app/extension's state:
NSExtensionHostDidBecomeActiveNotification
NSExtensionHostDidEnterBackgroundNotification
NSExtensionHostWillEnterForegroundNotification
NSExtensionHostWillResignActiveNotification
This is very difficult issue, since it doesn't occur every time.
When an app is just launched, returning from background, it is fine without any freezing.
After some time being in background, when I re-activate it, the whole UI is frozen for while, even the activity indicator is not animating. As time goes on, this freezing gets longer and finally causes the app to be terminated by iOS for not resuming in time.
I would like to learn what are the generic causes of an app to be unresponsive, especially if the app is supporting background running feature and re-activating after a period of being in background.
It looks like I have missed some fundamental techniques that should be respected to avoid freezing problems.
UPDATE: I am suspicious if saving UIImage into Core Data object can be the main reason. At launch, it's not visible, however, as time passes, numerous saveManagedObjectContext are performed while UIImage is still referenced.
Maybe I should have listened to the instruction not to save any image in Core Data?
check for your crash log if you are getting this
Exception Codes: 0x8badf00d
then its most probably your application is taking much time either in launch or while moving in background or terminate, actually app take much time in launch/shut iOS suspend it and our app freeze, there is no such time define in documents but as i experienced it should not be more then 4-5 seconds. check your app delegate applicationDidFinishLaunch or multitasking delegates there is some code which is taking time in completion. For more info lokk at these
http://developer.apple.com/library/ios/#technotes/tn2151/_index.html
http://en.wikipedia.org/wiki/Hexspeak